为Cassandra数据库建模数据的最佳实践
我是Cassandra的新手，正在寻找一个关于如何为具有以下一般结构的数据建模的最佳实践：
对于不同的用户，附加的数据字段不一定相同（字段的名称或这些字段的类型）
示例（csv格式：）
user_id_1.csv
| column1 (unique key per user_id) | column2 | column3 | ... | column10 | additionalColumn1 | ...additionalColumn_n |
|-----------------------------------|-----------|----------|---------|------------|---------------------|------------------------|
| user_id_1_key_1 | value | value | value | value | ... | value |
| user_id_1_key_2 | .... | .... | .... | .... | ... | ... |
| .... | ... | ... | ... | ... | ... | ... |
| user_id_1_key_2Million | .... | .... | .... | .... | ... | ... |
user_id_XXX.csv (notice that the first 10 columns are identical to the other users but the additional columns are different - both the names and their types)
| column1 (unique key per user_id) | column2 | column3 | ... | column10 | additionalColumn1 (different types than user_id_1 and others) | ...additional_column_x |
|-----------------------------------------------------------|-----------|----------|---------|------------|-----------------------------------------------------------------|-------------------------|
| user_id_XXX_key_1 | value | value | value | value | ... | value |
| user_id_XXX_key_2 | .... | .... | .... | .... | ... | ... |
| .... | ... | ... | ... | ... | ... | ... |
| user_id_XXX_key_500_thousand (less rows than other user) | .... | .... | .... | .... | ... | ... |
我考虑过的几个选择：
Keyspace
+--------------------------------------------------------------------------+
| |
| |
| Data_Table |
| + +--------+-------+--------------------------+-----+ |
| | | | | | | |
| | +-------------------------------------------------+ |
| | | | | | | |
| many rows | +-------------------------------------------------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | Many columns | | |
| | | | +------------------------> | | |
| | | | | | | |
| | +-------------------------------------------------+ |
| v +-------------------------------------------------+ |
| |
+--------------------------------------------------------------------------+
-
null
每个User_id创建Keyspace
每个关键字空间创建表“data”
+-----------------------------------------------------------------------------------+
| column_1 | column_2 | ... | column_n | additional_column_1 | additional_column_n |
+-----------------------------------------------------------------------------------+
keyspace_user1 keyspace_user2 keyspace_user_n
+----------------+ +---------------+ +---------------+
| | | | | |
| | | | | |
| +-+-+--+-+ | | +-+--+--+ | | +--+--+---+ |
| | | | | | | | | | | | | many keyspaces | | | | | |
| | | | | | | | | | | | | +-------------> | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |
| +--------+ | | +-------+ | | +---------+ |
+----------------+ +---------------+ +---------------+
备注：
-
null
+---------------------------------------------------------------+
| Keyspace |
| |
| user_1 user_2 user_n |
| +--+---+--+ +--+--+--+ +--+--+--+ |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| +--+---+--+ +--+--+--+ +--+--+--+ |
| |
| |
+---------------------------------------------------------------+
-
null
创建多个keyspaces（例如“x”个keyspaces)，每个keyspaces包含一系列表（每个用户的表）
keyspace_1 keyspace_x
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| | | |
| | | |
| user_1 user_2 user_n/x | | user_n-x user_n-x+1 user_n |
| +--+---+--+ +--+--+--+ +--+--+--+ | | +--+------+ +--+--+--+ +--+--+--+ |
| | | | | | | | | | | | | | "X" keyspaces | | | | | | | | | | | | | |
| | | | | | | | | | | | | | +---------------------> | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| +--+---+--+ +--+--+--+ +--+--+--+ | | +--+---+--+ +--+--+--+ +--+--+--+ |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
备注：
- 多个密钥空间
- 每个用户多个表
- 需要“查找”来确定哪个键空间包含所需的表
-
null
共有1个答案
这种类型的集成挑战通常通过关系系统中的EAV（实体属性值）数据模型来解决（就像Ashrafaul演示的那样）。在考虑EAV模型时，关键要考虑的是无界的列数。当然，EAV数据模型可以在Cassandra或ScylLadb这样的CQL系统中模拟。EAV模型很适合写，但在阅读时提出了挑战。你还没有详细说明你的阅读注意事项。您需要返回所有列还是需要返回每个用户的特定列？
文件
话虽如此，Cassandra和ScyllaDB还有一些内在的考虑因素，它们可能会使您在问题中描述的一些设计上指向统一的EAV模型。Cassandra和ScyllaDB都将键空间和数据库作为磁盘上的文件进行布局。文件数基本上是键空间数乘以表数的乘积。因此，您拥有的键空间、表或两者的组合越多，磁盘上的文件就越多。这可能是文件描述符的问题和其他os文件杂耍问题。由于您提到的访问的长尾，可能会出现每个文件一直打开的情况。这是不可取的，尤其是当从一个冷靴子开始。
更新或版本控制
你提到更新。基本EAV模型将只代表最近的更新。没有版本控制。您可以做的是将时间添加为集群键，以确保随时间的推移维护列的历史值。
阅读
CREATE TABLE data (
userid bigint,
column1 text,
column text,
value text,
PRIMARY KEY ( (userid, column1), column )
);
我还有一个单独的表，可能是columns_per_user，它记录每个userid的所有列。类似于
CREATE TABLE columns_per_user (
userid bigint,
max_columns int,
column_names text
PRIMARY KEY ( userid )
);
其中max_columns是该用户的列总数，column_names是实际的列名。您还可以有一列表示每个用户的条目总数，类似于user_entries int，它基本上是每个用户csv文件中的行数。
-
我目前有一个应用程序，它将事件驱动的实时流数据持久化到一个列系列，该系列建模为： 每个帐户ID每X秒发送一次数据，因此我们每次收到事件时都会覆盖现有行。此数据包含当前实时信息，我们只关心最近的事件（不使用旧数据，这就是我们插入已经存在的键的原因）。从应用程序用户端-我们通过account_id语句查询选择。 我想知道是否有更好的方法来模拟这种行为，并查看了Cassandra的最佳实践和类似的问题(
-
目前需求就是将mysql的表结构及数据迁移到pgsql. 我用的方案是使用navicate 同步数据及结构到pg, 有如下问题: mysql中的索引直接丢失了 不知道为啥一直报错表找不到 对于默认值 pgsql也丢失了 请问大家有什么好的实践吗? 我考虑的是 直接使用数据库迁移 将数据库脚本转化为pg的语法
-
我开始创建一个系统，我（作为目前唯一的用户）将加载一个动态创建的PHP页面，该页面具有
-
我正在尝试为一个Saas应用程序建模，在这个应用程序中，我将让不同的公司使用这些服务。我有点困惑于为这种类型的服务建模我的猫鼬数据库的最佳方式。 所以这个模型有点像 为这样的应用程序建模的最佳方式是什么？ 我是否应该为用户、项目等创建不同的模型，并将公司唯一ID附加到该公司内的所有用户或项目。也可以在公司模型中引用这些用户或项目。差不多 或者 只需在公司模式中引用用户和项目模式，而不需要单独的模型
-
表1： 表1的键和数据大小： 我的分区密钥为enterprise_id+campaign_id。每个企业可以有几个活动。datastore可能有几百个活动的数据。每个活动可以有多达200万-300万的记录。因此，在100个企业中可能有3000个分区，每个分区有2-3个miilion记录。 Cassandra查询：查询始终使用分区键+主键直到日期时间。订阅id包含在主键中，以保持每个记录的唯一性，因
-
问题内容： 我出于好奇而问这个问题。基本上，我的问题是，当您拥有一个需要行条目才能具有像标志作用的事物的数据库时，最佳实践是什么？一个很好的例子就是堆栈溢出的标志，或者是bugzilla中的操作系统字段。可以为给定条目设置标志的任何子集。 通常，我会进行c和c ++的工作，因此我的直觉反应是将无符号整数字段用作一组可以翻转的位…但是我知道，由于多种原因，这不是一个好的解决方案。其中最明显的是可伸缩