[Seeks-users] Another topic

[Camille H. <mam...@yo...>]

Le 07/07/2011 18:00, re...@se... a écrit :
> "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"
>
> CouchDB is way too slow:
> 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 that
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