我不是cassandra的绝对Maven，但我知道（如果我错了，请纠正我）为数据模型中的所有字段创建二级索引是一种反模式。
我使用的是elassandra，我的数据模型如下所示：
表示用户的users对象，包括：userid、name、phone、e-mail和关于用户的各种信息（假设这些用户正在销售东西）
一个sales对象，表示用户进行的销售，包括：saleid、userid、产品名称、价格等（可以有更多字段）
考虑到我只想对name、e-mail和phone进行复杂的用户搜索（通过电话搜索、通过电子邮件搜索等），从这个数据模型创建以下3个表是一个好主意：
“user core”表，只有userid、name、phone和e-mail（用于搜索的字段）[表在elasticsearch中完全索引和Map]
“用户信息”表，用户ID+其他信息[表未在elasticsearch中索引或Map]
“sales”表，包含userid、saleid、产品名称、价格等[表在elasticsearch中未索引或Map]
我至少看到了一个优势：任何类型的指数化（或在发生变化时重新编制指数）和相关成本只有在“用户核心”表发生变化时才会发生，而“用户核心”表不应变化太频繁。另外，如果我需要获取所有其他信息（user other infos或sales），我只需进行2次查询：1次在“user core”中获取userid，1次在other表中（使用userid）获取其他数据。
但我不确定这是一个好的模式，或者我不应该担心二次指数化，只是基本上索引任何其他表？
更概括地说，选择elassandra-vs-denormalizing表中的辅助索引elasticsearch和使用分区和集群键的主要原因是什么？
请随时询问是否需要更多关于我的用例的示例。
2条答案
按热度按时间3j86kqsm1#
在使用cassandra时，不应该将表标准化。cassandra数据建模最重要的方面是为每个应用程序查询设计一个表。换言之，您应该始终对表进行非规范化。
在为每个查询建立一个表的模型之后，用elasandra索引该表，它包含了您需要查询的大多数列。
需要注意的是，elassandra并不是一颗灵丹妙药。在很多情况下，如果已根据应用程序查询对表进行了正确的建模，则不需要对表进行索引。
elassandra的用例是利用诸如自由格式文本搜索、刻面、增强等特性，但它的性能不如原生表。事实上，索引查找比直接的单分区cassandra读取需要更多的“步骤”。当然，ymmv取决于您的用例和访问模式。干杯！
ctzwtxfj2#
我不认为埃里克´对于elassandra，s的回答是完全正确的。本机cassandra查询的性能将优于elastic，这是正确的，在纯cassandra中，您应该围绕查询 Package 您的表。
但是，如果您更喜欢灵活性而不是性能（这就是您主要选择使用elasandra的原因），那么您可以使用cassandra作为主存储并从cassandra中获益´s复制性能，并为表编制索引，以便在elastic中进行搜索。
这使您在搜索方面更加灵活，并且仍然确保不会丢失数据，以防弹性方面出现问题。
事实上，在生产环境中，我们将两者结合使用：表有它的分区/集群键，并且在必要时以弹性方式索引。在后端，您可以决定是否可以通过cassandra键进行查询，或者是否需要弹性查询。