面对海量且持续的文本流摄取（转写数据），传统的关系型数据库（如 MySQL/PostgreSQL）在高并发写入和复杂聚合查询下几乎必然会崩溃。CXMind 全面采用 ClickHouse 作为核心存储方案，利用其列式存储特性实现大规模计算与聚合。
1. 核心表结构元数据设计 (Schema Meta-Table Design)
sip_messages (信令追踪表)
- 用途: 临时存储原始 SIP 请求追踪日志（HEP v3）。
- 优化: 采用 MergeTree 引擎，并配置自动化的 TTL (Time-To-Live) 滚动过期机制（默认 7 天），确保磁盘空间不被原始信令报文无限堆积。
call_events (呼叫事件主表)
- 用途: 存储呼叫建立、结束、挂断原因等核心事件，是宏观索引与趋势分析的基石。
- 分区键: 按
toYYYYMMDD(event_time)分区，显著提升按天查询的扫描速度。
transcription_segments (转写片段明细表)
- 用途: 记录每一句对话文本、发言人 ID 以及毫秒级时间戳。
- 路由逻辑: 严格依赖
call_id的哈希值作为 SHARDING KEY。这确保了同一通通话的所有片段都落在同一个分片上，从而在进行全文检索或上下文分析时避免昂贵的跨节点 Join 操作。
2. 集群配置策略 (Cluster Configuration Strategies)
针对大规模生产环境，我们推荐采用 2 分片 + 2 副本 (4 节点) 的高可用架构：
- ReplicatedMergeTree 引擎:利用 ClickHouse Keeper (或 ZooKeeper) 实现副本间的数据同步。当主分片节点宕机时，副本节点可实现秒级接管，确保数据零丢失。
- Go 摄取端本地缓冲:为了抵御瞬时流量洪峰，Go 摄取容器内置了基于 BadgerDB 的持久化延迟队列。
Atomic Bulk Inserts高性能异步原子批量写入- 禁止单条记录写入。
- 系统会根据
buffer_size(如 10,000 条) 或buffer_interval(如 2 秒) 自动触发批量写入，利用 ClickHouse 对大块数据顺序写入的极端优化性能。
Need more help or have a specific architecture question?
Contact Engineering Support