选择正确的元数据存储应该取决于你的系统架构。没有明确的 "正确选择"。但如果你是在分布式系统之上构建你的产品或服务，那么你的选择肯定会变窄。
最近，数据安全公司Rubrik写了一个由三部分组成的博客系列，讲述他们如何为Rubrik CDM选择元数据存储。他们的旅程从Cassandra开始，以CockroachDB结束。这篇博客总结了他们在Cassandra上遇到的挑战，他们选择CockroachDB作为元数据存储的原因，以及他们的CockroachDB使用案例。
最初，Rubrik使用Cassandra作为元数据存储，使他们的产品达到MVP。他们喜欢Cassandra的一些不同的品质，包括：更高阶的列类型，如地图/列表，高性能的点查询，容易设置，简单的部署和维护。但他们很快就遇到了几个问题。
- 节点间数据分布不均。根据为范围分配产生的随机数，一些节点会比其他节点分配更多的行（哈希值）。为此，他们使用了一种变通方法，即把一个Cassandra节点看作是一个虚拟节点。
- 二级索引的效率低下。在Cassandra中，你可以从集群中的每个节点通过二级索引查询获得本地结果。这在大型集群中是个大问题，导致性能不佳。
- 内存不足（OOM）的崩溃。Cassandra是一个Java进程，当没有分配足够的堆空间时，所有的Java应用都会遇到OOM问题。Rubrik给了Cassandra足够的堆空间，但有几个集群还是会遇到这些错误。
- 重现被删除的行。这是Rubrik最终选择从Cassandra转移的主要原因。当他们从Cassandra中删除一行时，Cassandra会用一个 "墓碑 "标记来标记该行，该标记有一个可配置的寿命。墓碑的主要问题是，当一个节点瘫痪的时间超过墓碑配置的寿命时，就会发生。
我们找到了解决上述问题的方法，但维护最佳实践的操作费用太过繁重。因此，Rubrik寻找一个替代的元数据存储。
Rubrik对分布式数据库的评估标准
Rubrik对他们的Cassandra替代品有三个明确的评估标准。
- 即使在节点故障的情况下也能提供高一致性保证
- 在压力/高负荷时能够有良好的性能
- 易于部署和维护
看看Rubrik建立的一致性和负载测试框架，针对他们的要求标准对数据库选项进行压力测试。在成功通过这些压力测试后，Rubrik的团队选择了CockroachDB作为他们的元数据存储，并开始评估迁移过程。
使用CQLProxy从Cassandra迁移出去
Rubrik从Cassandra迁移到CockroachDB中最引人注目的部分是Rubrik实现了一个名为CQLProxy的无状态翻译器。这个工具将CQL（Cassandra查询语言）翻译成PostgreSQL（CockroachDB选择的SQL方言）。
(图片来源：**Vijay Karthik)**
CQL模式具有静态列和高阶列类型（想想看，映射列）等功能，这些功能在SQL中是不存在的。Rubrik通过在CockroachDB中使用额外的表在CQLProxy中实现了这些功能，这使得应用开发更加容易。
Rubrik在其博客系列的第二部分中详细介绍了从Cassandra到CockroachDB的迁移，但它基本上涉及两个步骤。
- 一次性将现有数据从Cassandra迁移到CockroachDB
- 将应用程序转换为使用CQLProxy而不是Cassandra
而有了CQLProxy，Rubrik不需要对他们的应用层做任何改变。否则，在改变应用程序代码的同时，还要换掉分布式数据库，这种复杂性是很痛苦的。
Rubrik在CockroachDB上开发时学到的东西
总的来说，从Cassandra迁移到CockroachDB对Rubrik来说是一个胜利。他们有更少的操作开销，新的跨表交易支持（通过CQLProxy）简化了他们的应用逻辑。但是他们确实需要为CockroachDB的一些挑战找到解决方法：时钟偏移和背压。
对于时钟偏移的问题，Rubrik建立了一个分布式的时间服务，他们将其插入到CockroachDB中。Rubrik的一些物理集群由于NTP服务器的错误行为，很容易出现时钟偏移。通常情况下，NTP有助于纠正时钟（这是CockroachDB为避免时钟偏移而提出的建议之一）。但是，当NTP服务器出现问题时，时钟就会出现严重的不同步。
Kronos，由Rubrik构建的自定义时间服务，具有以下特性。
- 它具有与实时相同的流速
- 它在集群中的所有节点上返回相同的时间。
- 它不受系统时间跳跃的影响。
- 它始终是单调的。时间永远不会倒退。
- 它是容错的；也就是说，在节点故障的情况下也能工作（只要有法定人数--一半以上的节点活着）。
Kronos在每个节点上的CockroachDB内运行。它在集群中选出一个 "Oracle "来进行时间选择。这确实是一个迷人的工具，解决了一个重要的问题。请点击这里阅读更多关于Kronos的信息。
背压是Rubrik在CockroachDB中面临的下一个挑战。当行被频繁的更新或者垃圾回收落后于规定的TTL时，这个问题就会悄然出现。Rubrik实施了一些改变，这有助于减少他们遇到的背压错误的数量。
- 改变应用程序以减少对同一行的更新要求
- 在他们的对象关系映射器（ORM）中增加了内部重试，以应对因背压导致的更新失败。
- 为CockroachDB添加了补丁，以便更积极地对容易产生反压的范围进行垃圾回收。
在CockroachDB，我们非常感谢Rubrik为我们的公共版本所做的贡献。在过去的几年中，与他们的团队合作解决问题是一个重要的学习经验，并改善了我们的产品。要了解更多关于Rubrik的CockroachDB用例，你可以观看这个视频。
如果你有兴趣了解更多关于元数据管理的信息，你可以查看我们的参考架构，并观看这个高层次的概述视频。
