【发布时间】：2012-01-30 18:39:05
【问题描述】：
我目前正在努力寻找与 Cassandra 一起使用的正确数据格式。我猜这是因为它提供了比标准键值存储更多的深度。
我的数据格式目前是这样定义的：
- 不同应用程序的键空间。
- 不同应用程序部分的列族。
- 在这些列族中，我有数据。
大部分数据以以下格式存储在单个列族中：
Key: UUID-1|UUID-2|UUID-3
Value: Array of PHP Values
插入几个 100.000 个条目（每个
据我了解，列族应该正是存储我的数据主要部分的位置。将我的大部分数据放在一个列族而不是几个不同的列族中不应该是重点。
我应该考虑将我的数据分成不同的列族，还是该方法正确但可能是其他原因导致问题？
在评论中编辑以回答 DNA 的问题：
我正在比较开始测试之前插入的单个密钥所需的读取时间。
当数据库仍然为空时，测试密钥在开始时始终在 1.000 次。测试中写入的数据结构如下：
- 由 5 个字符 + 20 个数字构建的 Key 标识的行
- 一列（1 个字符）包含当前的 unix 时间戳
我添加了条目并重新运行了相同的读取测试以比较读取时间。我在这里列出的阅读时间是较低的数字：
Entries | Read Time
0 | 0.0010
150.000 | 0.0013
300.000 | 0.0014
500.000 | 0.0016
750.000 | 0.0019
1.000.000 | 0.0022
因为这仅用于基本测试，所以仅在 Amazon 的单个节点（ec2 实例）上运行。每增加 250.000 行，读取时间似乎增加了大约 0.0003 秒。
我知道这些数字确实很小而且很棒，但是读取时间的线性增长并不是我所期望的。
我计划将带有大量小条目的大型 MySQL 服务器移至 Cassandra。它目前包含大约 750 亿个条目，它收集的新数据集数量非常快，因此读取时间的线性增加让我怀疑我是否朝着正确的方向前进。
【问题讨论】：
-
您看到了什么性能，您希望获得什么性能？使用一个 CF 还是多个 CF 通常取决于您存储的数据的结构以及您需要的查询类型。您能否详细说明您的数据结构以及您正在执行的读取查询类型？您使用的是什么版本的 Cassandra，在什么硬件上？
-
@DNA：我保存的 PHP 值数组包含一些字符串（大约 10-20，每个长度为 10-500）。我还编辑了我的问题，以（希望）更好地解释我为什么要问这个问题以及我的“担忧”来自哪里。我在我的测试环境中使用版本 0.7.6-2。