StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I would group your options into the following:</p> <ol> <li>Relational Database</li> <li>XML or JSON (whether that's a config file or some separate document).</li> <li>External in-memory caching such as <a href="http://memcached.org/" rel="nofollow">Memcached</a> (also available from within Play).</li> <li>Store the data as a Java data object, or use <a href="http://www.playframework.org/documentation/1.2.4/cache" rel="nofollow">Play's simple, non-distributed cache</a>, which stores the data in the Java heap. </li> </ol> <p>You have two issues with which you'll need to deal here: 1.) the performance of accessing your data, and 2.) the maintainability of your dataset. We can deal with these separately.</p> <p><strong>Performance</strong></p> <p>You have two considerations regarding performance. The first is access/lag time, the second is the amount of data stored in memory. Regarding the access time, the database will certainly have the most lag. Numbers 2 and 3 will vary depending on your hardware and OS -- you'll need to do some testing in your particular setup to really know for sure which is going to perform best. Having to retrieve the XML/JSON file from disk would certainly be much slower than accessing it from an in-memory cache, but Operating Systems are typically pretty intelligent about keeping frequently accessed files available in memory, too. It may be that the overhead of using a caching system ends up being slower than just using a static file. </p> <p>Your data will ultimately need to become a Java object in order for you to interact with it from your code. Thus, #1,2, and 3 will all require some serialization of external data into a Java object, which will take some amount of time. Accessing a Java variable (#4) will be the fastest, as it requires no extra serialization.</p> <p>Regarding the amount of data stored in memory, #2 and #4 will require that you store the entire dataset in memory each time you run the code (i.e. load any of the relevant pages). This may not be a huge concern for 7 x 300 values (8kB, if they were all floats), but when you're expecting a single server to serve thousands of clients, that extra memory consumption used on every page load may actually become the bottle-neck for you application. You could alleviate this cost if you were able to store the data statically. Option #3 will only store the data in memory once, then shares that across all requests, which shouldn't be a big memory penalty. #1 will likely function like #3 (at worst), in that it will store one copy in memory globally. These methods will store one global copy of the data in memory, then only serialize the relevant code into Java objects (perhaps one row of the dataset). </p> <p>Finally, note that the downside to using Play's internal, Java-based cache is that it costs you scalability. Be sure to read the details <a href="http://www.playframework.org/documentation/1.2.4/cache" rel="nofollow">here</a>.</p> <p><strong>Maintenance</strong></p> <p>The other concern is how difficult it will be for you to maintain the data. It sounds like you're opposed to an RDBMS-based solution because of maintenance and deployment concerns. Memcached would probably not offer you much over a database, as you would still need to ensure consistency of the cache across your deployment environments. At that point, you're left with options #2 and #4. In my mind, it's much easier to work with a dataset stored in XML or JSON than in Java, so I would say the benefit goes to the XML-based dataset in terms of maintainability.</p> <p><strong>Conclusion</strong></p> <p>So the best solution for maintenance and deployment is probably XML, the best in terms of performance would be Java-based objects. Thankfully, we can use a tool to get the best of both worlds. <a href="http://code.google.com/p/pojoxml/" rel="nofollow">PojoXML</a> allows you to convert POJOs (Java objects) to XML and back. Thus, you can maintain your data in XML, then use PojoXML to convert that document to a Java object any time you make changes to your dataset. Then you get the performance benefits of keeping your static data in compiled Java code, with the maintainability of using XML. Just be sure to store the data as a statically so that you don't consume 8kB of memory for every page load.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload