Question

请耐心等待，以获取更长的问题描述。我是Cassandra世界的新手，我正在尝试将当前产品从基于oracle的数据层迁移到Cassandra。

为了支持范围查询，我创建了如下所示的实体：

create table if not exists my_system.my_system_log_dated(
  id uuid,
  client_request_id text,
  tenant_id text,
  vertical_id text,
  channel text,
  event text,
  event_type text,
  created_date date,
  primary key((created_date, tenant_id, vertical_id, channel, event), 
  event_type, client_request_id, id)
) with clustering order by (created_date desc);

现在，我遇到了一些文档/资源/博客，其中提到，为了保持最佳性能，我应该将分区大小保持在100 mb以下。对于某些分区键组合，我的系统每天要处理的流量非常大，因此无法使用上述分区键将其保持在100 mb以下。

为解决此问题，我引入了一个名为bucket_id的新因子，并正在考虑为其分配一天中的小时值，以将分区进一步分成较小的块并将其保持小于100 mb（即使这意味着我必须进行24次读取提供一天的交通详细信息，但我的阅读效率有些低下）。这是具有存储区ID的架构

 create table if not exists my_system.my_system_log_dated(
  id uuid,
  client_request_id text,
  tenant_id text,
  vertical_id text,
  channel text,
  event text,
  bucket_id int,
  event_type text,
  created_date date,
  primary key((created_date, tenant_id, vertical_id, channel, event, 
  bucket_id), event_type, client_request_id, id)
) with clustering order by (created_date desc);

即使如此，超过100 mb，而其他所有音量都在该范围内。

考虑到这种情况，我有以下问题：

只有很少的分区超出100 mb的限制是绝对的错误吗？
尽管在较小的存储桶中说15分钟的窗口，但我得到的所有分区键组合都在100 mb以下，但是这也会产生严重偏斜的分区，这意味着高容量的分区键组合会升至80 mb，而剩下的一次就在15兆字节这会对我的集群性能产生不利影响吗？
是否有更好的方法来解决此问题？

以下是我认为可能有用的更多信息：

该实体的平均行大小约为200个字节
我还考虑了将来的负荷证明系数2，并估计负荷将增加一倍。
特定分区键组合的峰值负载一天约为280万条记录
同一组合的高峰时间约为140万条记录
在15分钟内，大约有550,000条记录。

提前感谢您的输入！

Answer 1

您使用存储桶ID的方法看起来不错。回答您的问题：

不，这不是硬性限制，实际上，考虑到最近几年的硬件改进，它可能太低了。我见过2 GB和5 GB的分区（尽管它们在进行修复时会给您带来很多麻烦），但这是极端的情况。不要接近那些值。底线是，如果您不超过100 MB，则可以。如果您的RAM至少为15 GB，请使用G1GC，这是黄金。
分区大小上的均匀分布对于保持整个群集中的数据负载平衡很重要，这也很好，因此您可以确信查询将接近平均延迟（因为它们将读取近似值）。相同大小的数据），但它本身不会带来性能问题。
这种方法看起来不错，但是如果这是一个时间序列，我认为它考虑到了您所说的话，那么我建议您在my_system.my_system_log_dated中使用TWCS（时间窗口压缩策略）。请检查如何配置此压缩策略，因为您设置的时间窗口非常重要。

Answer 2

我能够进行设备存储桶化，以防止由于意外流量高峰而对群集健康造成的任何风险。 https://medium.com/walmartlabs/bucketisation-using-cassandra-for-time-series-data-scans-2865993f9c00

已在此处进行了描述

流量偏斜的系统的Cassandra分区策略

2 个答案: