As an addendum to this thread ...
It just occurred to me now, following an interview today with a developer of
millions-users social-network games, that I could be embracing this NoSQL thing
in an indirect way, taking into account that still I consider it just a
reasonable compromise for some applications, but not a general database pancea.
Because Muldis D is designed from the start to be implementable over both SQL
DBMSs of various capabilities and within general purpose languages, meaning that
any functionality a DBMS doesn't natively support can be hoisted to the
application, this structure is a natural fit for NoSQL.
NoSQL is all about keeping the main DBMS simple, supporting just a few native
operations, and massively parallel. And so, one could write Muldis D code and
deploy it both over SQL and NoSQL, and in the latter case it would just do a lot
of the work on the application side. Essentially, Muldis D takes care of the "I
believe I did, Bob", so you can use a NoSQL store without doing the "write a
distributed map-reduce function in Erlang" yourself, instead you just say what
you want declaratively much like in SQL, and then the right thing happens.
Of course, that won't generally give you the consistency/integrity that a
relational DBMS backend has over a NoSQL one, but at least you'll get the
powerful queries part.
You heard it here first.
-- Darren Duncan
S.A. Kiehn wrote:
Thanks for the link Darren. I will read and ponder.
Also of interest, I seen that Search::GIN has had a new release
<http://blogs.perl.org/users/sawyer_x/2010/03/searchgin-004-finally-out.html>.
The post also mentions some docs explaining queries, but I have not
found them yet. Active Search::GIN development would encourage KiokuDB
usage I would think.
Thanks for the posts regarding this topic.
S. Kiehn
Darren Duncan wrote:
Here's something timely on Ars, in that I just discovered it now
around the time of this discussion thread:
http://arstechnica.com/business/data-centers/2010/02/-since-the-rise-of.ars
It lays out a summary of how the SQL and NoSQL worlds compare, and
what sort of trade-offs you get for each choice, and it introduces
several specific NoSQL projects. I also learned something, such
that what CouchDB and MongoDB specifically represent data with is
JSON documents.
So basically, what you pick out of today's choices depends on your
priorities.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
