2013/5/26 Cedric Greevey <cgree...@gmail.com> > I may be developing an application which will need a persistent, >
> ACID > which means at least transactionnal, are you sure you need that ? depending on the database, ACID means differents things. Do you need data integrity across «documents», which means that a transaction must span modification to several objects, if a failure happens everything should rolled back or not persisted. > local database (on the same disk as the application, rather than having to > be accessed over the network) > which means embedded > containing information about potentially 100,000-1,000,000 (or more) > objects. > which means relatively big > Much of that information will be of a quasi-boolean character: "is it an X > or not?" for various choices of X, but with "yes", "no", "borderline", and > "not yet evaluated" as the four possible values. It will be desirable to > query for these, for example to get a lazy seq of all objects for which > it's a borderline Y or for which it's not yet evaluated whether it's a Z or > for which it's either "yes" or "borderline" on whether it's an X or > whatever. > It seems like loosely structured data for which a key/value store (also know as kv store) might be great > I'm not that familiar with the local-DB solutions out there. I'd like a > recommendation for one which is * > > a) a good for for Clojure use > I'm not sure about Clojure specificities related to bindings C/C++ databases, but in Python it's some ctypes<http://docs.python.org/2/library/ctypes.html>(or else) definitions away. > and b) a good fit for the type of data and queries noted above. > You are not very specific about the queries and the data. 1) Is it structured aka. an object can have several fields possibly complex fields like list or hashmaps but also integers ? dates and uuids can be emulated with strings and integers 2) Do objects have relations ? a lot of relations ? 3) is the data schema fixed at compilation or do you need to have the schema to be dynamic ? > The DB must be able to grow larger then available RAM without crashing the > JVM and the seqs resulting from queries like the above will also need to be > able to get bigger than RAM. > > My own research suggests that H2 may be a good choice, but it's a standard > SQL/relational DB and I'm not 100% sure that fits well with the type of > data and querying noted above. Note though that not all querying will take > that form; there'll also be strings, uuids, dates, and other such field > types and the need to query on these and to join on some of them; also, to > do less-than comparisons on dates. > Depending on your speed needs and the speed of the database, a kv store can be enough, you serialize the data as strings and deserialize it when you need to do computation. Except that kv store are not easy to deal with when you have complex queries, but again it depends on the query. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
