SingleStore/MemSQL千万级1KB JSON的OLTP最优存储方案咨询

一、拆分表方案的可行性 #

完全可行，具体优势和注意点如下：

• 主表采用行存储，仅存储id, session_id, json_id, created_date, meta_data_1, meta_data_2，这类小字段组成的行数据内存占用极低，能高效支持按created_date排序、meta_data_1/2筛选，以及同会话批量查询的场景，完全匹配你的业务需求。
• JSON单独存入列存储表，设置columnstore_segment_rows<10000后，单个segment大小约为10MB（10000条×1KB），彻底解决原方案中1GB segment导致的内存不足问题。同时列存储的压缩特性仍能有效节省存储空间，且因为不需要对JSON做索引或OLAP操作，完全不影响查询效率——批量查询5-10条时，通过json_id关联两张表的开销可以忽略。
• 注意给两张表的json_id建索引：主表的json_id建普通索引，JSON表的json_id设为主键或唯一索引，确保关联查询的性能。

二、其他内存友好型替代方案 #

除了升级内存，还有以下几种更轻量化的方案：

1. 直接调整现有列存储表的segment大小 #

无需拆分表，直接修改当前列存储表的columnstore_segment_rows参数至10000以内，单个segment大小降至10MB级别，从根源解决内存占用过高的问题。这是成本最低、改动最小的方案，完全适配你的业务场景（无需JSON字段的OLAP操作）。

2. 行存储表+JSON字段压缩 #

直接使用行存储表存储所有字段，对JSON字段启用数据库自带的压缩功能（如MySQL的COMPRESS()函数、PostgreSQL的pg_compress）。JSON文本的压缩率通常能达到30%-50%，大幅降低存储和内存占用，同时不影响按元数据筛选、排序以及批量查询的性能。

3. 利用数据库的大字段分离存储特性 #

部分数据库支持自动分离大字段：比如PostgreSQL的TOAST机制，会自动将超过行大小限制的JSON字段存储到单独的TOAST表中，主表仅保留指针；MySQL的InnoDB也支持将大字段存到外部溢出页。这种方式无需手动拆分表，既能保留行存储在筛选、排序上的优势，又避免大JSON字段占用主内存。

4. JSON文件系统存储 #

如果业务对JSON和元数据的事务一致性要求不高，可以将JSON文件存储到本地文件系统或轻量对象存储，主表仅存储JSON文件的路径。查询时先从主表筛选出目标记录，再读取对应的JSON文件，这种方式完全不占用数据库内存，适合批量小数量查询的场景。

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