【问题标题】:Ways to organize row-keys for range scans in Cassandra在 Cassandra 中组织范围扫描的行键的方法
【发布时间】:2012-02-01 04:49:39
【问题描述】:

我正在尝试找到一种好方法来组织我的行键以对其执行范围扫描,而无需创建我自己的索引列表。

我有一个 MySQL 数据库,目前大约有 15.000 个数据库,每个 ~50 个表 = 75.000 个表。因为 99% 的数据始终使用唯一标识符读取,因此计划将数据移动到 Cassandra 集群中。

对于某些维护(列出完整表的内容、删除完整表或删除数据库)的情况,我需要获取完整表甚至数据库的内容。 Range-Scans 似乎非常适合。

目前我正计划为旧结构的每个部分生成 UUID,并将它们放在一起,用 | 分隔(DB + Table + Id = UUID1|UUID2|UUID2)。

例子:

07424eaa-4761-11e1-ac67-12313c033ac4|0619a6ec-4525-11e1-906e-12313c033ac4|0619a6ec-4795-12e9-906e-78313c033ac4

带有数据的CF应该用org.apache.cassandra.db.marshal.AsciiType排序。

作为客户端,我使用的是 phpcassa。

对于范围扫描,我想使用UUID| 作为开始键和范围的结束,相同的键但附加了chr(255)z。这两个字符的 ascii 值比该键后面的任何其他 UUID 字符都大。

这是一种可靠的方法,可以让我实现范围扫描的说明目标吗?

【问题讨论】:

    标签: database-design cassandra phpcassa


    【解决方案1】:

    Cassandra 的最佳实践是使用 RandomPartitioner - 只要您的令牌均匀分布,这将为您提供“免费”负载平衡。不幸的是,使用随机分区器,行范围查询(即 get_range_slices)以随机顺序返回键。

    这适用于对整个列族进行分页(如果这是您想要的,那么您的方法将起作用)。但是,如果您只想在较小的、连续的行键范围内进行分页,则将无法正常工作。

    解决此问题的一种方法是使用宽行和复合列。例如,如下所示的列族:

    { 
      row1 -> {column1: value1, column2: value2},
      row2 -> {column3: value3, column4: value4},
      ... 
    }
    

    将被转置为如下所示:

    {
      row1-10 -> {
                  [row1, column1]: value1, [row1, column2]: value2,
                  [row2, column3]: value3, [row2, column4]: value4,
                  ...
                 }
      ...
    }
    

    您可以通过在右列之间的右行上执行列切片 (get_slice) 来执行范围查询。即

    get_range_slice(start=row1, end=row2)
    

    变成:

    get_slice(row=row1-10, start=[row1, null], end=[row2, null])
    

    注意列键上的空第二维。

    诀窍是选择您的行(“桶”)键,这样您的列就不会变得太大(这对于普通的 Cassandra 来说会很糟糕),但您的查询不需要获取太多行。这将取决于您的平均查询大小和 uuid 的分布,但一个不错的选择可能是使用 UUID1 作为行键和 [UUID2, UUID3] 作为列键的第一个维度。

    【讨论】:

    • 感谢您确认该方法到目前为止是可靠的。排序顺序对我来说无关紧要,只有访问某些范围很重要。使用 chr(255) 或 z 字符作为查找范围的小帮手是个好主意吗? (简化示例:af-07-01|39-ef-98|12-52-98 ... 要获取从第一部分开始的所有密钥,start_key 将是 af-07-01| 和 end_key af-07-01 |z)
    • 如您所说,如果您需要访问子范围(而不是整个 CF),那么您的方法将行不通。 CF 中的所有行都是随机顺序的,因此在两个键之间选择一个范围不仅会以随机顺序返回键,而且会在该范围内返回非“逻辑”键,因为所有键都是随机顺序.
    • 感谢您回到这个问题!因此该方法仍然需要手动索引或将数据拆分为块。与更多 ColumnFamilies 合作怎么样?假设我创建了 15.000 个 ColumnFamilies 以提供更轻松的管理级别(每个数据库一个)?这可以成为一种可行的替代方法吗?根据我的阅读,这可能是一个很大的内存问题,因为 Cassandra 如何为每个 CF 分配内存。在当前版本中是否仍然如此?
    猜你喜欢
    • 1970-01-01
    • 2014-02-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-12-17
    • 2022-09-23
    • 2011-10-21
    • 1970-01-01
    相关资源
    最近更新 更多