MongoDB vs Couchbase¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Область: MongoDB8.0; Couchbase7.6. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.
Критерии выбора¶
| Критерий | MongoDB8.0 | Couchbase7.6 |
|---|---|---|
| Workload | Document queries, aggregation, replica/shard design | Direct KV plus SQL++/Index/Search service paths |
| Consistency | Atomic document + supported multi-document transactions; concerns | KV durability levels + CAS + supported distributed transactions |
| Latency | Query plan/index + read concern определяют path | KV latency отдельно от GSI freshness/request_plus wait |
| Throughput | Shard key/hot document/index maintenance | vBucket distribution, service capacity и hot key |
| Cost | Replicas, indexes, shards, backup и memory | Data/Query/Index nodes, memory quotas, engine/edition и XDCR |
| Scalability | Sharding с routing/chunk design | vBucket rebalance и разделение services |
| Operational complexity | Oplog window, concern config, shard migrations | DCP/GSI lag, durability topology, service rebalance |
flowchart LR
Application --> Mongo[Document queries and concerns]
Application --> KV[Couchbase KV]
KV --> GSI[Async GSI projection]
GSI --> SQL[SQL++ with chosen scan consistency]Конкретные сценарии¶
KYC documents с variable schema → оба кандидата, выбор по access/transaction/ops. Player profile lookup по key → оценить Couchbase KV и Mongo indexed lookup при одинаковой durability. Cross-Region mutable wallet → ни async XDCR, ни неуточнённый replica concern не являются готовым global ledger protocol.
Ограничения и отказы¶
Embedding и indexes требуют bounded growth. Couchbase request_plus не global ACID, Mongo majority не означает любой read из secondary актуален. Сравнивать identical payload, working set, concerns и failure outcomes.
Как принять и проверить решение¶
Зафиксировать query mix, data distribution/skew, payload, working set, retention, concurrency, authoritative boundary и допустимую stale-read policy. Проверять steady state и maintenance, lost ACK, node loss, replay и restore. Сопоставлять total cost при одинаковых durability/replication requirements. Не объявлять универсального победителя по одному среднему времени запроса.
Типичные ошибки проектирования¶
Сравнивать default eventual/cache path с durable transactional commit; игнорировать operations/recovery; переносить benchmark другого dataset; выбирать продукт до определения access pattern.
Вопросы на собеседовании¶
Можно ли использовать варианты вместе? Да, если роли, data contracts и способы reconciliation определены. Дополнительная projection добавляет lag, replay и ownership, поэтому её польза должна покрывать эту сложность.
Практические упражнения¶
Для одного сценария выше составьте ADR: invariant, выбранный вариант, отклонённая альтернатива, failure outcomes и план измерений. Не задавайте придуманные TPS/SLA; перечислите входные данные, необходимые для sizing.