mongoDB CAP
mongoDB CAP
https://towardsdatascience.com/cap-theorem-and-distributed-database-management-systems-5c2be977950e
https://medium.com/@bikas.katwal10/mongodb-vs-cassandra-vs-rdbms-where-do-they-stand-in-the-cap-theorem-1bae779a7a15
CP
- mongo single leader based system with multiple replic -replicates asynchronously from Oplog
- node 之间heartbeat
- primary goes down， election
scenario 1
default - read、write config primary ， election 会有秒级的读写不可用，保证一致性，牺牲availability
scenario 2
Enable readble from secondary - readPreference
如果从primary 由于replication 延迟无法保证一致性 - 最终一致
但是可以通过write concern 来控制（读）一致性， eg “majority” 写数据除了primary ack还有replica到n个slave
In Summary, MongoDB can always be Consistent based on how you configure your client and the way you write data(using write options) and can be always available for reads but you can never make write always available, there will always be downtime when: a) the new leader is getting elected b) the client driver disconnects from the leader
MongoDB 适用领域
文档型数据库， json， k-v直观 ； 不需要多表join，可以使用嵌套array 或者object； schema free， design更灵活；
索引： 唯一索引，二级索引，ttl ，地理位置索引；在内存足够的情况下，索引会被加载到Cache中，如果执行的查询是索引覆盖的（Query Optimization），其性能甚至可以媲美Redis等内存数据库等； TTL 可以实现自动删除（eg 保存监控和logging数据）
explain 查看执行计划；
replica ，oplog； primary 出问题，自动election failover ， 易于运维
sharding 支持horizontal scaling， 只有业务数据量和负载单个replicaset 无法支持，再考虑sharding （complexity）
缺点： CP db， 可能会有短时间不可用。
适用场景：
- 敏捷迭代的业务，需求变动频繁，数据模型无法确定
- 无需要跨文档或跨表的事务及复杂的join查询支持 // 目前已经支持事务，join的支持也越来越好。
- 存储的数据格式灵活，不固定，或属于半结构化数据
- 要求存储的数据持久化、不丢失