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



dbShards: MPP DBMS on top of MySQL or PostgreSQL

Three articles about dbShards:

  1. Product: DbShards - Share Nothing. Shard Everything

    What Kind Of Customer Are You Targeting With DbShards? Who Ends Up Using Your Product And Why?

    The primary customers for dbShards fit into two categories:

    1. fast-growing Web or online applications (e.g., Gaming, Facebook apps, social network sites, analytics)
    2. any application involved in high volume data collection and analysis (e.g., Device Measurement). Any application that requires high rates of read/write transaction volumes with a growing data set is a good candidate for the technology.

    I’ve checked the customers page and I don’t see any company listed there that corresponds to the first point above. As regards the second category, read on.

  2. dbShards — a lot like an MPP OLTP DBMS based on MySQL or PostgreSQL

    insert performance with dbShards + MySQL + InnoDB is 1500-3000 inserts per shard per second, scaling almost linearly with the number of shards. I forgot to ask how many shards this had been tested for.

    I assume you are aware of some numbers for NoSQL databases. Not to mention the 750k qps NoSQLized MySQL.

    dbShards has good join performance when – you guessed it! – everything being joined is co-located shard-by-shard, because the tables were distributed on the same shard key and/or replicated across each shard. Cory can’t imagine why you’d want to do an inner join under any other circumstances.

    While there’s no surprise in the above quote, I’m not sure how to correlate it with the fact that dbShards targets data analysis clients.

  3. dbShards update

    dbShards’ replication scheme works like this:

    • A write initially goes to two places at once — to the DBMS and a dbShards agent, both running on the same server.
    • The dbShards agent streams to the dbShards agent on the replica server, and receipt of the streamed write is acknowledged.
    • At that point the commits start. (Cory seemed to say that the commit on the primary server happens first, but I’m not sure why.)

    In essence, two-phase database commit is replaced by two-phase log synchronization.

    Anyone could explain how are these different?

I know all this may come out as too negative. But while I think dbShards has a decent set of features, some of the statements out there are not doing it any favors.

Original title and link: dbShards: MPP DBMS on top of MySQL or PostgreSQL (NoSQL databases © myNoSQL)