NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



javascript: All content tagged as javascript in NoSQL databases and polyglot persistence

Riak and JavaScript

Riak has a love affair with JavaScript, and we embrace it in various ways across the codebase. That’s one of the many reasons Basho chose to sponsor both JSConf and NodeConf. And, since we are head over heels for JS, we thought it appropriate to assemble this page (complete with state-of-the-art animated GIF) aimed at getting developers up to speed with what Riak has to offer the JavaScript community.

Nice resource page put together by Basho guys in celebration of two JS conferences taking place these days.

Original title and link: Riak and JavaScript (NoSQL databases © myNoSQL)


Why MapReduce is Simple

Mathias Meyer:

I’m almost 100% certain you use MapReduce every day. If not daily, then at least once a week. Whenever you have a list of items that you loop or iterate over and transform into something else one by one, if only to extract a single attribute, there’s your map function.

Explaining MapReduce using simple functions.

Original title and link: Why MapReduce is Simple (NoSQL databases © myNoSQL)


Powered by CouchApp: MapChat

Nice little CouchApp: MapChat:

MapChat: CouchApp

Why CouchApp/CouchDB? I guess the answer in this case is: development simplicity, as there’s no need for additional web server or other things like that. Just CouchDB and a bunch of Javascript.

Original title and link: Powered by CouchApp: MapChat (NoSQL databases © myNoSQL)

Backbone and CouchDB

CouchDB with Backbone and backbone-couchdb.

And because it’s couchdb, all you have to do is create the database record in futon (one click) and all the models are automatically saved away, the database doesn’t need to be aware of what you’re saving, it just saves.

Original title and link: Backbone and CouchDB (NoSQL databases © myNoSQL)


Thanksgiving Weekend Crash Course - Android, Sencha Touch, PhoneGap and CouchDB

Horace Lin having fun with some cool frameworks and tools, including CouchDB:

The goal of this project was to display the Sencha list view on Android device with user names, user’s icons and pop out the game the user paying on facebook if the arrow button pushed. All the users information will be stored on CouchDB and retrieve by JavaScript codes through Ajax.

Christmas is getting closer, so you can come up with fun projects too.

Original title and link: Thanksgiving Weekend Crash Course - Android, Sencha Touch, PhoneGap and CouchDB (NoSQL databases © myNoSQL)


Stratifying asynchronous storage

More about Node.js, but everyone is playing out with Node and NoSQL databases these days. And I don’t think I’m the only one finding the callback programming model quite unreadable (eye hurting?):

Here, waitfor()/resume is one of the special constructs that StratifiedJS adds to the JavaScript language. You can find out more in the StratifiedJS docs, but in a nutshell, the above code executes this.async_get(), passing in a special callback function called ‘resume’, and blocks execution of the current stratum until async_get() calls back resume().

While the stratum that called database.get() blocks and waits for database.async_get() to perform its work, the browser UI will stay responsive. At the same time, other parallel strata not waiting for database.get() will happily continue running.

Here is the ☞ StratifiedJS library/framework

Original title and link: Stratifying asynchronous storage (NoSQL databases © myNoSQL)


MongoDB Impressions

I’ve spent the past three days diving into MongoDB and jQuery. [ …] But the real attraction is the ability to work with syntax very similar to Javascript and JSON from client to server to database. Just better for my relatively weak, pan-fried brain.

Let’s not forget though, that MongoDB is BSON so you’ll need to go through a native driver. But there are other NoSQL databases that speak natively JSON (e.g. CouchDB) and that may not even need a server side component.

Original title and link: MongoDB Impressions (NoSQL databases © myNoSQL)


CouchDB Reference to JS Functions, CommonJS modules, URL Rewrites

Caolan McMahon shares the documentation he put together for CouchDB JavaScript functions, CommonJS modules that can be used in CouchDB design documents, and URL rewrites:

I’ve been exploring some of the more recent features, as well as a few older ones that I’d previously neglected. I’ve found experimenting with these at turns both exciting and frustrating. CouchDB continues to lack thorough documentation, and although the reasons behind most API choices are blindingly obvious once you understand the context of their implementation, getting there is a steepening learning curve.

Original title and link for this post: CouchDB Reference to JS Functions, CommonJS modules, URL Rewrites (published on the NoSQL blog: myNoSQL)


Release: Riak 0.12.0, Improving Failure Recovery

I’m not really sure how I’ve missed the release of Riak 0.12.0 last week. The ☞ release notes are listing over 30 enhancements and bug fixes. Another important update coming with Riak 0.12.0 is the improved failure recovery:

Riak now uses a new and improved mechanism for determining whether a node is fully online and ready to participate in Riak operations. This is especially important in failure recovery situations, as it allows the storage backend to complete a full integrity check and repair process.

Riak is getting closer to celebrate 1 year and there were more than 12 releases during this year. That’s a nice pace for a project!

Meanwhile, Riak has got a library in Go named ☞ Goriak whose API is described ☞ here, but also a Javascript library for node.js[1]: ☞ riak-js.

  1. As we can see in how many mentions node.js sees in the NoSQL database world, I’d say people are looking for interesting ways to connect the two technologies.  ()

node.js Gets its Own Key-Value Store: nStore


A simple in-process key/value document store for node.js. nStore uses a safe append-only data format for quick inserts, updates, and deletes. Also a index of all documents and their exact location on the disk is stored in in memory for fast reads of any document. This append-only file format means that you can do online backups of the datastore using simple tools like rsync. The file is always in a consistent state.

nStore can be found on ☞ GitHub

Effective Stored JavaScript in MongoDB

Vasil Remeniuk shares some tricks on working with MongoDB JavaScript:

This approach (nb: inlined JavaScript ) has two obvious drawbacks:

  1. Performance. Evaluated functions are not persisted between connects, therefore should be re-evaluated, which takes a lot of time (especially, if you deal with complex calls);
  2. Testability and readability. In-lined code is untestable and looks ugly.


First of all, all the in-lined JavaScript code should be moved to the place, where it should be – .js files on the classpath that can be tested (and mocked), and recognized by IDEs, which make them more comfortable to edit (because oh highlights, JavaDocs, autocompletion and other features we love our IDEs for).


Emulate Sequences in MongoDB

Interesting approach of emulating sequences with MongoDB, by hosting JavaScript code on the server side. Anyway, there’s a part that confused me:

This also isn’t the most efficient approach for high performance because db.eval() monopolizes mongod, so depending on the database usage pattern this could be pretty disruptive. On the other hand, this mongod behavior effectively acts as a lock and means calling this function will be atomic.

If we are to believe the above comment, it just means that executing a server side MongoDB function is blocking and that doesn’t really sound scalable at all. Not to mention that I thought they improved on this behavior with the MongoDB 1.4 release.

I’m wondering if anyone can clarify what is the behavior for server-side MongoDB functions.