请容忍我稍微长一点的问题描述。我是cassandra world的新手，我正在尝试将我当前的产品从基于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);

现在，我遇到了几个文档/参考资料/博客，其中提到我应该将分区大小保持在100MB以下，以获得最佳性能的集群。对于分区键的特定组合，我的系统每天处理的通信量，我不可能用上面的分区键将其保持在100MB以下。
为了解决这个问题，我引入了一个名为bucket\u id的新因子，并考虑将它分配为hour of the day值，以便进一步将分区划分为更小的块，并将它们保持在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);

即使这样，两个卷的组合也可以超过100MB，而其他卷都可以轻松地保持在这个范围内。
考虑到这种情况，我有以下问题：
让很少的分区超过100MB限制是绝对的错误吗？
尽管使用更小的bucket（比如说15分钟窗口），我得到的分区键的所有组合都在100MB以下，但这也会造成严重的分区倾斜，这意味着分区键的高容量组合会上升到80MB，而剩余的一次则远远低于15MB。这是否会对集群的性能产生不利影响？
有没有更好的办法解决这个问题？
以下是我认为可能有用的更多信息：
此实体的平均行大小约为200字节
我还考虑了2的负荷未来证明系数，并估计为负荷的两倍。
特定分区密钥组合的峰值负载在一天内约为280万条记录
同样的组合也有大约140万个高峰小时的记录
在15分钟的时间内，这一数字约为55万条。
提前感谢您的投入！！