MongoDB 和 cassadra

  1. MongoDB在搭建时候,要自己设置shard。也要自己进行缩容/扩容

  2. MongoDB可以创建表时候是定义分片的或是非分片的。如果是分片的,需要指定shardkey

  3. MongoDB可以createIndex() 创建索引。

  4. MongoDB是只写入primery节点的。primery节点会复制到secondery节点。复制的个数可以配置,只有多少个复制成功了,才会认为插入成功

  5. readPreference = primary

readConcern = majority/linearizable

writeConcern = majority

readPreference可以从主,也可以从备读取。但是readConcern = linearizable,则要求一定要readPreference是primary。因为要判断可读取的主是不是真的主

  1. majority的在readConcern并不是含义真的读取全部的node判断,而是在请求的节点获取它认为的majority同意后的数据。因此这个数据可能是过时的,例如主变更,有新的数据写入

  2. MongoDB 有 causal consistency session。可以保证自己写入后,自己可以读取出来

我刚写了 x=2

马上去读 secondary

如果不用 session,可能读到旧值 x=1

如果用 causal consistent session + majority,MongoDB 会尽量保证我读到 x=2 或更新值

**8.**MongoDB索引是B树。MongoDB 分片集群里没有一个中心化的全局索引文件;每个 shard 只维护自己数据范围内的本地索引,副本集里的每个副本节点也各自保存一份索引文件。

  1. MongoDb的shard key不一定要求唯一性。结合shardkey能定位到哪个shard,之后这个shard的索引就能用上。否则就只能广播

10.MongoDb

普通 collection:按 _id 查完整文档,通常是 _id_ 索引查到 RecordId,再 FETCH 文档。

covered query:只返回索引里已有字段,可以不 FETCH。

clustered collection:_id 和文档存储顺序绑定,按 _id 查会更接近直接定位。

  1. Cassandra 也是配置写入多少个节点返回成功。此时可能一个值的更新被同时写入,此时根据最后一个写入成功的时间戳来解决冲突。解决冲突是在读取时候发现并解决的。

读取有

配置 含义 特点
ONE 一个副本返回即可 最快,但可能读旧数据
LOCAL_ONE 本地数据中心一个副本返回即可 多机房常用,低延迟
QUORUM 多数副本返回 一致性更强,延迟更高
LOCAL_QUORUM 本地数据中心多数副本返回 多机房最常见推荐
ALL 所有副本返回 最强但可用性和延迟最差

单机房:QUORUM

多机房:LOCAL_QUORUM

追求低延迟:LOCAL_ONE

强一致要求很高:ALL 通常不推荐,太脆弱

  1. Cassandra speculative_retry 如果某个副本读得慢,coordinator 可以额外请求另一个副本,谁先回来用谁,降低长尾延迟。

ALTER TABLE users

WITH speculative_retry = '99PERCENTILE';

or

ALTER TABLE users

WITH speculative_retry = '10ms';

  1. 并发冲突检测 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 内排序和组织数据。

相关推荐
吃糖的小孩38 分钟前
给 QQ AI 机器人设计“可控记忆”:会话摘要、手动长期记忆与角色卡边界
数据库
葫芦和十三2 小时前
图解 MongoDB 17|大集合与工作集:数据超过内存怎么办
后端·mongodb·面试
葫芦和十三10 小时前
图解 MongoDB 18|复制集拓扑:Primary、Secondary 和 Arbiter 的分工
后端·mongodb·面试
葫芦和十三16 小时前
图解 MongoDB 15|journal 与持久化:写入怎么不丢,崩溃怎么恢复
后端·mongodb·面试
葫芦和十三16 小时前
图解 MongoDB 16|压缩:snappy、zstd 和 zlib 的取舍
后端·mongodb·面试
笃行35018 小时前
金仓数据库数据安全双防线:静态存储加密与传输加密实战
数据库
笃行35018 小时前
金仓数据库物理备份实战:sys_rman 全流程演练与误覆盖抢救
数据库
笃行35019 小时前
金仓数据库逻辑备份实战:从全库导出到 Schema 替换的完整闭环
数据库
葫芦和十三1 天前
图解 MongoDB 13|WiredTiger 存储引擎:B-tree、页和 checkpoint 三件套
后端·mongodb·agent