MS SQL, MySQL, Posrgres ... Amazon Dynamo derivatives: Cassandra, Voldemort, Riak Neo4J, Google BigTable and Google BigTable derivatives: MongoDB, HBase, Redis, ...
Document Column Short Description Developed and supported by 10gen Open source Written in C++ Initial release 2009 Initially developed by Facebook. Now Apache Cassandra Project Open source Written in Java Initial release 2008 Paid support by DataStax Best Use Content/product management, dynamic queries Write often, read less Key Points Schema less. Retains some properties of SQL such as query and index. High availability. Almost linear scales. SQL-like query language. Tunable consistency and flexible schema
• BSON Documents Binary serialized JSON with additional data types like Date, BinData, ObjectId Document size up to 16Mb Field names stored in each document
byte[] - is base type for keys, column name and values. Validators for Strings, Primitives - long, float, etc. Rows could be wide - up to 2 billions You can think about Row as SortedMap<ColumnName,ColumnValue> • Schema strict (CQL - SQL like syntax) String column names Set, List, and Map of Strings/Primitives
byte[] - is base type for keys, column name and values. Validators for Strings, Primitives - long, float, etc. Rows could be wide - up to 2 billions You can think about Row as SortedMap<ColumnName,ColumnValue> • Schema strict (CQL - SQL like syntax) String column names No direct wide rows support Set, List, and Map of Strings/Primitives
less Schema strict/less BSON Wide rows (up to 2 Billions), Blobs or Set, List, Map of primitives Document size up to 16M Column value several megabytes. Row up to 2 GB Length of field names does matter Length of column names does matter
document field • Config server (used two phase commit) • mongos (aka routers) Replica Set - 1 Replica Set 1 Replica Set N mongos 1 Client 1 Config Server 1 Config Server 2 Config Server 3
Primary / Slaves P2P ring Shard by any document field Shard by key Different roles and more complex configuration Simple configuration, elastic scalability, Datacenter/Rack aware
read from primaries, but eventually for reads from secondaries • database level read-writes locks • Write concern Write acknowledgment from replica set (by default acknowledgment from primary) Journaling (flush delay 100ms)
consistency. Tunable write acknowledgement Tunable consistency for reads/writes. Trade off between consistency and availability Read-Write database level lock Conflict resolution by timestamp Document level isolation Row level isolation Journaling. Flush every 100ms Commit log on disk ACID Summary
performance problems as for RDBMS) • Single/Multiple fields • One index per query. Hint • Unique indexes (must be shard key) • Geospatial Indexes • Text indexes • explain
consistency. Tunable consistency for reads/writes. Read-Write database level lock Conflict resolution by timestamp Rich query and indexing support Limited query/indexing support. Plan your data model by your queries. More complex sharding/replicating model. Sharding by non PK Simple p2p architecture. Sharding only by PK. Elastic scale. Read better than writes. Intensive write could significantly impair performance. Extremely fast write. Reads looks good too. Overall summary