【问题标题】:How to query Cassandra by date range如何按日期范围查询 Cassandra
【发布时间】:2010-08-20 21:29:30
【问题描述】:

我有一个 Cassandra ColumnFamily (0.6.4),其中包含来自用户的新条目。我想向 Cassandra 查询这些新条目,以便我可以在另一个系统中处理这些数据。

我的感觉是我可以使用 TimeUUIDType 作为我的条目的键,然后查询以 "" 作为 startKey 或任何 lastStartKey 开头的 KeyRange。这是正确的方法吗?

get_range_slice 是如何实际创建范围的?它不必知道密钥的数据类型吗?任何地方都没有声明键的数据类型。在 storage_conf.xml 文件中,您声明列的类型,但不声明键的类型。是否假定键与列的类型相同?或者它会做一些神奇的嗅探来猜测?

我还看到了人们将 TimeUUIDType 存储在列中的参考实现。但是,这似乎存在规模问题,因为这个特定的密钥会变得“热”,因为每次更改都必须更新它。

在这种情况下的任何指针将不胜感激。

【问题讨论】:

    标签: nosql cassandra


    【解决方案1】:

    在对数据进行排序时,只有列键很重要。存储的数据无关紧要,自动生成的时间戳也无关紧要。 CompareWith 属性在这里很重要。如果将 CompareWith 设置为 UTF8Type,则键将被解释为 UTF8Types。如果将 CompareWith 设置为 TimeUUIDType,则键会自动解释为时间戳。您不必指定数据类型。查看此页面上的 SlicePredicate 和 SliceRange 定义http://wiki.apache.org/cassandra/API 这是一个很好的起点。此外,您可能会发现这篇文章很有用http://www.sodeso.nl/?p=80 在第三部分左右,他谈到了对他的查询进行切片等。

    【讨论】:

    • 我知道您可以使用列键进行排序。但是,如果我要为我的集合中的每个项目写一个时间戳列,我会不断地写一个列族,这会创建一个热点。
    • 我没听懂你的评论。你能详细说明一下吗?就列键而言,Cassandra 会在您存储后立即根据键(或 Cassandra 约定中的“名称”)对整个列(超列)进行自动排序。另外,如果您可以详细说明您的用例,那将有所帮助:)
    【解决方案2】:

    道格,

    如果您使用的是 Order-Preserving Partitioner,写入单个列族有时会产生热点,但如果您使用的是默认的 Random Partitioner,则不会(除非一部分用户创建的数据比所有其他用户多得多! )。

    如果您按时间对您的 进行排序(使用 Order-Preserving Partitioner),那么您可能更有可能创建热点,因为您将按顺序添加行并且单个节点将负责对于键空间的每个范围。

    【讨论】:

      【解决方案3】:

      列和键可以是任何类型,因为行键只是第一列。 实际上,集群是一个循环散列密钥环,并且密钥由分区器散列以分布在集群周围。

      但是,请注意使用日期作为行键,因为即使是默认随机分区器的随机化也是有限的,您最终可能会弄乱您的数据。

      此外,如果该日期发生变化,您将不得不删除前一行,因为您只能在 C* 中进行插入。

      这是我们所知道的:

      • 切片范围是具有起始值和结束值的行中的列范围,这主要用于宽行,因为列是有序的。然而,CF 中定义的已知列名已编入索引,因此可以通过指定名称来检索它们。
      • 键切片,是与 Cassandra 返回的切片列范围关联的键
      • 相当于 where 子句使用二级索引,您可以在那里使用不等式运算符,但您的语句中必须至少有一个 equals 子句(另请参阅https://issues.apache.org/jira/browse/CASSANDRA-1599)。
      • 使用键范围对 Random Partitionner 无效,因为您的键的 MD5 哈希不会保持词法顺序。

      您要使用的是使用 Wide Row 的基于列族的索引: CompositeType(TimeUUID | UserID) 为了不让它变热,请添加第一个有意义的键(“分片键”),它将跨节点(例如用户类型或区域)拆分数据。

      在 Cassandra 中拥有比所需更多的数据不是问题,而是它的设计方式,所以您必须问自己“我需要查询什么”,然后为其设计一个列族,而不是试图适应所有内容在一个 CF 中,就像您在 RDBMS 中所做的那样。

      【讨论】:

        猜你喜欢
        • 2018-04-10
        • 2017-11-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多