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



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

F1 and Spanner: A Distributed SQL Database That Scales

A very good summary of the goals, interactions and collaboration between F1 and Spanner by Srihari Srinivasan:

With both the F1 and Spanner papers out its now possible to understand their interplay a bit holistically.

Original title and link: F1 and Spanner: A Distributed SQL Database That Scales (NoSQL database©myNoSQL)


Amazon Preparing 'Disruptive' Big Data AWS Service?

Interesting speculation by The Register:

AWS already has the AWS Data Pipeline, which helps administrators schedule and shuttle data among various services, AWS Redshift for data warehousing which lets people store large quantities of data in the cloud and run queries on it, its NoSQL SSD-backed DynamoDB, and its Relational Database Service (RDS). So where does MADS fit?

The Reg’s take is that MADS will allow Amazon to build services that can net together the above components and help automate the passing of data among them. It may also become a standalone product in its own right, based on its similarities to the TransLattice and Google Spanner tech.

I almost never bet, but I’d say this could be Amazon’s Spanner.

Original title and link: Amazon Preparing ‘Disruptive’ Big Data AWS Service? (NoSQL database©myNoSQL)


Todd Hoff on Google Spanner's

Todd Hoff of

What struck me most in the paper was a deeply buried section essentially describing Google’s motivation for shifting away from NoSQL and to NewSQL. The money quote:

We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

That’s one piece of the Spanner paper that’s catching everyone’s attention. I’m wondering how much of this reference to transactions refers to:

  1. multi-operations transactions
  2. synchronous replication
  3. data strong consistency

Original title and link: Todd Hoff on Google Spanner’s (NoSQL database©myNoSQL)


Building Spanner Presentation

Alex Lloyd’s talk from Berlin Buzzwords 2012 about Google’s Spanner:

Cloudant's Mike Miller on Google Spanner

Cloudant’s Mike Miller sharing his thoughts about Google’s Spanner paper:

Spanner’s key innovation is around time. It includes a novel system using GPS and Atomic Clocks to distribute a globally synchronized “proper time.” The previous dogma in distributed systems was that synchronizing time within and between datacenters is insurmountably hard and uncertain. Ergo, serialization of requests is impossible at global scale. Google’s key innovation is to accept uncertainty, keep it small (via atomic clocks and GPS), quantify the uncertainty and operate around it. In retrospect this is obvious, but it doesn’t make it any less brilliant.

Original title and link: Cloudant’s Mike Miller on Google Spanner (NoSQL database©myNoSQL)