items that can be stored and retrieved • What can the system store? • Opaque data, documents? • What kind of queries can you do? • E.g . SQL is based on relational algebra
and then replicated • Replication can provide read scalability • Writing becomes a bottleneck • Physical limitations (seek time) • Throughput of a single I/O subsystem
via hashing • Set up a duplicate system for each shard • The write-rate limitation now applies to each shard • Joins or aggregation across shards are problematic • Can the data be re-sharded on a live system? • Can shards be re-balanced on a live system?
a primary (master) • Failure of the primary is detected, and a new one is elected • Application writes get an error if there is no quorum to elect a new master • Reads can continue
• Files are allocated as needed • Documents in a collection are kept on a list using a geographical addressing scheme • Indexes (B*-trees) point to documents using geographical addresses
- August 2009 • v1.2 - December 2009 - Map/Reduce, lots of small things • v1.4 - March 2010 - Concurrency/Geo • V1.6 - August 2010 - Sharding/Replica Sets • V1.8 – March 2011 – Journaling, Covered/Sparse indexes, Geo sphere
index • Find points near a given point • Find points within a polygon/sphere • Built-in Map-Reduce • The caller provides map and reduce functions written in JavaScript
Replica Sets • Sharding – Read and write scalability • Collections are sharded • Each shard is served by its own replica set • Shard key ranges are automatically balanced