每天日志300G数据写入，求架构设计推荐

[LKLK]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【概述】每天日志300G数据写入，求架构设计推荐

【背景】每天日志300G数据写入，求架构设计推荐

【现象】每天日志300G数据写入，求架构设计推荐
【TiDB 版本】v5.0.2
线上一日志业务(只有写入和查询)，每天数据量大概300G，大佬们能否给个架构规划建议？几个pd，几个tidb，几个tikv，几个tiflash ？磁盘做raid 几？

【附件】

• 相关日志 和 监控

1. TiUP Cluster Display 信息

2. TiUP Cluster Edit Config 信息

3. TiDB- Overview 监控

• 对应模块日志（包含问题前后1小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[qizheng]

• 写入和查询比例多少，有多少列，每行的宽度多少
• 写入的数据是否有时序上的顺序性，表上有多少索引
• 存量数据打算保留多少天，数据有没有冷热之分和历史数据清理
• QPS 和吞吐量一天是如何分布的，高低峰值各是多少，延迟有没有要求
• 查询都是哪种类型单表还是多表 join 偏 TP 还是偏 AP
• 之前在什么集群上面运行，当前是否遇到了什么问题

[LKLK]

1、写入90%，查询10%，主要是有张按天分的物品表（每天数据大概200G），有10个字段
2、写入的数据有时序上的顺序性，表上有5个索引
3、数据保留2个月就可以，历史数据可以drop掉
4、QPS我看最高到5W. 不能有延迟，要不数据会缓存在server 端，内存会爆掉
5、 查询都是多表 join，需要TIFlash
6、目前是主从MySQL ，磁盘20T SSD raid 5在顶，快顶不住了

[qizheng]

1. 硬件配置参考官网建议配置部署，可适当提高 TiKV 配置如16核64G
2. 实例数量建议 3个PD，至少 3个TiDB（跟 cpu load 有关），至少10个TiKV（本地 NVME SSD，满足 4.5W 高写入，单盘2~3TB），至少 2个TiFlash（也跟待同步表的容量有关）
3. 表结构考虑使用 auto_random 主键，索引顺序写入可能有少量热点；考虑按日期进行 range 分区，drop 历史分区便于快速回收空间
4. 写入建议使用 batch，减少 RPC 交互开销，可以测试不同 batch 大小，寻找达到较高吞吐量的区间，本地测试环境模拟不同 batch 如下
   
5. 表中如果存储日志信息，存在宽列如接近或超过 1kb，需要考虑开启 [titan]，减少写放大(https://docs.pingcap.com/zh/tidb/stable/titan-overview)

[LKLK]

谢谢你，我准备搭建起来测试下