Stancey Schneider for VMware:

Over the past few years, memory has gotten cheap and is easily commoditized in the cloud. So moving your data strategy to put it all in-memory just plain makes sense. It eliminates an extra hop to read and write data from disk, making it inherently faster and the performance more consistent. It also manages to simplify the internal optimization algorithms and reduce the number of instructions to the CPU making better use of the hardware.

This is the “conclusion” after “establishing” in the post that:

1. traditional databases are already broken because of the fixed schemas and data being persisted on disk
2. NoSQL databases are also broken because even if they have flexible schemas, data is still persisted on disk and “replication takes time to do all the read and writes”
3. NewSQL are also broken because “the way the databases handles the data distribution makes it so there NewSQL databases do not scale linearly”

All this FUD just to promote GemFire and SQLFire? I really thought VMware is a serious company.

Original title and link: Traditional, NoSQL and NewSQL Are All Broken. All Data in Memory (NoSQL database©myNoSQL)

via: http://blogs.vmware.com/vfabric/2013/03/why-every-database-must-be-broken-soon.html

The most sincere, simple, and correct list of pros and cons about NoSQL databases and RDBMS. Hat tip to Kelly Martinez.

Original title and link: Why I Love and Hate NoSQL and RDBMS Databases (NoSQL database©myNoSQL)

via: http://www.zero1design.com/2013/01/21/why-i-lovehate-nosql-and-rdbms-databases-not-a-versus-post/

The interview Dmitry Sotnikov¹ had with Monty Widenius was published on so many places that I had a hard time deciding which to link to. Anyways, there are a couple of comments and corrections that I’d like to suggest:

The whole thing with the “new NoSQL movement” started with a blog post from a Twitter employee that said MySQL was not good enough and they needed “something better,” like Cassandra.

That’s not quite correct. The “NoSQL movement” debuted in 2009 when the guys from Last.fm organized an event about “open source, distributed, non relational databases” where they invited people from companies like Cloudera, LinkedIn, StumbleUpon, etc. to talk about the solutions they were building to responde to their platforms’ special requirements. But as papers like Bigtable: A distributed storage system for structured data and Dynamo: Amazon’s Highly Available Key-value Store prove, NoSQL solutions have been in production way before 2009.

I can’t find the original article, but I did find a follow up a bit later where it was said MySQL would be dropped for Cassandra.

I can help find that article as it was posted on this blog: Cassandra @ Twitter: An Interview with Ryan King

The main reason Twitter had problems with MySQL back then, was that they were using it incorrectly.

I don’t think there are many examples in the history of software where a private platform benefited from more scaling advice than Twitter. Judging by how many solutions have been suggested, a possible Twitter IPO will be at risk of IP law suites.

The current state is that now, three years later, Twitter is still using MySQL as their main storage for tweets. Cassandra was, in the end, not able to replace MySQL.

That’s true. What’s also true is that at that time Cassandra was at version 0.9 and and that having to invest into a new databases was considered riskier than investing into more hardware and hiring MySQL experts.

The main reason NoSQL became popular is that, in contrast to SQL, you can start using it without having to design anything. This makes it easier to start with NoSQL, but you pay for this later when you find that you don’t have control of your data (if you are not very careful).

I assume that this is how a vendor would present flexible data models as a drawback. It is also one of the most dangerous misconceptions about NoSQL, i.e. NoSQL databases require no data modeling. The reality is that most of the time using a NoSQL database will require a lot more thinking and analysis of the data models and data access patterns. There are no blueprints, no normalized forms, and no ORMs to hide everything away.

As soon as data can’t fit into memory, SQL generally outperforms NoSQL.

Where’s the proof? According to the data I have, there’s no comparison between let’s say Cassandra and MySQL.

For anything else, you have to write a program and it’s very hard to beat a SQL optimizer for complex things, especially things that are automatically generated based on user requests (required for most web sites).

That’s true. Except when:

1. most of the people don’t know how to write those SQL queries—search StackOverflow for a random sample of what I mean
2. getting everything out of your database requires using vendor specific solutions
3. there’re those moments when the optimizer decides to change the execution plan in such a way that brings down your whole service

The problem with Hadoop is that there is no known business model around it that ensures that the investors will get back 10X money that they expect. Because of that, I have a hard time understanding how Cloudera can survive in the long run.

???

Everything else in the interview is spot on.

Original title and link: Monty Widenius About NoSQL, Big Data, and Obvioulsy MySQL and MariaDB (NoSQL database©myNoSQL)

via: http://blog.jelastic.com/2013/01/21/are-nosql-and-big-data-just-hype/

So how can big companies get in on the action? Let’s contrast the nature of data suited for NoSQL with the properties of enterprise data that requires the single-source-of-truth systems that we talked about. We’ll use three V’s: volume, velocity, and variety.

Just in case you want to read an InformationWeek post with no start, no end, and no logic, but (ab)using all the necessary buzzwords.

Original title and link: NoSQL Everywhere? Not So Fast (NoSQL database©myNoSQL)

via: http://www.informationweek.com/news/software/info_management/232901328?printer_friendly=this-page

Pedro Visintin:

We can distinguish several objects: Session, Cart, Item, User, Order, Product and Payment. Usually we use ActiveRecord to store all of them. But this time let’s think about it differently.

For sessions, we don’t need durable data at all — Redis can be a good option, and of course will be faster than any RDBMS. For Cart and Item,we will need high availability across different locations. Riak can fit well for this use case. For User Order Product and Payment, a relational database can fit well, focusing on Transactions and Reporting about our application.

This is a very good exercise for understanding the requirements for your data service layer. As much as I write about polyglot persistence, when architecting an application never leave aside or ignore the operational requirements for your service.

Original title and link: A Different Approach to Data Modeling: Thinking of Data Service Requirements (NoSQL database©myNoSQL)

via: http://news.dice.com/2012/04/06/nosql-and-sql/

Three paterns of making a relational database behave like a document database. Useful in the times there were no document databases around.

If we were to use a relational database we might end up with a single table with an ungodly amount of columns so that each event has all its specific columns available. But we will never use all columns for one event of course. Maybe try to re-use columns, and call them names like column1, column2 etc. Hmm… sounds like fun to maintain and develop against.

The other pattern would be to start creating a normalized schema with multiple tables – probably one per game, and one per even type etc. So then we end up with a complex schema that needs to be maintained and versioned. Inserts and selects will be spread across tables and for sure we need to change the schema when new games or events are introduced.

There is also a third pattern out there which is to store a binary blob in the database… lets not even talk about that one.

Original title and link: Design Your Database Schema (NoSQL database©myNoSQL)

via: http://www.cubeia.com/index.php/blog/archives/436

Dr. C. Mohan’s first post about NoSQL databases:

Having worked in the database field for more than 3 decades with a fair amount of impact on the research and commercial sides of this field (see bit.ly/cmohan), it pains me to see the casual way in which some designs have been done and some supposedly new ideas get proposed/implemented. Not enough efforts are being made to relate these proposals to what has been done in the past and benefit from the lessons learnt in the context of RDBMSs. Not everything needs to be done differently just because it is supposedly a very different world now! 

There are evolutionary and revolutionary products. And sometimes changing the perspective and starting from scratch is needed to validate or invalidate new or old time hypothesis. In the world of polyglot persistence there’s space for every solution that solves real problems. As perfect as one product could be it will not be able to address all the needs. The data storage space is not a zero-sum game. Winners don’t take it all.

Original title and link: The NoSQL Hoopla … What Is NonsenSQL About It? (NoSQL database©myNoSQL)

via: http://cmohan.tumblr.com/post/20141910210/the-nosql-hoopla-what-is-nonsensql-about-it

I recently added a fairly feature rich Graph Database to AlchemyDB (called it LuaGraphDB) and it took roughly 10 days to prototype. I implemented the graph traversal logic in Lua (embedded in AlchemyDB) and used AlchemyDB’s RDBMS to index the data. The API for the GraphDB is modeled after the very advanced GraphDB Neo4j. Another recently added functionality in AlchemyDB, a column type that stores a Lua Table (called it LuaTable), led me to mix Lua-function-call-syntax into every part of SQL I could fit it into (effectively tacking on Document-Store functionality to AlchemyDB). Being able to call lua functions from any place in SQL and being able to call lua functions (that can call into the data-store) directly from the client, made building a GraphDB on top of AlchemyDB possible as a library, i.e. it didn’t require any new core functionality.

Two reasons for posting about it:

1. relaxing contraints of the relational model can make a RDBMS partially adapt to other models (nb: this is just re-inforcing an old strategy used by)
2. usually dismissed for the lack of portability in the RDBMS world, server side scripting support is an extremely powerful tool. Having processing close to data (i.e. data locality) is a well known advantage, but as shown in this post and in creating reliable queues with Redis Lua scripting it can open the doors to completely new features.

Original title and link: AlchemyDB: An Integrated GraphDB + RDBMS + KV Store + Document Store (NoSQL database©myNoSQL)

via: http://jaksprats.wordpress.com/2012/02/28/lightweight-oltp-data-platform/

Before we begin, I am going to ask a question of the reader, “do you have a data description document?” Something in writing (written down, not just in your head) that describes your data requirements and how you will be using your data. I know that some people are thinking that I want you to have a E-R diagram fully developed, that is not the case. I just want the reader to have some sense what data they will be working with, how is that data related (or not), what they need to do with the data, etc. If you know those things then you will be able to determine what issues are relevant to you and how important are they.

It’s impossible to use just a checklist to decide between a NoSQL database and relational database, but at least this post lists the main chapters you need to consider before making a decision. Keep in mind that the devil (read complexity) is in the details though.

Original title and link: MongoDB or Relational Database: That Is the Question (NoSQL database©myNoSQL)

via: http://chuckjohnson.wordpress.com/2012/03/19/to-sql-relational-or-not-to-sql-nosql-that-is-the-question/

Maggie Nelson:

Here are a couple of examples of using MySQL in interesting (and it’s up to you whether unwise) ways:

• MySQL as a graph database, like Twitter’s FlockDB.
• MySQL as document store, like FriendFeed’s extremely custom schema design.
• MySQL as a key/value store. This lets you play with NoSQL concepts using MySQL.

Such examples abound. In fact most of the companies known for their contributions or using NoSQL databases run some sort of interesting relational database deployment. Most of the time these examples are interpreted as clear proof that relational databases can solve any problem. Reality is different though: the engineers’ long time familiarity with relational databases allowed them to ingeniously overpass their limitations when lacking better alternatives. But with NoSQL databases getting more mature every day, less and less problems require acrobatic usages of relational databases.

Original title and link: Examples of Using MySQL in Interesting Ways (NoSQL database©myNoSQL)

via: http://phpadvent.org/2011/out-with-the-old-by-maggie-nelson