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



Riak at Clipboard: Why Riak and How We Made Riak Search Faster

Gary William Flake:

For me, the two most important considerations are (1) how easy it is to write effective code and (2) how bulletproof the system is operationally. Others may argue that other attributes — like performance or the particulars of the data model — are more important, but I’ll pick simplicity and robustness every time1. A simple and robust store can usually be finessed to map to any data model and can be scaled outward to make up for performance.

The rest of the article focuses on the solution Clipboard employed to making Riak Search scale for the scenario of performing multi-matching search queries across millions of documents. While the very details apply only to Clipboard and Riak Search, the idea of precomputing results or at least modeling data in ways that optimize the most often access scenarios are generally applicable.

  1. My emphasis. I find these two principles to be the core of Riak. 

Original title and link: Riak at Clipboard: Why Riak and How We Made Riak Search Faster (NoSQL database©myNoSQL)