-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/21/2011 12:37 PM, Jay A. Kreibich wrote: > Yes, but in something like memcached, the database is not aware of > that structure, and can't take advantage of it.
Memcached does understand some types and has atomic increment/decrement etc but does not understand structure. > When storing serialized objects, it is all too common to see code that > fetches an object, un-marshals it, alters some simple value, re-marshals > the whole object, and then write the whole thing back. This all circles back to what you are doing and in particular what the OP was doing. If you need to do queries, modifications and durability then what you really need falls under the category of 'database'. On the other hand if there is no need for querying or changes then something like memcached is a great way for a bunch of machines/processes to get the data. > .... Redis .... Redis is a database :-) > Yes and no. Redis, like memcached, is essentially an always in-memory > key/value store. *All* databases are in-memory for practical purposes. Their working set will need to be in memory either explicitly due to their implementation, or implicitly via the operating system or through administration (eg indices). If accesses to the working set of data require disk accesses then the performance will be dismal. (Some exceptions for data only accessed sequentially.) > Its main selling point is memcached-like speed, Incidentally MongoDB claims the same thing :-) The places I use memcached are where I do not want disk touched. > ... but it is a good fit ... It looks like we are seeing what happened with the first generation of DVCS. Relational representation is being changed to be less constrained/structured. There are numerous "databases" with varying and overlapping sweet spots in terms of querying, persistence, performance, distribution etc. I expect we'll see similar shakeouts and end up with a small number of strong products., > Like SQLite itself, I tend do all my virtual table modules in > extremely vanilla C. Brave :-) My personal preference is to do the initial development in Python and then reimplement in C if needed for portability/performance reasons. The Python development is a lot quicker and then acts as a test suite for the C implementation. I wonder how many of the other bindings for SQLite have bothered to implement virtual tables as that probably holds back usage of virtual tables a lot. (A 'hello world' virtual table in Python/APSW is about half a screenful of code. An example one I have that represents information about files on disk is just under a screenful.) > I happen to think virtual tables are one of the more powerful features > of SQLite, but also one of the most under-utilized features. Agreed. Unfortunately it does require that the underlying data be representable in a relational manner which is also very constraining. > Since a big part of writing these is to get them out for other people > to use them, Where do you publish them? It is probably also worth trying to encourage a 'contrib' location for SQLite that is more active and in wider use than http://www.sqlite.org/contrib > Working in C avoids adding complexity, like someone working > in Java wanting to use your MongoDB module. I suppose it could be > done, but I wouldn't want to be the one trying to make it all work. MongoDB is client server so this issue does not arise. (Nor do they have virtual tables.) In order to perform "programming" on the server side such as for map/reduce you have to use Javascript which is slowly becoming the most popular language for that kind of thing including on the desktop. (Eg see node.js and Seed.) Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1i/zkACgkQmOOfHg372QT9cgCgyV7NaECzQUrrrDZr9zYri0tq RkkAoKSuRlclVshN/oIxSXOy0dtXZcot =xEyA -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
