请耐心等待稍长的问题描述。我是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的新因素，并考虑将其分配为一天中的小时值，以进一步将分区划分为更小的块，并将其保持在100mb以下(尽管这意味着我必须进行24次读取才能在一天内提供流量详细信息，但我对读取效率低下的问题很满意(。以下是bucket-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毫巴，而所有其他音量都舒适地位于该范围内。
考虑到这种情况，我有以下问题：
- 您的分区很少超过100mb的限制，这绝对是一个错误吗
- 尽管使用更小的bucket(比如15分钟窗口(，我可以获得低于100 mb的所有分区键组合，但这也会产生严重的倾斜分区，这意味着分区键的高容量组合可以达到80 mb，而剩余的一次则远低于15 mb。这是否会对集群的性能产生不利影响
- 有更好的方法来解决这个问题吗
以下是一些我认为可能有用的更多信息：
- 此实体的平均行大小约为200字节
- 我还考虑了2的负载未来证明系数，并估计负载是原来的两倍
- 分区键的特定组合的峰值负载在一天内约为280万条记录
- 同一组合的高峰交通时间约为140万条记录
- 15分钟窗口内的相同记录约为550000条
提前感谢您的投入！！
使用bucket id的方法看起来不错。回答您的问题：
- 不，这不是一个硬性限制，实际上，考虑到过去几年的硬件改进，它可能太低了。我见过2GB和5GB的分区(尽管它们在进行修复时会让你头疼(，但这些都是极端情况。不要接近这些价值观。最重要的是，如果你不超过100MB，你会没事的。如果你有至少15GB的内存，那么使用G1GC，你就是黄金
- 分区大小的均匀分布对于保持整个集群的数据负载平衡很重要，这也很好，这样你就可以确信你的查询将接近平均延迟(因为它们将读取大致相同大小的数据(，但这本身不会带来性能问题
- 这种方法看起来不错，但如果这是一个时间序列，我认为它考虑了你所说的，那么我建议你在
my_system.my_system_log_dated中使用TWCS(时间窗口压缩策略(。检查如何配置此压缩策略，因为您设置的时间窗口非常重要
我能够安装bucketisation，以防止由于任何意外的流量峰值而对集群健康造成任何风险。此处已对此进行了描述https://medium.com/walmartlabs/bucketisation-using-cassandra-for-time-series-data-scans-2865993f9c00