Oren Eini¹:

Why the history lesson, you ask? Why, to give you some perspective on the design choices that led to the victory of the relational databases. Space was at a premium, the interaction between the user and the application closely modeled the physical layout of the data in the database. That made sense, because there really were no other alternatives given the environment that existed at the time.

In my company, we are using RavenDB as the backend database for everything from a blog, our ordering and purchasing systems, the daily build server and many more. The major advantages that we found weren’t the ability to scale (although that exists), it is the freedom that it gives us in terms of modeling our data and changing our minds.

The Googles, Facebooks, and Amazons told the story of this was not our relational database vendors’ fault. Jan Lehnardt² said a while back that NoSQL is about choice. I said that NoSQL databases are a departure from having just good enough solutions. And Oren Eini is emphasizing the benefits of other data models.

Original title and link: Why NoSQL Databases Are Not Just For Google and Amazon? (NoSQL database©myNoSQL)

via: http://java.dzone.com/articles/why-nosql-not-just-google-and

Terence Siganakis:

I have been playing around with Hybrid Word Aligned Bitmaps for a few weeks now, and they turn out to be a rather remarkable data structure.  I believe that they are utilized extensively in modern column oriented databases such as Vertica and MonetDB. Essentially HWABs are a data structure that allows you to represent a sparse bitmap (series of 0’s and 1’s) really efficiently in memory.  The key trick here is the use of run length encoding to compress the bitmap into fewer bits while still allowing for lightening fast operations.  

The comment thread discusses a couple of reasons for column databases being faster than row-oriented databases and some scenarios where this is not happening.

Terence Siganakis links to FastBit: An efficient compressed Bitmap index technology :

FastBit is an open-source data processing library following the spirit of NoSQL movement. It offers a set of searching functions supported by compressed bitmap indexes. It treats user data in the column-oriented manner similar to well-known database management systems such as Sybase IQ, MonetDB, and Vertica.

Original title and link: Hybrid Word Aligned Bitmaps: Why are column oriented databases so much faster than row oriented databases? - (NoSQL database©myNoSQL)

via: http://siganakis.com/using-bitmap-indexes-in-query-processing

Google is actively researching ways to improve TCP:

Our research shows that the key to reducing latency is saving round trips. We’re experimenting with several improvements to TCP. Here’s a summary of some of our recommendations to make TCP faster:

1. Increase TCP initial congestion window to 10 (IW10). The amount of data sent at the beginning of a TCP connection is currently 3 packets, implying 3 round trips (RTT) to deliver a tiny 15KB-sized content.
2. Reduce the initial timeout from 3 seconds to 1 second.
3. Use TCP Fast Open (TFO).
4. Use Proportional Rate Reduction for TCP (PRR).

The database world attacked the network latency with connection pools and pipelining. For reducing network round trips we’ve used JOINs or denormalized data. But all software architectures will benefit from a faster TCP.

Andrei Savu

Original title and link: Google Research: Let’s Make TCP Faster (NoSQL database©myNoSQL)

via: http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html

A different, unified look at the data model of the key-value stores, document databases, and column-family stores from Martin Fowler:

there’s a big similarity between the first three - all have a fundamental unit of storage which is a rich structure of closely related data: for key-value stores it’s the value, for document stores it’s the document, and for column-family stores it’s the column family. In DDD terms, this group of data is an aggregate.

The aggregate approach was present in the relational databases world for quite a while. It came in two flavors: views and denormalization. The first one worked well for non-distributed deployments, while the second is used everywhere the speed or the usage of joins was not an option.

Original title and link: Key-Value Stores, Document Databases, and Column Stores as Aggregate Oriented Databases (NoSQL database©myNoSQL)

via: http://java.dzone.com/articles/aggregate-oriented-database

Wise words from Sid Anand:

Many of the NoSQL vendors view the “battle of NoSQL” to be akin to the RDBMS battle of the 80s, a winner-take-all battle. In the NoSQL world, it is by no means a winner-take-all battle. Distributed Systems are about compromises.

While there might be some that would like to see a NoSQL battle and at some point money will talk, I hope the real battle will remained centered around the technical aspects and which data solutions solve each specific problem better. The sort of battle in which everyone learns something.

Original title and link: The State of NoSQL in 2012 (NoSQL database©myNoSQL)

via: http://practicalcloudcomputing.com/post/16109041412/the-state-of-nosql-in-2012

Alexander Bresk:

The neuron based data structure (called NBDS) follows the idea, to keep an information as an atomic part. The model contains three parts. The first part is the Neuron, which acts like a container for data. The second part is the Axon. This axon connects two neurons together and it can still contain information (data about the connection or relation). The last part is the Space. In a Space you put neurons and axons together and run some operations on it. You can imagine the space as a component, that brings the order into the set of neurons and axons.

You’ll find all these features in any graph database.

Original title and link: Neuron Based Data Structure – an Implementation (NoSQL database©myNoSQL)

via: http://www.cip-labs.net/2011/12/14/neuron-based-data-structure-an-implementation/

On the surface it would appear that building such a system would be easy since the card vault can be implemented in a data store (either RDBMS or noSQL store) and the data stores schema could be simple, containing just the PAN, token and perhaps some timestamp information. There are plenty of companies that have attempted to build their own card vaults and many vendors offering commercial products. However we shall see later in this article that designing a card vault it requires a distributed data store and a decision is needed on which compromises of the CAP Theorem your system is willing to accept.

Firstly a small correction to the original post: instead of “partition tolerance is not an option”, read “partition tolerance is not optional”.

One of the most frequently asked question about NoSQL databases is “how do they handle transactions. Like in a banking system”. I’ve never developed a banking system, so I don’t know how those work. But I’d bet most of those asking haven’t worked on one either. So why not asking about the solution a NoSQL database would require for the system you are actually working on.

Original title and link: Card Payment Sytems and the CAP Theorem (NoSQL database©myNoSQL)

via: http://superconductor.voltage.com/2011/12/tokenization-of-credit-card-numbers-and-the-cap-theorem.html