data-nosql-database

Data NoSQL Database

Purpose

Select and design NoSQL databases by access patterns, data shape, consistency requirements, and scale. Use document stores for flexible schemas, wide-column for high-scale writes, key-value for caching, and single-table designs for DynamoDB.

Architecture / Decision Trees

NoSQL Type Selection Decision Tree

What is the primary access pattern?
├── Complex queries with flexible filters, aggregations
│   └── Document store (MongoDB, Couchbase)
├── Simple lookups by primary key, high throughput
│   ├── Key-value reads < 1KB → Redis (in-memory)
│   └── Larger payloads, durable → DynamoDB
├── High-volume writes, time-series data
│   └── Wide-column (Cassandra, Scylla, Bigtable)
├── Relationship-heavy traversals
│   └── Graph (Neo4j, Amazon Neptune)

What consistency model is required?
├── Strong consistency required → MongoDB (primary reads, majority write)
├── Tunable consistency → Cassandra (ONE/QUORUM/ALL per query)
├── Eventually consistent acceptable → DynamoDB (default eventual reads)
└── Strict serializable → Spanner, CosmosDB (Bounded Staleness)

What is the write volume?
├── < 10K writes/sec → MongoDB, DynamoDB, any
├── 10K-100K writes/sec → Cassandra, Scylla, DynamoDB (on-demand)
├── 100K-1M writes/sec → Scylla, Cassandra (tuned), Bigtable
└── > 1M writes/sec → Scylla, Bigtable, custom partitioning

What is the data size per entity?
├── Small documents (< 16MB) → MongoDB (16MB doc limit)
├── Large blobs → Store in S3/GCS, reference in NoSQL
└── Variable size → DynamoDB (400KB item limit)

Partition Key Design Decision Tree

What is the query pattern?
├── Always query by user/tenant ID
│   └── User/tenant ID as partition key
├── Query by time range within a partition
│   └── Partition: user/region, Sort/cluster: timestamp
├── Global queries across all partitions
│   └── GSI (DynamoDB), secondary index (MongoDB)
├── Need time-series + evenly distributed writes
│   └── Compound partition key with time bucket + hashed shard key
└── Need geographic data locality
    └── Ranged shard key by region

Avoid:
├── Monotonically increasing keys (all writes to last shard)
├── Low-cardinality keys (jumbo partitions, hot spots)
├── Single-attribute keys for multi-tenant (all writes to one shard)
└── Frequently updated keys (cross-shard transactions)