think differently big

The NoSQL Blog

Just in case you missed it so far, back in December I have started myNoSQL a NoSQL blog featuring the best daily NoSQL news, articles and links covering all major NoSQL projects and following closely all things related to NoSQL ecosystem. Everything you need and want to know about NoSQL.

Tokyo Tyrant Through The Eyes of MySQL Experts

After writing about MonetDB and InfoBright, the MySQL Performance guys are now taking a look at ☞ Tokyo Tyrant, the network interface of the NOSQL Tokyo Cabinet solution.

Their observations span 3 articles (☞ part 1, ☞ part 2 and ☞ part 3) and cover subjects like data durability (the D in ACID), read and write performance.

And if I mentioned Tokyo Cabinet, I should point you to a presentation given by Ilya Grigorik (of PostRank): ☞ Lean & Mean Tokyo Cabinet Recipes

Then if you have another 57minutes, you can watch the O’Reilly Webcast: Tokyo Cabinet in One Hour:

A Thought about KV and Column-based Solutions

This is just a quick thought I had this morning: KV (key-value) storage solutions are excelling at item-based read/write throughput, but suck at everything that involves range queries. The column-based storage solutions might probably not have the same read/write throughput, but have a better chance at offering range queries.

I’ll probably have to check this by looking at some of the solutions included in the NOSQL reference.

Meanwhile, what do you think? Are there any other upfront ‘advantages’?

The NoSQL Environment

Jonathan Ellis (Rackspace) has published a ☞ review of the options available in the NoSQL space. If you are interested in getting a better picture of this NoSQL environment you’ll probably find these other articles useful: quick reference to alternative data storages and alternative data storage status quo

A NoSQL Taxonomy

Steven Yen included in his ☞ presentation (pdf) the following NOSQL taxonomy:

• key‐value‐cache
  • memcached
  • repcached
  • coherence
  • infinispan
  • eXtreme scale
  • jboss cache
  • velocity
  • terracotta
• key‐value‐store
  • keyspace
  • flare
  • schema‐free
  • RAMCloud
• eventually‐consistent key‐value‐store
  • Amazon Dynamo
  • Project Voldemort
  • Dynomite
  • SubRecord
  • Mo8onDb
  • Dovetaildb
• ordered‐key‐value‐store
  • tokyo tyrant
  • lightcloud
  • NMDB
  • luxio
  • memcachedb
  • actord
• data‐structures server
  • redis
• tuple‐store
  • gigaspaces
  • coord
  • apache river
• object database
  • ZopeDB
  • db4o
  • Shoal
• document store
  • CouchDB
  • Mongo
  • Jackrabbit
  • XML Databases
  • ThruDB
  • CloudKit
  • Perservere
  • Riak Basho
  • Scalaris
• wide columnar store
  • BigTable
  • Hbase
  • Cassandra
  • Hypertable
  • KAI
  • OpenNeptune
  • Qbase
  • KDI

I think the only one missing the graph-oriented storage which is the solution provided by neo4j

ACID vs BASE

As we all know traditional relational databases are implementing the ACID principles: atomicity, consistency, isolation, durability. Then there came Brewer’s CAP (consistency, availability and partition tolerance) conjecture that was leading the road towards BASE systems (basically available, soft state, eventually consistent).

Here are a couple of great resources about BASE:

BASE: An Acid Alternative by Dan Pritchett ☞

Eventually Consistent by Werner Vogels ☞

Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services by Seth Gilbert and Nancy Linch

Thanks Debasish Ghosh ☞ for the links. You should also check the NoSQL, Relational and Storage in General entry.