在 Cassandra 中拥有许多键空间和潜在的数千个表是一个好主意吗？

Question

所以，我使用 Cassandra 已经有一段时间了，并且数据库的架构设计方式对我来说是相当不寻常的。事实上，我只是没有足够的知识来决定这是否是一个好的设计，因为我对整个大数据这件事还是新手。

这是一个简化：

• 我们有供应商
• 每个供应商都有客户
• 对于每个供应商，我们都会在 Cassandra 中创建自己的密钥空间。
• 对于供应商的每个客户，我们在其供应商的键空间中创建大约 12-15 个表。类似clientid_TableName。
• 在创建客户端时动态创建表。这很慢，我担心 Cassandra 在所有其他操作的负载下将无法传播架构。
• 所有表都具有相同的架构，没有针对任何给定客户端的特殊建模。
• 由于我们数据的性质，其中大约 5 个表可能包含数百万甚至数十亿行。

由于 Cassandra 的分布式特性，我永远不会认为需要这种“手动”的数据划分，甚至有益。

这个单一的应用程序将有几十个键空间和可能有数千个表每个键空间。这不会对性能产生负面影响吗？

给我的印象是这种设计允许更均匀地分布数据，在单个表中搜索时对性能的影响较少。这对我来说没有多大意义，但我没有任何论据来反驳它，因为我在 Cassandra 和所谓的大数据设计方面的经验充其量是非常有限的。我真正能想到的唯一好处是每个供应商都有不同的键空间设置。但我不认为这胜过任何增加的复杂性。

简而言之，这是个好主意吗？

Answer 1

首先，当您从 RDBMS 迁移到 Cassandra 时，您可能必须重新设计 ERD，并且在大多数情况下，迁移标准和规范化模式是一个非常糟糕的决定。现在您只是想将现有架构移动到 Cassandra。

您拥有每个供应商等工作流程的所有这些表创建。您需要了解为什么要以这种方式工作，以及是否需要在 Cassandra 中这样做。一般来说，您可以拥有许多表和许多键空间（有限制，但它们很高），但这可能根本不适合 Cassandra 建模。

在 Cassandra 中，您应该基于查询而不是实体、对象、关系等来构建表...数据重复不是问题，而是需要在性能和存储之间进行权衡。

我建议您参加 Datastax 的 Cassandra 数据建模课程。这是一门很棒的课程，而且完全免费::

https://academy.datastax.com/courses