lightweight database
in [Lisp]
|
From: Pillsy on 17 Mar 2010 10:43 On Mar 17, 10:39 am, "vanekl" <va...(a)acd.net> wrote: [...] > The database will exist in multiple locations simultaneously. The database will have a really stupid name: [...] > Witness Cassandra, Redis, Hadoop, BigTable, Hypertable, > Hbase, MongoDB, Tokyo Cabinet, Voldemort, CouchDB, ... Cheers, Pillsy
From: Tamas K Papp on 17 Mar 2010 10:53 On Wed, 17 Mar 2010 07:43:26 -0700, Pillsy wrote: > On Mar 17, 10:39 am, "vanekl" <va...(a)acd.net> wrote: [...] >> The database will exist in multiple locations simultaneously. > > The database will have a really stupid name: [...] >> Witness Cassandra, Redis, Hadoop, BigTable, Hypertable, Hbase, MongoDB, >> Tokyo Cabinet, Voldemort, CouchDB, ... Dunno. CouchDB sounds nice. Especially if they ever get around to writing FridgeDB and TVRemoteDB. Also, Voldermort is a nice touch, they can call the demo version YouKnowWhoDB. Tamas
From: Alex Mizrahi on 17 Mar 2010 11:16 ??>> Emm... People use databases when they have shitloads of records, and ??>> so O(N) operations are not acceptable. v> That type of thinking is only relevant when working with old hardware, v> and is quickly turning into a fiction. All databases will be stored in v> primary memory and machines will commonly work in parallel. Ironically, here's a presentation by Guy L. Steele which (basically) says that stuff like linked lists does not work well with parallelism, and you need some kind of trees for it: http://docs.google.com/viewer?url=http%3A%2F%2Fresearch.sun.com%2Fprojects%2Fplrg%2FPublications%2FICFPAugust2009Steele.pdf v> It's just a matter of time. With this new capability algorithms and v> database programming will become simpler. I don't think that it is particularly complex now. Unless you're retarded. v> The database will exist in multiple locations simultaneously. O(n) ops v> will become normal. We're already seeing this happenng today. Witness v> Cassandra, Redis, Hadoop, BigTable, Hypertable, Hbase, MongoDB, Tokyo v> Cabinet, Voldemort, CouchDB, ... Oh, sure, all these databases use simple linked lists and O(N) traversals under the hood... Next time you'll be trolling consider making it at least somewhat plausible.
From: Raffael Cavallaro on 17 Mar 2010 11:48 On 2010-03-17 04:03:01 -0400, Alex Mizrahi said: > Emm... People use databases when they have shitloads of records You do realize that the title of the thread is "lightweight database" right? I suggested cl-prevalence precisely because it is useful for light duty, when the entire dataset fits easily in memory, not because it scales to what, to put this in technical parlance, is sometimes referred to as "shitloads of records." warmest regards, Ralph -- Raffael Cavallaro
From: Raymond Wiker on 17 Mar 2010 11:59
Dmitry Kalyanov <kalyanov.dmitry(a)gmail.com> writes: > On Mar 16, 8:55 pm, Raymond Wiker <r...(a)RAWMBP-2.local> wrote: >> "Alex Mizrahi" <udode...(a)users.sourceforge.net> writes: >> > AP> You might want to look into sqlite. I haven't tried their CL >> > AP> binding, >> >> > One can use SQLite via CLSQL, I've tried it, it works. >> >> There are also one or two alternative sets of bindingss for >> SQLite. They may be worth looking into, but using CLSQL obviously gives >> you more freedom to change to some other database at a later point. >> >> If you're using Windows, it's also possible to create a thin >> layer of sanity around the .NET database database classes, using RDNZL >> (which is absolutely awesome :-). >> >> > AP> but the database itself is simple, easy to setup and robust. (And >> > AP> fast, too.) >> >> > I agree. >> >> I'm not 100% sure I agree about the speed of SQLite, but I >> haven't done enough benchmarking to contradict you :-) >> >> ... and the bottleneck (if there is one) may actually lie within the >> SQLite wrapper that I use. > > CLSQL is the performance bottleneck. SQLite itself is very fast; it > may be > slow on very complex queries due to its query plan generator not being > as > sophisticated as in e.g. PostgreSQL or Oracle. I'm using SQLite through cl-sqlite (thanks :-). The speed issues I had may actually be caused by running on a platform on which it is necessary/mandated to run a real-time virus scanner which hooks into each disk write operation[1]. I did get a fair improvement by doing PRAGMA synchronous = NORMAL; and might be able to get even better performance by using the "OFF" setting. I don't think that is a good compromise between safety and speed, though. My application may be a bit unusual, in that I am using SQLite to implement something that behaves like a disk-based hash table, with lots of lookups, and lots of updates, with 0 or 1 rows returned by most (99%) of the queries. Footnotes: [1] I'm not a fan of Windows. |