singer
147 天前
我来讲一个方案给楼主点思路。
我在广告方面做过一些项目，热点数据量在几亿条，存储占用四五 T ，需要秒级别延迟下的数据检索。
开始我们用了 starrocks ，但 starrocks 在广告场景下密集写入数据后搜索性能极差（这里不是点 starrocks ，只是我们在用这个。实际上各种号称大数据搜索的都有这种问题）。线上事故不断，资损动不动就是几十万，巅峰时期 3 天 4 个线上事故。
后来我们想了一个办法，搜索的字段和内容是固定的。我们动用了两套数据库，一个是常规的大容量存储，保证原始数据不丢失（这块我们不用于线上查询，偶尔 T+1 检索，目的是保证数据可以用来恢复业务需要的数据以及数分团队抽数分析），另一个是 Redis ，通过 ETL 方式将数据通过规则（规则是可配置的，比如“今天是星期天”，分词后就是“今天”，“星期天”）写入 Redis 作为索引。
* 检索：检索的时候仅查询 Redis ，从 Redis 中查到原始数据的索引，再去获取需要的数据
* 数据重刷：规则是固定的，随着业务的发展，规则需要变更。分词变更成“今天是星期天”要分词成“今天”，“2024/07/30”，“星期天”，“2024/08/04”，这个时候只能重刷数据。刷数就会导致未知风险，为了保证线上可以无感切换，我们还准备了两条数据链路，刷数链路清完数据开始从大容量存储里捞数据，重建影响范围内的数据。刷完后切换查询数据源。再把原来的数据链路重复上面的步骤。
以上一把操作后，我们的热点数据存储从之前的几 T 变成了百 G 。热点数据的数据量上的降低让我们系统 SLA 从 95%提升到 99.9%以上，接口耗时从 200 ～ 300ms 变成了 5ms 。
-----
ES 对于千万级别的数据用起来还算顺手，但数据量上去后 C 端接口抖动真的难以优化。如果有预期数据量在短期有数十倍增长就不必折腾了。B 端业务可以上，B 端接口 10ms 与 200ms 的感知不明显。