That statement has to do with a particular type of data, the kind that gets generated copiously in a day’s activity on the Internet. Each day sees 15 million tweets, 60 million Facebook updates and 1.6 billion people active online in a variety of other ways. It’s hard for relational systems to keep up. Relational systems have to work hard at decomposing this data, storing it in tables and building indexes on it — they work so hard on it that you don’t really want your system to undertake the task. It’s too expensive.

“When you scale up relational systems, you introduce single points of failure… You lose the advantage of their precision but you gain the overhead,” as you try to make the system work on a larger and larger data set, said John Quinn, VP of engineering at Digg, the social networking site, and lead off speaker at the Under the Radar’s cloud event April 16 on the Microsoft Campus in Mountain View, Calif.

Those NoSQL systems you’ve been hearing about, on the other hand, scale out by distributing their operations across more nodes in a server cluster. “There’s nothing wrong with relational database…You just need to use the right tool for the right job,” Quinn said, throwing in the fact that NoSQL stands for “Not Only SQL,” although there were a few knowing smiles at that one.

Quinn is a leading member of the generation that doesn’t want to try to capture terabytes of data with relational systems. He prompted the changeover from the MySQL open source relational database at the social networking site, Digg, to Cassandra, a key value store system. Cassandra performs many of the data sorting operations of a relational database but allows data reads to be done in advance of full updates. The practice sometimes leads to momentary consistency problems, since one user of the data might get a version that differs slightly from the next one, although both sought identical sets.

The large, distributed key value store system “sacrifices consistency to slave lag,” or tolerates the lapse between when an update occurs on a distributed node and when it’s replicated on other servers. In most NoSQL systems, assured consistency is less an issue — and less a virtue — than in relational systems.

The NoSQL approach allows “tune-able consistency. You can trade off consistency for speed,” Gunn noted.

Because a server in a NoSQL system automatically creates duplicates of the data on at least one other node, a server in the cluster can fail and no data is lost, the NoSQL system keeps processing and an application keeps running. In addition to Cassandra, MongoDB, Voldemort, and CouchDB are NoSQL systems in the public arena. Google and Amazon operate their own internally.

Gunn did implicitly point to a potential NoSQL shortcoming. Although indexes are associated with relational systems, if you do need an index, you may need an external system to build it. So far, the NoSQL systems have only rudimentary indexing.

That’s why the NoSQL enthusiasts say their systems are not for financial or other time-sensitive transactions. Relational systems are. On the other hand, if you’re updating your Zynga Farmville plot, then Cassandra makes a lot of sense for capturing that information.

Of 24 companies presenting at this event, six had a big data handling, analytics or storage systems in mind. They included Sones, Cloudant, GenieDB, GoodData, neotechnology and Maxiscale.

Each start-ups presented their business and product plans in six minutes at the event, then faced questioning from a three-judge panel of reviewers.

Source

Perhaps our most significant infrastructure change is abandoning MySQL in favor of a NoSQL alternative. To someone like me who’s been building systems almost exclusively on relational databases for almost 20 years, this feels like a bold move.
What’s Wrong with MySQL?

Our primary motivation for moving away from MySQL is the increasing difficulty of building a high performance, write intensive, application on a data set that is growing quickly, with no end in sight. This growth has forced us into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead.

Relational database technology can be a blunt instrument and we’re motivated to find a tool that matches our specific needs closely. Our domain area, news, doesn’t exact strict consistency requirements, so (according to Brewer’s theorem) relaxing this allows gains in availability and partition tolerance (i.e. operations completing, even in degraded system states). We’re confident that our engineers can implement application level consistency controls much more efficiently than MySQL does generically.

As our system grows, it’s important for us to span multiple data centers for redundancy and network performance and to add capacity or replace failed nodes with no downtime. We plan to continue using commodity hardware, and to continue assuming that it will fail regularly. All of this is increasingly difficult with MySQL.
Choosing an Alternative

Digg is committed to the use and development of open source software and we’re keen to avoid the cost of proprietary large-scale storage solutions. We were inspired by Google and Amazon’s broad use of their non-relational BigTable and Dynamo systems. We evaluated all the usual open source NoSQL suspects. After considerable debate, we decided to go with Cassandra.

Simplistically, Cassandra is a distributed database with a BigTable data model running on a Dynamo like infrastructure. It is column-oriented and allows for the storage of relatively structured data. It has a fully decentralized model; every node is identical and there is no single point of failure. It’s also extremely fault tolerant; data is replicated to multiple nodes and across data centers. Cassandra is also very elastic; read and write throughput increase linearly as new machines are added.

We experimented on our live site, replacing a relatively high scale MySQL component with a Cassandra alernative. These tests went well. You can read more about these experiments here.
Where We Are

At the time of writing, we’ve reimplemented most of Digg’s functionality using Cassandra as our primary datastore. We’ve supplemented Cassandra-based indexing using full text, relational and graph indexing systems. We’re getting used to dealing with eventual consistency.

We’ve been working on Cassandra itself too. We’ve made massive performance improvements: increased comparitor speed, added better compaction threading, reduced logging overhead, added row-level caching and implemented multi-get capability. We’ve also implemented native atomic counters using Zookeeper (you can probably guess why were motivated to add that feature :)

We’ve tested and improved the operational capabilities of Cassandra, upgrading its Rackaware capability, added slow query logging, improved the bulk import functionality and implemented Scribe support for improved logging. We’ve also done a ton of operational testing.

We’re open sourcing all our work on Cassandra.
What’s Next?

Currently our main focus is getting Digg’s latest release into general availability, but we’ll continue to lead the way in championing Cassandra’s development and adoption.

If you’re interested in joining a world-class team using cutting edge, NoSQL technology at scale, check out http://jobs.digg.com

Take it easy,
John Quinn. VP Engineering. (Digg: doofdoofsf, Twitter: doofdoofsf)

Source

Check the source for details on various types of NoSQL.

Source