关于高频读写 mysql 数据库的设计

2019-12-31 12:59:56 +08:00
 wsldl123292

有一个需求,是从 kafka 读取数据入 mysql,数据要保证实时性,要及时入库和查询, 现在是的数据量大概每天 30 万,基本是每秒 4 条的频率 现在的问题是在写入的同时再去查库,会导致查询变慢,有什么好的方案吗?

由于硬件限制,只有台 8g 的机器,没有办法分布式多节点

6085 次点击
所在节点    MySQL
29 条回复
netnr
2019-12-31 13:10:19 +08:00
当天 30 万的数据用内存,隔天(半天、小时)入库
wsldl123292
2019-12-31 13:15:29 +08:00
@netnr 我要实时查询的
wsldl123292
2019-12-31 13:15:52 +08:00
一台机器,8g 内存,要部署 kafka,mysql,web 应用
opengps
2019-12-31 13:16:22 +08:00
每秒 4 条,写入压力并不大,但是大量读取,你得用从库了
opengps
2019-12-31 13:16:54 +08:00
缓存解决,把最新数据留在内存里,查询时候不用去硬盘
kop1989
2019-12-31 13:18:30 +08:00
写库 30 万条还算可以,关键是查询压力如何?查询跨度如何?得说明白才好分析。
widdy
2019-12-31 13:22:05 +08:00
内存表。
wsldl123292
2019-12-31 13:24:13 +08:00
@kop1989 做了分表处理,主表基本会保持在 2000w 左右的数据,查询是跨 3 到 4 张表
lhx2008
2019-12-31 13:25:45 +08:00
一次拿多条,一条语句插完全没有问题,查询看你是索引还是文本,查的量有多少,我建议写多一份 redis 或者是 LSM Tree 的数据库。kafka 的数据等 mysql 落库再删。
wsldl123292
2019-12-31 13:31:32 +08:00
@lhx2008 数据还有各种查询条件,还要做到实时展示,不好弄 redis
optional
2019-12-31 13:33:51 +08:00
每秒 4 条并不算高,看过查询计划哪一步比较慢吗?理论上并不会慢,调个参数试试?
encro
2019-12-31 13:36:10 +08:00
查询慢 explain 看看结果?
确定查询满是因为写导致的吗?
encro
2019-12-31 13:37:56 +08:00
每天 30 万真的不多。
阿里云最便宜的 rds,也可以支持每天 30 万订单(订单明细,日志等加起来肯定不止 30 万)。
wsldl123292
2019-12-31 13:38:08 +08:00
@encro 大部分的 sql 都看过了,都走了索引,把写停掉就能快不少
derrick1
2019-12-31 13:40:11 +08:00
读写分离
encro
2019-12-31 13:43:03 +08:00
@wsldl123292
写是无序的( innodb 主键不连续)导致索引重建或者锁表?

1,开启慢日志吧;
2,然后 show full processlist,看处于什么状态。
authony2020
2019-12-31 13:51:39 +08:00
30 万不大吧,配置确实有点低
sudoz
2019-12-31 13:52:49 +08:00
每秒 4 条插入,不是常规理解的“高频写”
wsldl123292
2019-12-31 14:02:30 +08:00
@encro 应该是,主键是 uuid
encro
2019-12-31 14:08:53 +08:00
@wsldl123292
主键不能是 UUID,会导致索引重排(除非你 UUID 是递增的参考另外一个帖子使用 SnowFlake )

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/633870

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX