所以，我已经使用 Cassandra 一段时间了，数据库架构的设计方式对我来说很不寻常。事实上，我只是没有足够的知识来决定这是否是一个好的设计，因为我是整个大数据事物的新手。
这里有一个简化:
- 我们有供应商
- 每个供应商都有客户
- 对于每个供应商，我们在 Cassandra 中创建他们自己的 key 空间。
- 对于供应商的每个客户，我们在其供应商的键空间中创建大约 12-15 个表。类似于
clientid_TableName。 - 表是在创建客户端时动态创建的。这很慢，我担心 Cassandra 在所有其他操作的负载下将无法传播模式。
- 所有表都具有相同的架构，没有针对任何给定客户端的特殊建模。
- 由于我们数据的性质，这些表中大约有 5 个可能有数百万(如果不是数十亿)行。
由于 Cassandra 的分布式特性，我永远不会认为需要这种“手动”数据划分，甚至有益。
这个单一的应用程序将有几十个键空间，每个键空间可能有数千个表。这不会对性能产生负面影响吗？
给我的印象是，这种设计允许更均匀地分布数据，在单个表中搜索时对性能的影响较小。这对我来说没有多大意义，但我没有任何论据来反驳它，因为我在 Cassandra 和所谓的大数据设计方面的经验充其量是非常有限的。我真正能想到的唯一好处是每个供应商都有不同的 key 空间设置。但我认为这并不能胜过任何增加的复杂性。
简而言之，这是个好主意吗？
最佳答案
首先，当您从 RDBMS 迁移到 Cassandra 时，您可能不得不重新设计 ERD，并且在大多数情况下，迁移标准和规范化的架构是一个非常糟糕的决定。现在，您只是想将现有模式移动到 Cassandra。
您拥有每个供应商等工作流程的所有这些表创建。您需要了解为什么要这样工作，以及您是否需要在 Cassandra 中这样做。一般来说，您可以有很多表和许多键空间(有限制，但它们很高)但这可能根本不适合 Cassandra 建模。
在 Cassandra 中，您应该基于查询而不是实体、对象、关系等构建表...数据重复不被视为问题，而是性能和所需存储之间的权衡。
我建议您学习 Datastax 的 Cassandra 数据建模类(class)。这是一门很棒的类(class)，而且完全免费::
关于database-design - 在 Cassandra 中拥有许多键空间和可能的数千个表是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43252589/