- Last 7 days
-
rustwiki.org rustwiki.org
-
现在换一种方式思考这个关系，父节点应该拥有其子节点：如果父节点被丢弃了，其子节点也应该被丢弃。然而子节点不应该拥有其父节点：如果丢弃子节点，其父节点应该依然存在。这正是弱引用的例子！
如果父节点没人引用了，而子节点还有人引用，这时候可能父节点就会直接销毁掉，看起来挺奇怪的
-
-
rustwiki.org rustwiki.org
-
结合 Rc<T> 和 RefCell<T> 来拥有多个可变数据所有者
一个地方修改每个引用可见
-
在任意给定时刻，只能拥有一个可变引用或任意数量的不可变引用 之一（而不是两者）。
- 要么一个可变引用
- 要么0个可变引用 + 1或多个不可变引用
-
-
rustwiki.org rustwiki.org
-
这里的drop方法是用于提前清理Drop Trait的
-
-
rustwiki.org rustwiki.org
-
那Box是如何销毁掉堆上的对象的呢？
-
所以 Message 值需要的最大空间是存储其最大成员所需的空间大小。
对于枚举其实和union类似，取需要最大空间的一个类型的空间即可
-
使用 Box<T> 指向堆上的数据
Box感觉可以理解为Reference
-
当希望拥有一个值并只关心它的类型是否实现了特定 trait 而不是其具体类型的时候
支持上转型？
-
当有大量数据并希望在确保数据不被拷贝的情况下转移所有权的时候
转移所有权并不会被拷贝，拷贝也不会转移所有权，所以这里是一大堆的数据相互关联，然后通过转移或者拷贝栈上的引用来转移所有权？
-
当有一个在编译时未知大小的类型，而又想要在需要确切大小的上下文中使用这个类型值的时候
由于栈上的数据是需要知道确切大小的，因此如果大小不确定则只能放在堆上，而栈上使用引用
Tags
Annotators
URL
-
-
ddia.qtmuniao.com ddia.qtmuniao.com
-
版本向量
看不懂
-
r 和 w 都常都选择超过半数，如 (n+1)/2
由于r和w都超过半数，因此是能够保证写入和读取是最新的
-
由于 w + r > n 时，总会至少有一个节点（读写子集至少有一个节点的交集）
因为读写的节点比总结点多，读的节点中一定会存在上一次写的节点，但是上一次写的节点能保证写入时这些节点相对那些不写的节点更新吗
-
两个有因果依赖的（先插入，后更新）的语句，在复制到 Leader 2 时，由于速度不同，导致其接收到的数据违反了因果一致性。
由于支持多点写入，那么多个操作之间如果有依赖关系，但是后面的操作写入时写入的还未同步的节点，那么就会出问题
-
多主模型应用场景
实际上应该会在业务上进行妥协，对不同数据中心的用户或者数据进行隔离。或者直接使用一个数据中心也不是不可以，比如国内访问油管发送评论，那应该是在同一个数据中心进行的操作。如果是离线业务，那么就更不需要多主写入了
-
让所有有因果关系的事件路由到一个分区。
分区策略，如基于hash分区或者前缀分区
-
写后读保证的是写后读顺序，单调读保证的是多次读之间的顺序。
由于不同副本的同步进度不同，因此多次读取如果是不同节点，则可能出现不同的结果
-
客户端记下本客户端上次改动时的时间戳，在读从副本时，利用此时间戳来看某个从副本是否已经同步了改时间戳之前内容
记录客户端的上一次修改，从而保证从已经同步该修改的节点上获取数据
-
字段标号不能修改，只能追加。这样旧代码在看到不认识的标号时，省略即可。
向前兼容
-
在更改模式时（比如 alter table），数据库不允许增加既没有默认值、也不允许为空的列
添加列时向后兼容
-
Avro
Avro相对Protobuf和Thrift来讲没有使用字段标号(原本是为了标识数据属于哪个字段)，也没有显示指定类型，其会显式写入write schema版本，同时解析时使用read schema读取获取数据类型等信息
-
向后兼容：新加的字段需为 optional。这样在解析旧数据时，才不会出现字段缺失的情况。
数据兼容
-
列式存储的写入
所以列式存储的底层是使用什么数据结构？看起来像是顺序存储的样子
-
不同副本，不同排序
好主意，不过似乎对于复杂查询实际上帮助不大，毕竟只能按三个列的顺序存储
-
不可能同时对多列进行排序。因为我们需要维护多列间的下标间的对应关系，才可能按行取数据。
这是很疑惑的地方，每一列分开存储，应该可以分开排序才对，同时存储对应的行索引即可，而主键列也同样如此。这样每个列都进行顺序存储，并且行索引顺序且与列值位置映射，是否能实现这样的功能呢？只是说会额外浪费一定的空间，同时对于多列的排序无法实现
-
聚集索引（clustered index）
感觉聚簇索引相对来讲在读取多个数据节点时顺序读效率更高
-
性能优化
LSM-Tree进行范围查询性能很差，需要遍历所有的SSTable
-
图模型和网络模型
网状模型相对图模型有着更严格的约束，而图模型则更宽松可扩展，不过看起来图的查询效率依然很低
-
无论是 BFS、DFS 还是剪枝等实现细节
图的查询一般基于图的遍历操作，只是基于相关元数据进行了剪枝加速
-
数据类型和结构由外部决定，你没办法控制数据的变化。
既然无法确定数据类型，那么能对数据做的操作其实也有限，只能在应用能够通过配置操作、计算指定列数据时能够很好的利用。否则只能存储。
-
关系模型
相对网状模型进一步抽象，使得访问方式统一，同时基于用户需求统一生成执行计划进行数据访问
-
元组（tuples）
奇特的视角
-
在每一层，通过对外暴露简洁的数据模型，我们隔离和分解了现实世界的复杂度。
通过分层简化问题
-
弱 Schema（读时解析）
非关系型数据库比如hive使用
-
强 Schema（写时约束）
一般关系型数据库使用
-
-
book.originit.top book.originit.top
-
周同步，每
test
-
-
time.geekbang.org time.geekbang.org
-
大数据
测试111
-