fluiddb: All content tagged as fluiddb in NoSQL databases and polyglot persistence
- what is FluidDB: a platform for the web of things, each represented by an openly writable “social” object
- why FluidDB: most of the information nowadays lives inside walled gardens, so its difficult to make real use of it. I especially enjoyed this slide explaining the problem with closed information:
- how to use FluidDB: all applications use the same FluidDB database through a RESTful API
- A short version of NoSQL week in review, after losing the original post. ¶
- Nicholas J. Radcliffe: ☞ Alice in FluidDB. The power of tagging. ¶
- ☞ A graph theory book by David Joyner, Minh Van Nguyen, and Nathann. Helpful for everyone interested in graph databases. ¶
- Jeff Darcy: ☞ Riak and Cassandra. It wasn’t long until someone jumped at/corrected Riak’s comparisons with Cassandra, MongoDB and Neo4j. And now there is a comment on the Basho blog: ☞ The Craft Brewers of NoSQL¶
I think the market is still too young and small to see real attacks between the players. But once the market will grow in size, we will unfortunately start seeing some of these. Hopefully, myNoSQL readers will know how to make the difference!
And the conversation ☞ ends with beers!
- Till Klampaeckel: ☞ Redis on Ubuntu (9.04) ¶
- Daniel Wertheim: ☞ Simple-MongoDB – Support for Regex and custom Id’s. ¶
- Salvatore Sanfilippo: ☞ Redis weekly update #2 - Real world hashes, refactoring, and fixes ¶
It looks like initially I have misunderstood what FluidDB is by calling it a “Wikipedia of databases“. A ☞ post on the FluidDB blog has clarified it for me, so I came up with another definition: “a persistent post-it database service in the cloud”.
While reading the blog post — and leaving aside the fact that as any NoSQL solution it came up with a Twitter-related application — I have found myself getting really excited at the idea. But then, I have realized that:
- there must be someone creating such an application
- the associative pattern suggested by FluidDB, while being nice will have to be extremely carefully implemented in the app
- (this is the most interesting from our NoSQL perspective) there doesn’t seem to be anything unique in FluidDB that would make such a usecase non-applicable to any other NoSQL solution.
Let me clarify it a bit. Basically the article introduces the idea of being able to associate metadata with any kind of information and keep this metadata under clear access rules. In my opinion this is just a simple associative relationship (think key-value stores) that could be implemented using any of the NoSQL solutions we are covering here. Moreover, I tend to think that document databases, like CouchDB, MongoDB, Riak or Terrastore would offer natively a lot of flexibility on the metadata “(un)structure”
Am I wrong?
Taking a look at a fascinating FluidDB usecase that seems to be easily supported by any NoSQL solution. Or not?