lightweight database
in [Lisp]
|
From: Dmitry Kalyanov on 16 Mar 2010 22:56 On Mar 16, 7:06 pm, "Alex Mizrahi" <udode...(a)users.sourceforge.net> wrote: > 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. > > AP> but the database itself is simple, easy to setup and robust. (And > AP> fast, too.) > > I agree. CLSQL interface to SQLite is quite bad. CLSQL simply kills the performance of DB access.
From: Dmitry Kalyanov on 16 Mar 2010 22:59 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.
From: Tim X on 17 Mar 2010 02:47 Tamas K Papp <tkpapp(a)gmail.com> writes: > Hi, > > I need to use a simple database from CL. The database consists of > timestamp/count pairs, a timestamp is a date&time, while the count is a > single integer. The idea is that a server which runs the database > collects the data continuously (not necessarily using CL, but that can be > achieved), and I want to be able to do simple queries using CL (eg get > all the records between two timestamps). I am looking for something > that is > > 1. robust, > 2. simple to setup (would prefer to avoid SQL) > 3. has reasonably mature CL bindings, or makes it easy to implement them. > > I have no experience with these things, so any help would be appreciated. > CLISP has some simple DB extensions. You need to run the 'full' version. Its support for BDB would probably meet your needs. Tim -- tcross (at) rapttech dot com dot au
From: Alex Mizrahi on 17 Mar 2010 04:03 ??>> Tamas wrote: " and I want to be able to do simple queries using CL ??>> (eg get all the records between two timestamps). " ??>> ??>> Hash-table cannot do this. You need a data structure like a binary ??>> tree to do this. ??>> There are no such data structures in CL standard, so you'll have to ??>> use some library for it. v> Because hash-map/reduce doesn't exist. Oh, wait... Emm... People use databases when they have shitloads of records, and so O(N) operations are not acceptable. If they are ok (no hurry and/or relatively low number of records), you can just use lists.
From: vanekl on 17 Mar 2010 10:39
Alex Mizrahi wrote: >>> Tamas wrote: " and I want to be able to do simple queries using CL >>> (eg get all the records between two timestamps). " >>> >>> Hash-table cannot do this. You need a data structure like a binary >>> tree to do this. >>> There are no such data structures in CL standard, so you'll have to >>> use some library for it. > > v> Because hash-map/reduce doesn't exist. Oh, wait... > > Emm... People use databases when they have shitloads of records, and > so O(N) operations are not acceptable. That type of thinking is only relevant when working with old hardware, and is quickly turning into a fiction. All databases will be stored in primary memory and machines will commonly work in parallel. It's just a matter of time. With this new capability algorithms and database programming will become simpler. The database will exist in multiple locations simultaneously. O(n) ops will become normal. We're already seeing this happenng today. Witness Cassandra, Redis, Hadoop, BigTable, Hypertable, Hbase, MongoDB, Tokyo Cabinet, Voldemort, CouchDB, ... |