KDB+历史数据库分区策略咨询：25亿行分钟数据查询性能问题

一、优先选择日期+代码（sym）复合分区 #

虽然你不想按日期分区，但这是kdb+处理时序数据的最优实践，原因如下：

• 你的查询包含t.date维度，按日期分区后，聚合查询可直接按日期分片并行处理，大幅减少单进程需加载的数据量
• 复合分区（日期为一级分区，sym为二级分区）能同时满足单个sym查询（直接定位到对应日期+sym的分片）和跨sym的日期聚合查询（并行遍历日期分片，每个分片内按sym聚合）
• 具体实现步骤：
  1. 按日期将数据拆分至不同目录，例如2024.01.01/、2024.01.02/
  2. 每个日期目录下，对sym做二级分区：建议用sym的哈希值分桶（如分成100个桶），避免3万个sym直接建目录导致文件系统性能下降
  3. 使用.Q.par或分布式查询框架，让16个从属进程并行处理不同分片

二、若坚持不按日期分区，选择sym哈希分桶分区方案 #

如果必须保留完整数据集，按sym分区可行，但需注意以下优化点：

• 不要直接为每个sym单独建分区（3万个目录会拖慢文件系统），而是计算每个sym的哈希值取模，分成N个桶（如1000个，可根据内存和从属进程数调整），每个桶存放一批sym的数据
• 重新尝试压缩：之前启用压缩崩溃，是因为全表加载时解压占用过多内存；分区后单个分片数据量小，内存压力大幅降低，可优先启用zlib压缩（针对数值列如volume、price），IPC压缩更适合网络传输，本地存储优先选zlib
• 内存配置优化：为每个从属进程单独设置内存上限，例如用-s 2G启动每个slave，避免单个进程占用过多内存引发全局OOM；主进程仅负责调度，不参与数据加载，把内存留给从属进程

三、查询语句优化 #

针对你需要执行的desc select sum volume by sym, t.date查询：

• 若采用复合分区，直接用分布式查询：

  desc .Q.par[16;`select sum volume by sym, date from data where date within 2024.01.01 2024.12.31]
  

  .Q.par会让16个从属进程并行处理不同日期分片，每个分片内完成sym和date的聚合，最后由主进程合并结果
• 若采用sym哈希分区，同样用.Q.par指定从属进程数，让每个进程处理一个哈希桶，并行计算后合并结果

四、其他关键优化措施 #

• 确保分区时sym列已排序，这样查询单个sym时可使用二分查找，而非全量扫描
• 分钟级数据中，将time列存储为minute类型而非datetime，减少存储和内存占用
• 检查磁盘IO：若使用机械硬盘，更换为SSD——kdb+对随机IO要求极高，慢磁盘会显著增加查询耗时

内容的提问来源于stack exchange，提问作者cjm2671