NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Amazon SimpleDB: All content tagged as Amazon SimpleDB in NoSQL databases and polyglot persistence

Grails 2.0 and NoSQL

Graeme Rocher:

Grails 2.0 is the first release of Grails that truly abstracts the GORM layer so that new implementations of GORM can be used. […] The MongoDB plugin is at final release candidate stage and is based on the excellent Spring Data MongoDB project which is also available in RC form. […] Grails users can look forward to more exciting NoSQL announcements in 2012 with upcoming  future releases of GORM for Neo4j, Amazon SimpleDB and Cassandra in the works.

This is great news.

The very very big news would be a Grails version that doesn’t default anymore to using Hibernate for accessing a relational database.

Original title and link: Grails 2.0 and NoSQL (NoSQL database©myNoSQL)


Centralized Logging With Amazon SimpleDB, Slf4j, and Logback

Store logs in SimpleDB. Amazon SimpleDB is a highly available, flexible and scalable non-relational data store. It is perfect for this situation. It is eventually consistent, write-optimized, highly available and extremely durable. It can handle extremely large tables that can keep the logging data very well. It can query and filter logs. Oh, and it is also really cheap.

Plus, the simpledb-appender is doing the right thing:

Logback is designed to be extremely efficient. simpledb-appender is also designed to have minimal impact on CPU resources. Logging events are buffered in memory and then later at user-configurable intervals (by default 10 seconds) are written to SimpleDB in bulk on a separate thread. In this way calls to the logging API return very quickly, and the time-consuming work is done in a way that doesn’t block the main application. A JVM shutdown hook writes any unwritten log events when the application exits.

Original title and link: Centralized Logging With Amazon SimpleDB, Slf4j, and Logback (NoSQL database©myNoSQL)


NoSQL & Cloud at Netflix

Today Netflix can be seen as a leader in what can be achieved by combining cloud computing and polyglot persistence. Not only that, but Netflix has chosen to share their experience with everyone else so we can all learn from their experience.

Netflix’s experience of migrating from an on-premise architecture using relational databases has been documented over time. Here are a couple of important points in the history of migrating from the classical architecture to the mostly in the cloud solution they are currently using and continuing to experiment and build:

And it doesn’t stop here. In the video below, Siddharth “Sid” Anand covers the answers to some questions that are in the mind of everyone considering NoSQL databases in the cloud:

  • What sort of data can you move to NoSQL?
  • Which NoSQL technologies are we working with?
  • How did we translate RDBMS concepts to NoSQL?

Original title and link: NoSQL & Cloud at Netflix (NoSQL databases © myNoSQL)


Why Netflix Picked Amazon SimpleDB, Hadoop/HBase, and Cassandra

Yury Izrailevsky[1]:

The reason why we use multiple NoSQL solutions is because each one is best suited for a specific set of use cases. For example, HBase is naturally integrated with the Hadoop platform, whereas Cassandra is best for cross-regional deployments and scaling with no single points of failure. Adopting the non-relational model in general is not easy, and Netflix has been paying a steep pioneer tax while integrating these rapidly evolving and still maturing NoSQL products. There is a learning curve and an operational overhead. Still, the scalability, availability and performance advantages of the NoSQL persistence model are evident and are paying for themselves already, and will be central to our long-term cloud strategy.

Summarizing the pros for each of the 3 solutions:

  • Amazon SimpleDB Pros

    • highly durable, writes spanning multiple availability zones
    • handy query and data formats
    • batch operations
    • consistent reads
    • hosted solution
  • HBase Pros

    • dynamic partitioning model
    • built-in support for compression
    • range queries
    • support for distributed counters
    • strong consistency
    • interoperability with Hadoop
  • Cassandra Pros

    • no dedicated name nodes
    • no practical architectural limitations on data sizes, row/column counts, etc.
    • flexible data model
    • no underlying storage format requirements like HDFS
    • uniquely flexible consistency and replication models
    • cross-datacenter and cross-regional replication

I hope the next post will be about the “small” issues Netflix ran into when adopting each of these systems. In the past they’ve shared some of the challenges of an Oracle - Amazon SimpleDB hybrid solution.

  1. Yury Izrailevsky: Netflix Director of Cloud and Systems Infrastructure  

Original title and link: Why Netflix Picked Amazon SimpleDB, Hadoop/HBase, and Cassandra (NoSQL databases © myNoSQL)


Amazon SimpleDB, MongoDB, CouchDB, and RavenDB Compared

I wanted to share this before the weekend is over: Jesse Wolgamott’s video: “Battle of NoSQL starts: Amazon’s SDB vs MongoDB vs CouchDB vs RavenDB” from September’s Lone Star Ruby Conference.

You can download the video from the Confreaks site for watching offline.

Original title and link: Amazon SimpleDB, MongoDB, CouchDB, and RavenDB Compared (NoSQL databases © myNoSQL)