Netflix单key存储的架构演进

记录一下看了Netflix实战指南：规模化时序数据存储后关于其中的单key存储的架构演进理解，

Overview

Netflix 的云原生存储架构使用了 Cassandra存储观看历史数据，考虑如下，

支持对时序数据的建模
在当前业务数据上，读写操作比是1：9。而Cassandra提供了高效写操作API，适用于当前的写密集型业务应用
CAP权衡，当前业务更偏向于C。而Cassandra支持可调整的一致性，有助于实现CAP上的权衡

演进路线总结，

v1：一个用户一个key，key后面跟一连串的用户观影记录信息data。当data少时，可以快速定位<userId, data[record1, …, recordN]>；水平扩展性好。但是当data很大，查询需要低效的O(N)来遍历整个data。LRU缓存可以改善查询低效，但是空间换时间。

v2：既然v1的问题是累积data的太大引起，那么可以根据自定义阈值T1将data切分为两部分，一部分是实时数据；一部分是历史数据。小的实时数据可以按照v1的方式一列一个record；大的历史数据都压缩在一起成为一列（多个历史列合并成一个列）。如果合并压缩后的历史数据还是太大，那么依照阈值T2对其切分。

个人感觉是分库分表/MapReduce/冷热数据分离的思想，将一个读操作或者一个写操作的数据模型，切开成多个小的数据模型，然后在其上实现并发读写。

单表数据模型(Version1)

数据结构

每位会员的所有观看记录存储为一行，使用customerId为主键，每一次观看记录为一列，即，

(`customerId`, record1, record2, record3, ..., recordN)

优点，水平分区设计支持数据存储随会员数量的增长而有效扩展（会员越多，row越多，分库分表即可），并支持简单并高效地读取会员的完整观看历史数据（都在一行里）
缺点，每位会员观看的视频流越来越多，存储的数据列数和整体数据量也日益膨胀。随着时间的推移，这将导致存储和操作的成本增大。而且对于观看了大量视频的会员而言，查询性能会严重降低（hashMap冲突多了查链表之后就是O(n)）

单表数据模型/v1模型的读、写操作

写操作

当一位会员开始播放视频时，一条观看记录会以一个新列的方式插入。当会员暂停或停止观看视频流时，观看记录会做更新。在 Cassandra 中，对单一列值的写操作是快速和高效的。

读操作

为检索一位会员的所有观看记录，需要读取整行记录。如果每位会员的观看记录数量不大，这时读操作是高效的。如果一位会员观看了大量的视频，那么他的观看记录数量将会增加，即记录的列数增加。读取一个具有大量列的数据行，会对 Cassandra 造成了额外压力，进而对读操作延迟产生负面影响。

要读取一段时间内的会员数据，需要做一次时间范围查询。这同样会导致上面所说的性能不一致问题。因为查询性能依赖于给定时间范围内的观看记录数/列数。

如果要查看的历史数据规模很大，需要做分页才能进行整行读操作。分页对 Cassandra 更好，因为查询不需要等待所有数据都就绪，就能返回给用户。分页也避免了客户超时问题。但是，随着观看记录的增长，分页增加了读取整行的整体延迟。

读延迟

原因，只有最近的数据是维护在内存中的（LRU），因此在很多情况下，检索观看历史记录时需要同时读取内存表和 SSTable。这对于读取延迟具有负面影响。同样，随着数据的增长，合并（Compaction）操作将占用更多的 IO 和时间。此外，随着一行记录越来越宽，读修复（Read repair）和全列修复（Full column repair）也会变慢。

缓存层

为优化读操作延迟，考虑了以增加写路径上的工作为代价，在Cassandra存储前增加了一个内存中的分片缓存层（即EVCache）。缓存实现为一种基本的键-值存储，键是customerId，值是观看历史数据的二进制压缩表示。每次Cassandra的读操作，将额外生成一次缓存查找操作。一旦缓存命中，直接给出缓存中的已有值。对于观看历史记录的读操作，首先使用缓存提供的服务。一旦缓存没有命中，再从Cassandra读取条目，压缩后插入到缓存中。

实时数据与历史数据分离模型(Version2)

数据结构

为进一步实现存储的规模化，分析了数据的特征和使用模式，重新定义了观看历史存储。给出了两个主要目标，

更小的存储空间
考虑每位会员观看视频的增长情况，提供一致的读写性能

最后决定将每位会员的观看历史数据划分为两个数据集，

实时/近期观看历史记录（LiveVH，Live or Recent Viewing History）：一小部分频繁更新的近期观看记录。LiveVH 数据以非压缩形式存储
历史/归档观看历史记录（CompressedVH，Compressed or Archival Viewing History）：大部分很少更新的历史观看记录。该部分数据将做压缩，以降低存储空间。压缩观看历史作为一列，按键值存储在一行中

为提供更好的性能，LiveVH 和 CompressedVH 存储在不同的数据库表中，并做了不同的优化。

冷数据太多，单机memory放不下，就将冷数据打包，然后切片分段，缓存到不同的单机memory上。在查找时再根据meta data的routing来查。

LiveVH

写操作

如果一位会员观看了大量的视频，那么他的观看记录数量将会增加，即记录的列数增加（跟version1的写操作一样）。

读操作

读取实时/近期观看历史：在大多数情况下，近期观看历史仅需从LiveVH读取。这限制了数据的规模，进而给出了更低的延迟。

CompressedVH

写操作

在从LiveVH读取观看历史记录时，如果记录数量超过了一个预设的阈值，那么最近观看记录将由后台任务打包（roll up）、压缩并存储在CompressedVH 中。

打包数据存储在一个行标识为 customerId 的新行中。新打包的数据在写入后会给出一个版本，用于读操作检查数据的一致性。只有验证了新版本的一致性后，才会删除旧版本的打包数据。

CompressedVH的打包行中还存储了元数据信息，其中包括最新版本信息、对象规模和分块信息。

实时数据与历史数据/v2模型的读、写操作

新行记录中具有一个版本列，指向最新版本的打包数据。这样，读取 customerId 总是会返回最新打包的数据。为降低存储的压力，只使用了一个列存储归档数据。为最小化具有频繁观看模式的会员的打包频率，LiveVH中仅存储最近几天的观看历史记录。打包后，其余的记录在打包期间会与 CompressedVH中已有的记录归并。