-
MongoDB在搭建时候，要自己设置shard。也要自己进行缩容/扩容
-
MongoDB可以创建表时候是定义分片的或是非分片的。如果是分片的，需要指定shardkey
-
MongoDB可以
createIndex()创建索引。 -
MongoDB是只写入primery节点的。primery节点会复制到secondery节点。复制的个数可以配置，只有多少个复制成功了，才会认为插入成功
-
readPreference = primary
readConcern = majority/linearizable
writeConcern = majority
readPreference可以从主，也可以从备读取。但是readConcern = linearizable，则要求一定要readPreference是primary。因为要判断可读取的主是不是真的主
-
majority的在readConcern并不是含义真的读取全部的node判断，而是在请求的节点获取它认为的majority同意后的数据。因此这个数据可能是过时的，例如主变更，有新的数据写入
-
MongoDB 有 causal consistency session。可以保证自己写入后，自己可以读取出来
我刚写了 x=2
↓
马上去读 secondary
↓
如果不用 session，可能读到旧值 x=1
↓
如果用 causal consistent session + majority，MongoDB 会尽量保证我读到 x=2 或更新值
**8.**MongoDB索引是B树。MongoDB 分片集群里没有一个中心化的全局索引文件；每个 shard 只维护自己数据范围内的本地索引，副本集里的每个副本节点也各自保存一份索引文件。
- MongoDb的shard key不一定要求唯一性。结合shardkey能定位到哪个shard，之后这个shard的索引就能用上。否则就只能广播
10.MongoDb
普通 collection：按 _id 查完整文档，通常是 _id_ 索引查到 RecordId，再 FETCH 文档。
covered query：只返回索引里已有字段，可以不 FETCH。
clustered collection：_id 和文档存储顺序绑定，按 _id 查会更接近直接定位。
- Cassandra 也是配置写入多少个节点返回成功。此时可能一个值的更新被同时写入，此时根据最后一个写入成功的时间戳来解决冲突。解决冲突是在读取时候发现并解决的。
读取有
| 配置 | 含义 | 特点 |
|---|---|---|
ONE |
一个副本返回即可 | 最快，但可能读旧数据 |
LOCAL_ONE |
本地数据中心一个副本返回即可 | 多机房常用，低延迟 |
QUORUM |
多数副本返回 | 一致性更强，延迟更高 |
LOCAL_QUORUM |
本地数据中心多数副本返回 | 多机房最常见推荐 |
ALL |
所有副本返回 | 最强但可用性和延迟最差 |
单机房：QUORUM
多机房：LOCAL_QUORUM
追求低延迟：LOCAL_ONE
强一致要求很高：ALL 通常不推荐，太脆弱
- Cassandra speculative_retry 如果某个副本读得慢，coordinator 可以额外请求另一个副本，谁先回来用谁，降低长尾延迟。
ALTER TABLE users
WITH speculative_retry = '99PERCENTILE';
or
ALTER TABLE users
WITH speculative_retry = '10ms';
-
并发冲突检测 Cassandra 官方文档说，每一行里的每个 column 都会根据 last-write-wins 解决并发 mutation，并且 timestamp 是加在每个 column/cell 上的。
可以，Cassandra 的 clustering key 可以有多个。
在 Cassandra 里，一个表的 Primary Key 分两部分：
PRIMARY KEY ((partition_key), clustering_key1, clustering_key2, ...)例如：
CREATE TABLE orders (
user_id text,
order_date date,
order_id uuid,
amount decimal,
PRIMARY KEY ((user_id), order_date, order_id)
);这里：
(user_id)是 partition key，决定数据分布在哪个节点。
order_date, order_id是 clustering keys，用于在同一个 partition 内排序和组织数据。