由于 w + r > n 时，总会至少有一个节点（读写子集至少有一个节点的交集）
因为读写的节点比总结点多，读的节点中一定会存在上一次写的节点，但是上一次写的节点能保证写入时这些节点相对那些不写的节点更新吗
224 Matching Annotations
- Dec 2024
-
ddia.qtmuniao.com ddia.qtmuniao.com
-
-
两个有因果依赖的（先插入，后更新）的语句，在复制到 Leader 2 时，由于速度不同，导致其接收到的数据违反了因果一致性。
由于支持多点写入，那么多个操作之间如果有依赖关系，但是后面的操作写入时写入的还未同步的节点，那么就会出问题
-
多主模型应用场景
实际上应该会在业务上进行妥协，对不同数据中心的用户或者数据进行隔离。或者直接使用一个数据中心也不是不可以，比如国内访问油管发送评论，那应该是在同一个数据中心进行的操作。如果是离线业务，那么就更不需要多主写入了
-
让所有有因果关系的事件路由到一个分区。
分区策略，如基于hash分区或者前缀分区
-
写后读保证的是写后读顺序，单调读保证的是多次读之间的顺序。
由于不同副本的同步进度不同，因此多次读取如果是不同节点，则可能出现不同的结果
-
客户端记下本客户端上次改动时的时间戳，在读从副本时，利用此时间戳来看某个从副本是否已经同步了改时间戳之前内容
记录客户端的上一次修改，从而保证从已经同步该修改的节点上获取数据
-
字段标号不能修改，只能追加。这样旧代码在看到不认识的标号时，省略即可。
向前兼容
-
在更改模式时（比如 alter table），数据库不允许增加既没有默认值、也不允许为空的列
添加列时向后兼容
-
Avro
Avro相对Protobuf和Thrift来讲没有使用字段标号(原本是为了标识数据属于哪个字段)，也没有显示指定类型，其会显式写入write schema版本，同时解析时使用read schema读取获取数据类型等信息
-
向后兼容：新加的字段需为 optional。这样在解析旧数据时，才不会出现字段缺失的情况。
数据兼容
-
- Nov 2024
-
ddia.qtmuniao.com ddia.qtmuniao.com
-
列式存储的写入
所以列式存储的底层是使用什么数据结构？看起来像是顺序存储的样子
-
不同副本，不同排序
好主意，不过似乎对于复杂查询实际上帮助不大，毕竟只能按三个列的顺序存储
-
不可能同时对多列进行排序。因为我们需要维护多列间的下标间的对应关系，才可能按行取数据。
这是很疑惑的地方，每一列分开存储，应该可以分开排序才对，同时存储对应的行索引即可，而主键列也同样如此。这样每个列都进行顺序存储，并且行索引顺序且与列值位置映射，是否能实现这样的功能呢？只是说会额外浪费一定的空间，同时对于多列的排序无法实现
-
聚集索引（clustered index）
感觉聚簇索引相对来讲在读取多个数据节点时顺序读效率更高
-
性能优化
LSM-Tree进行范围查询性能很差，需要遍历所有的SSTable
-
图模型和网络模型
网状模型相对图模型有着更严格的约束，而图模型则更宽松可扩展，不过看起来图的查询效率依然很低
-
无论是 BFS、DFS 还是剪枝等实现细节
图的查询一般基于图的遍历操作，只是基于相关元数据进行了剪枝加速
-
数据类型和结构由外部决定，你没办法控制数据的变化。
既然无法确定数据类型，那么能对数据做的操作其实也有限，只能在应用能够通过配置操作、计算指定列数据时能够很好的利用。否则只能存储。
-
关系模型
相对网状模型进一步抽象，使得访问方式统一，同时基于用户需求统一生成执行计划进行数据访问
-
元组（tuples）
奇特的视角
-
在每一层，通过对外暴露简洁的数据模型，我们隔离和分解了现实世界的复杂度。
通过分层简化问题
-
弱 Schema（读时解析）
非关系型数据库比如hive使用
-
强 Schema（写时约束）
一般关系型数据库使用
-
-
book.originit.top book.originit.top
-
周同步，每
test
-