Cassandra的麻烦：为什么它是对象存储元数据数据库的不佳选择

Cassandra是一个受欢迎的验证和真正的NoSQL数据库，支持键值宽列表。与任何强大的工具一样，Cassandra具有其理想的用例 - 特别是Cassandra擅长支持写入繁重的工作负载，同时在支持读取重型工作负载时具有局限性。 Cassandra＆＃39; s最终一致性模型和缺乏交易，多表支持，如加入，子查询也可以限制其有用性。

但是，使用Cassandra作为对象存储系统的元数据数据库，引入了显着的复杂性，从而导致规模的数据完整性和性能问题 - 特别是如果想要将其对象存储用作主存储系统。对象存储需求远更简单，与Cassandra建造的不同。

由于雇用Cassandra作为对象存储元数据数据库的含义未正确理解，因此许多对象存储供应商使其成为其架构的基础部分 - 不幸的是，它使它们永远将过去的简单归档工作负载转移到定义未来的现代工作负载中对象存储（AI / ML，Analytics，Web / Mobile应用程序）。

Cassandra从未设计用于管理文件或对象存储元数据，在这方面可以预测地弱。它不符合酸。它没有防止部分成功的写入，欺骗，矛盾等的僵化。 Cassandra不支持连接或外键，因此在酸感的不提供一致性。此外，在发生故障时没有滚动交易的容量。虽然Cassandra在行级支持了原子性和隔离，但它交易了用于高可用性和快速写入性能的事务隔离和原子性。

Cassandra被归类为CAP中的AP系统。意味着它交易了可用性和分区容差的一致性。在使用Cassandra作为对象存储的元数据数据库时，您可以快速或一致 - 但不是同时。 Cassandra的可调一致性是一个妥协，而不是一个功能。仲裁以外的任何设置或一切都意味着您面临陈旧数据的风险。除了在其外部执行的对象数据操作之外，还可以针对读写操作应用此一致性设置。在对象存储世界中，含义是您可以对档案用例（写一次，非常不经常读取）或者选择不同的架构。

类似于一致性问题，耐用性保证也是性能和正确性之间的权衡。存储引擎的默认提交日志设置为每10秒定期同步。这意味着在电源故障时，您将减少最新的最新更新。使Cassandra持久的唯一合理方式是使用具有性能损失的同步批量模式提名。

Cassandra的高可用性保证不适合擦除编码对象商店。对于3的复制因子和2的一致性仲裁因子，Cassandra只能在复制组中容忍单个节点/驱动器故障。增加复制因子和法定量为5或更高的一致性，仅用于使元表现从坏差。与复制不同，擦除编码可以容忍多个服务器并驱动分布式系统中的故障。即使您已将擦除代码设置配置为6个奇偶校验（任何6个节点可能发生故障），您仍然受到弱链路的限制，即Cassandra的复制因子。 ops团队往往没有意识到这些高可用性的惊喜，直到为时已晚。

对象存储系统在树形结构化分层命名空间中组织数据。由于Cassandra不支持分层密钥命名空间，因此您必须为每个目录前缀构建一棵树数据模型，并在没有目录步行的情况下维护一个平面列表。具有批量提交日志和完整读/写法仲裁的多个表慢并且容易损坏多个表。

虽然对象本身是不可变的，但对象存储系统是可变的。添加，删除，覆盖对象及其元数据时，应用策略，收集指标，授予会话令牌和旋转凭据，元数据始终突变。 Cassandra不设计用于处理这种级别的元数据突变，并且绝对不是主要存储工作负载。长期档案用例，物体大（GB大小）和不经常访问，将工作 - 其他用例不会。原因是Cassandra＆＃39; S日志结构存储系统快速附加到结尾的新写字日志文件，但延迟删除和覆盖墓碑标记。吸取这些墓碑是一个昂贵的操作，因为通过将SSSTables复制到筛选过程中的陈旧条目的新表来应用实际删除操作。必须同时在所有节点上执行此操作。如果您延迟吸尘，过多的墓碑将导致读取延迟增加，内存GC暂停和失败的查询。一些对象存储供应商使用额外的REDIS数据库来卸载CASSANDRA的压力。使用两个数据库来管理对象存储元数据几乎不优雅，并引入了其他失败点。最大的gotcha？在您深入生产之前，您将不会看到这些问题，为时已晚。

小对象（大小的kB到MB）将填充专用于Cassandra的元数据驱动器，而不是数据驱动器。还有小对象工作负载加剧了Cassandra的局限性，因为它们对延迟和一致性问题很敏感。一些供应商完全在Cassandra内存的小物体来解决这个问题。此时，您只需在Cassandra数据库上看一个S3代理。这也是一个糟糕的做法。如果您使用对象存储以进行大型对象并使用擦除编码并使用Cassandra作为您的小对象的数据存储和使用复制 - 您已经介绍了一个非平凡的SLA问题。在这种方法中，数据受到不同保证的保护。鉴于驱动器一直死在一起，服务旧对象或损坏对象的可能性很大。如上所述，您的元数据数据库现在是薄弱的链接。可用性，一致性和耐用性保证仅与最薄弱的联系一样好。如果最弱的链接采用复制（三个副本），则可以在丢失数据之前抵消一个节点或一个驱动器故障。柜台参数可能是复制五个副本。结果是一个大规模的绩效命中，您仍然只能承受两个节点或两个驱动器故障。在使用对大型物体的小物体和擦除编码的复制中，您还破坏了与EC相关的效率增益。如果您只使用大型对象的擦除代码（可能是整个对象池的少量百分比），您不会得到很多，但大大增加您的曝光。

使用Cassandra作为对象存储的元数据数据库也引入了麻烦的Java依赖项。这反过来可能导致陷阱软件和内存管理问题。 Cassandra以恒定的大规模元数据分配和突变征收JVM内存管理，导致内存耗尽和垃圾收集暂停。

显而易见的外带是，操作Cassandra集群比适当设计的对象存储系统更复杂。 Cassandra是为不同的目的而构建的，对象存储的元数据不是其中之一。 Cassandra斗争的领域是表演，可扩展和弹性对象商店的核心。

最后一点是注 - 对象存储是Blob数据的自然适合，这就是擦除编码如此有效和高效的原因。 Cassandra专为复制而设计。当您使用该型号进行元数据时，它会破坏对象存储的擦除编码优势（或者最不使其脆弱并且容易破损）。

我们欢迎您的意见。在我们的松懈频道上，或通过在[email protected]下放记笔，随时致力于推特。