Camille Harang
2011-07-07 20:05:41 UTC
"BTW I think that CouchDB could be another excellent base to implement Seeks, as it is already RESTfull, decentralized, multi-platform, hosting and providing JSON/HTML, multi-language (Python, JS, Erlang, etc.), but that's another topic :-p"
http://news.ycombinator.com/item?id=942810
http://github.com/igal/ruby_datastores/raw/master/2009-11-14%20Non-relational%20data%20stores%20for%20OpenSQL%20Camp.pdf
Tokyo Cabinet / Tyrant is > 10 times faster (this includes RESTful, master-slave replication). The only other contender here is redis (we don't need the expressiveness of MongoDB at the moment).
I've just been interested in CouchDB these days, but yes, I've read thathttp://news.ycombinator.com/item?id=942810
http://github.com/igal/ruby_datastores/raw/master/2009-11-14%20Non-relational%20data%20stores%20for%20OpenSQL%20Camp.pdf
Tokyo Cabinet / Tyrant is > 10 times faster (this includes RESTful, master-slave replication). The only other contender here is redis (we don't need the expressiveness of MongoDB at the moment).
many benchmarks shows that CouchDB can be slow (however many comments
claiming that it doesn't reflect real use cases, in real situation
CouchDB doesn't seem to suffer on this, e.g.*), but in most cases Seeks
nodes work on personal single machines that are not used at 100% of
their capacity. Anyway, that's not what I was pointing, CouchDB might
indeed be a bit slower than other DB, I was talking about CouchDB assets
on higher level: application. Indeed, CouchDB is very fast for something
else: software development, which is also an important aspect to be
considered (IMHO).
*http://webcache.googleusercontent.com/search?q=cache:9StCnkyuwLsJ:www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benchmark
As CouchDB does a lot of things that Seeks does (and plans to do) and is
very friendly for developing, distributing, hosting, and running
applications upon it, I find that an interesting way for implementing
Seeks could have been a to make it a CouchDB app. Basically, bringing
Seeks' specific technological layer (DHT, LSH, etc.) to CouchDB would
transform any CouchDB node into a Seeks node. Then the community would
have several the advantages from it, for example:
* Installing Seeks easily, just point your CouchDB to the Seeks
application and replicate (few clicks), and you can keep it
updated to the last version by continuous and decentralized
replication, no need to package.
* It would be the same for any other Seeks components: anyone can
start to hack it's own piece of software (e.g. parser) directly in
the browser using the programming language of their choice
(JavaScript, PHP, Ruby, Python or Erlang), and distribute it to
any other Seeks user without any effort.
* CouchDB is sufficient by itself (no ngnix, apache, etc. in front).
* It's easy to install and multi-platform (Windows, OSX, Android,
Linux, etc.).
* It's lightweight.
* It has a powerful RESTful API.
* It's a cutting edge technology Web server, does almost all the
work for you when developing JSON/HTML5 apps (data validation,
events, etc.), e.g. implementing a meteor-like interface that
reflects data in real-realtime takes 5 minutes.
* It's good to store (like MongoDB) an serve binary data as well, so
snippets could contain thumbnails, video footage, etc.
* Thus, anyone having a Seeks/Couch node would have a powerful Web
server, people could then host their own data, and index it into
Seeks instead of pointing to external resources (even big video
files, as p2p replication assets of CouchDB could load-balance
large bandwidth to other nodes).
* It has data versionning (e.g. interesting for snippet history).
* NoSQL (no-shema), so very flexible regarding snippet structure
evolution and extra data.
* Stored document's uuids are128bits hashes: halos fit right in.
* It comes with user management (excellent for profiles) : roles,
ACL, authentication (with openid), authorization (with oauth, out
of the box, e.g. cool for managing access rights on node's served
Web applications).
* Online/offline capabilities : e.g. you can access a URL from your
offline mobile to communicate it to someone (or capture a new URL
from a QR code and store it on the device), while the replicated
DB is still available on the network from another up and running
host, and when you are back online they sync :-)
Well, the actual way is probably the best, but while browsing about
CouchDB I found this manner could be interesting as well, even very
different, it was just to share my discoveries ;-)
Camille.
--
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1