现在互联网业务单表过亿是很正常的,再优化索引还是性能不够理想,比如说某个股票交易软件的评论区域,这 A 股 3 千多只,每天产生 100 条,一年就过亿了,这种情况下计算时分片查找的话也是性能不够理想,当然很多数据都是老的,不使用的,可以做冷热分离,但是这样维护起来就太麻烦了。 使用数据库中间件的话比如 mycat 联表又不方便而且单个分片卡会造成性能问题。 现在个大公司类似的场景都使用什么解决方案呢?多谢诸位
1
batter 2018-10-12 11:41:26 +08:00
海量数据还用 mysql,应该不会吧,mysql 作为数据的最后备份,而不是查询主体吧
|
2
jswh 2018-10-12 11:41:30 +08:00
MySQL 分库分表都不能适应的时候,业务的有不愿改变,可以考虑换数据库。评论这种可以考虑稳定数据库,或者 tidb 这种分布式数据库。
不过,在那之前,确保缓存用好了。个人对数据理解,一个是数据落地的地方,还有就是事务处理中心,其他查询的问题,大部分情况可以用加机器和加缓存解决。 |
3
jswh 2018-10-12 11:42:14 +08:00
稳定数据库-〉文档数据库
|
4
ihavecat 2018-10-12 11:49:31 +08:00
es、hbase 都可以阿
|
5
0ZXYDDu796nVCFxq 2018-10-12 11:50:25 +08:00 via Android
搜索评论里的内容?
可以把评论内容放 Elasticsearch 上做全文索引,搜索评论文本时调用 ES |
6
wsc449 2018-10-12 13:16:25 +08:00
建议 mysql 数据 同步到 Elasticsearch
|
10
fireapp 2018-10-12 17:21:56 +08:00 via iPhone
@cc959798 只是展示评论,3000 支股票分 3000 张表啊,简单粗暴🤭,数据一下缩小 3000 倍
|
13
summerwar 2018-10-12 17:49:30 +08:00
再多的数据也没有 Google 索引的数据多,到时候参考 Google 使用的方法就是了
|
14
realpg 2018-10-12 18:25:23 +08:00
@cc959798 #12
基于查询历史统计的优化分库分表 因为你之前没提出这些问题,黑箱基于外面大家掌握的信息给你的按照股票分表 如果你掌握更多的查询细节 那就可以按照生产环境的实际情况自定义更符合你环境的分表分库方法 |
15
privil 2018-10-12 18:51:53 +08:00 via Android
TiDB 了解一下
|
16
Leigg 2018-10-12 18:56:54 +08:00 via iPhone
hbase 了该一哈,如果你是负责人,你应该走在身边所有人的前面,如果你不是,告诉你,你也是懂个概念。
|
17
likuku 2018-10-12 18:58:38 +08:00
充分利用缓存,每日统计热点,可以空闲时,主动对涉及热点的评论“预热”,主动让它们进驻缓存。
或者,最近一周/一个月 发出的评论/"新帖" 优先主动推进缓存里。 |
18
akira 2018-10-13 00:22:06 +08:00 1
当数据量去到亿级别的时候,就别嫌麻烦了。 单台数据库的负荷终归是有上限的,该拆表拆,改分库分
|