scalability: All content tagged as scalability in NoSQL databases and polyglot persistence
Even if not focused on NoSQL, the videos from the Surge conference are covering very interesting aspects related to scalability. Here are a couple of examples:
- Theo Schlossnagle: Scalable Design Patterns
- Justin Sheehy: Embracing Concurrency at Scale
- Ronald Bradford: The most common MySQL scalability mistakes, and how to avoid them
- Ruslan Belkin: Going 0 to 60: Scaling LinkedIn
- Robert Treat: Database Scalability Patterns
- Artur Bergman: Scaling and Loadbalancing Wikia Across The World
- Mike Malone: Working with Dimensional Data in a Distributed Hash Table
- Gavin M. Roy: Scaling myYearbook.com - Lessons Learned From Rapid Growth
- Benjamin Black: Go with the flow - Meditations on network infrastructure analysis
- John Allspaw: The “Go or No-Go”: Operability and Contingency at Etsy
- Rod Cope: Top 10 Lessons Learned from Deploying Hadoop in a Private Cloud
Last but not least there’s also a “SQL vs NoSQL” panel featuring Geir Magnusson Jr (Moderator), Robert Treat, Baron Schwartz, Mike Malone and Justin Sheehy.
From thechangelog podcast:
- MongoDB roadmap: MongoDB 2.0 will be focusing on concurrency, aggregation, online compaction, and TTL temporal collections
- MongoDB single server durability as the most awaited feature of the recent MongoDB 1.8 release
- MongoDB compared with Riak and CouchDB
- MongoDB geo support
And it is cool that Eliot and 10gen think the Web Scale meme is all in good fun.
Original title and link: MongoDB, NoSQL, and Web Scale with 10gen CTO Eliot Horowitz (NoSQL databases © myNoSQL)
Jim Webber has published a series of posts — here, here, and here — discussing generic graph sharding solutions, the route Neo4j is taking for addressing this problem, and, in the last post, a simple strategy — suggested by Mark Harwood — for deciding a graph database scaling approach:
Dataset size: Many tens of Gigabytes
Strategy: Fill a single machine with RAM
Dataset size: Many hundreds of Gigabytes
Dataset size: Terabytes and above
Strategy: Domain-specific sharding
The cache sharding approach — described here — suggests replacing the problem of graph sharding with “the simpler problem of consistent routing”. But I’m not sure how this solution works effectively:
- if there is a way to provide consistent routing isn’t that equivalent with having an solution for sharding the graph?
- considering graph databases are chatty — in the sense that most of the time there is a complex traversal happening — how smart should the client and the router be to work effectively and efficiently?
For now I feel that being able to solve the consistent routing in a graph implies having a strategy for sharding a graph. The reverse applies too: having a sharding strategy would provide a routing solution. Thus scaling graph databases remains a subject open for research.
Original title and link: Scaling Graph Databases: Sharding and Consistent Routing (NoSQL databases © myNoSQL)
I know this will sound like bashing MongoDB. But I’ve already said it a couple of times: MongoDB scaling looks complicated.
People coming to MongoDB think their scalability issues are of no concern as MongoDB supports auto-sharding and replica sets. I would advise everyone to check the MongoDB mailing list before relaxing:
- “Huge collection is not balanced across shards” here
- “Questions on Enabling Sharding on a Database (pre-sharded configuration)” here
- “mongodb crash when new shard is added” here
- “Shards Unevenly balanced” here
- “Imbalance on auto-sharding” here
- “Sharding woes - All chuncks stuck on one shard”
- “sharding makes reads/writes slower” here
It takes time to perfect complicated solutions and it is your job to verify the current status. Hopefully the next version, MongoDB 1.8.0 will address many of these issues. As it’ll also do with single server durability.
In the light of publicly announcing customers, I wanted to read a bit about Clustrix Clustered Database Systems.
The company homepage is describing the product:
- scalable database appliaces for Internet-scale work loads
- Linearly Scalable: fully distributed, parallel architecture provides unlimited scale
- SQL functionality: full SQL relational and data consistency (ACID) functionality
- Fault-Tolerant: highly available providing fail-over, recovery, and self-healing
- MySQL Compatible: seamless deployment without application changes.
All these sounded pretty (
too) good. And I’ve seen a very similar presentation for Xeround: Elastic, Always-on Storage Engine for MySQL.
So, I’ve continued my reading with the Sierra Clustered Database Engine whitepaper (PDF).
Here are my notes:
- Sierra is composed of:
- database personality module: translates queries into internal representation
- distributed query planner and compiler
- distributed shared-nothing execution engine
- persistent storage
- NVRAM transactional storage for journal changes
- inter-node Infiniband
- queries are decomposed into query fragments which are the unit of work. Query fragments are sent for execution to nodes containing the data.
- query fragments are atomic operations that can:
- insert, read, update data
- execute functions and modify control flow
- perform synchronization
- send data to other nodes
- format output
- query fragments can be executed in parallel
- query fragments can be cached with parameterized constants at the node level
- determining where to sent the query fragments for execution is done using either range-based rules or hash function
- tables are partitioned into slices, each slice having redundancy replicas
- size of slices can be automatically determined or configured
- adding new nodes to the cluster results in rebalancing slices
- slices contained on a failed device are reconstructed using their replicas
- one of the slices is considered primary
- writes go to all replicas and are transactional
- all reads fo the the slice primary
The paper also exemplifies the execution of 4 different queries:
SELECT * FROM T1 WHERE uid=10 SELECT uid, name FROM T1 JOIN T2 on T1.gid = T2.gid WHERE uid=10 SELECT * FROM T1 WHERE uid<100 and gid>10 ORDER BY uid LIMIT 5 INSERT INTO T1 VALUES (10,20)
- who is coordinating transactions that may be executed on different nodes?
- who is maintains the topology of the slices? In case of a node failure, you’d need to determine:
- what slices where on the failing node
- where are the replicas for each of these slices
- where new replicas will be created
- when will new replicas become available for writes
- who elects the slice primary?
Kristina Chodorow’s giving the serious version of MongoDB is web scale in an O’Reilly webcast: scaling with MongoDB: