Cadir Lee (CTO Zynga) quoted in a VentureBeat post:

It’s not the amount of hardware that matters. It’s the architecture of the application. You have to work at making your app architecture so that it takes advantage of Amazon. You have to have complete fluidity with the storage tier, the web tier. We are running our own data centers. We are looking more at doing our own data centers with more of a private cloud.

Couple of thoughts:

1. Zynga is going the opposite direction than Netflix. While Netflix is focusing (by using Amazon for most of their infrastructure), Zynga is diversifying (building their own data centers) .
2. Zynga’s applications are great examples of where fully distributed NoSQL databases fit. Availability is key.
3. My answer to the question: “how many Zyngas are out there” would be: “enough to ensure some good business for the most reliable and scalable distributed databases”
4. Zynga has contributed and is an investor in Membase, the company that merged with CouchOne to form Couchbase. But Zynga was using a custom version of Membase.
5. Zynga also operates a large MySQL cluster.
6. Zynga processes over 15 terabytes of game data every day (according to their SEC filing ). That’s Hadoop sweet spot.

PS: I’d love to talk to someone from Zynga about their data storage approach. If you have any connections I’d really appreciate an introduction.

Original title and link: Zynga, Data Centers, Polyglot Persistence, and Big Data (NoSQL database©myNoSQL)

Lorenzo Alberton with an overview of the NoSQL landscape:

NoSQL databases get a lot of press coverage, but there seems to be a lot of confusion surrounding them, as in which situations they work better than a Relational Database, and how to choose one over another. This talk will give an overview of the NoSQL landscape and a classification for the different architectural categories, clarifying the base concepts and the terminology, and will provide a comparison of the features, the strengths and the drawbacks of the most popular projects (CouchDB, MongoDB, Riak, Redis, Membase, Neo4j, Cassandra, HBase, Hypertable).

VMWare’s Cloud Foundry has the potential to become the preferred PaaS solution. It bundles together a set of services that it took years for other PaaS providers (Google App Engine, Microsoft Azure) to offer. And it seems that Cloud Foundry has much less (or none at all) vendor lock in^[1].

From a storage perspective, Cloud Foundry is encouraging polyglot persistence right from the start offering access to a relational database (MySQL), a super-fast smart key-value store (Redis), and a popular document database (MongoDB). The only bit missing is a graph database^[2].

I think the first graph database to get there will see an immediate bump in its adoption.

Original title and link: Cloud Foundry, NoSQL Databases, and Polyglot Persistence (NoSQL databases © myNoSQL)

Don White¹ in an interview over odbms.org:

The new data systems are very data centric and are not trying to facilitate the melding of data and behavior. These new storage systems present a specific model abstractions and provide their own specific storage structure. In some cases they offer schema flexibility, but it is basically used to just manage data and not for building sophisticated data structures with type specific behavior.

Decoupling data from behavior allows both to evolve separately. Or differently put, it allows one to outlive the other.

Another intersting quote from the interview:

[…] why would you want to store data differently than how you intend to use it? I guess the simple answer is when you don’t know how you are going to use your data, so if you don’t know how you are going to use it then why is any data store abstraction better than another?

I guess this explains the 30 years dominance of relational databases. Not in the sense that we never knew how to use data, but rather that we always wanted to make sure we can use it in various ways.

And that explains also the direction NoSQL databases took:

To generalize it appears the newer stores make different compromises in the management of the data to suit their intended audience. In other words they are not developing a general purpose database solution so they are willing to make tradeoffs that traditional database products would/should/could not make. […] They do provide an abstraction for data storage and processing capabilities that leverage the idiosyncrasies of their chosen implementation data structures and/or relaxations in strictness of the transaction model to try to make gains in processing.

Original title and link: Comparing NoSQL Databases with Object-Oriented Databases (NoSQL databases © myNoSQL)

When checking the ☞ GitHub repository for Grails/GORM entities support for Riak MapReduce I have noticed multiple NoSQL integration projects^[1] :

Grails/GORM and NoSQL databases:

• Gemfire
• JCR
• MongoDB
• Redis
• Riak

Spring Data and NoSQL databases:

• AppEngine
• Cassandra
• Gemfire
• JCR
• MongoDB
• Redis
• Riak

What seems to be missing is the Neo4j support in Spring Data, but maybe there’s a different repo for it.

Finally lots of love for NoSQL database in the Java land.

Original title and link: NoSQL Databases in Grails and Spring Data (NoSQL databases © myNoSQL)

Fantastic presentation from Jon Moore on why Comcast (enterprises?) is not interested in NoSQL databases:

Summarizing:

• it is not for massive scale
• it is not for high performance
• it is not for handling Big Data
• NoSQL databases still carry risks and require more ramp-up and investment
• it is for the distributed nature of NoSQL databases, including multi-data center support
• it is for operational scalability and operational friendliness of NoSQL databases

You can get the PDF from ☞ here.

Jon Moore

Original title and link: Why Comcast is Interested in NoSQL databases (NoSQL databases © myNoSQL)