千万级表，读写相当频繁，该用什么思路去优化？

问题是这样的，有三张表，user, foo, bar。每张表的字段数都在10以上。其中foo量级在5000w，bar在20000w。这两张表的某些字段（每张表两个左右）每天都会更新一遍。foo表每天增加1w，bar表每天增加200w。foo.user_id = user.user_id, foo.foo_id = bar.bar_id。
有上百台服务器，每台服务器有50个左右的mysql连接（无法做连接池）。数据库并发连接数在4000左右，且每个链接都是更新操作为主。
目前的方案是，在mysql上通过thrift实现一层http的service，提供api，每台服务器来调用api进行数据更新。
拆表方面，打算把user,foo和bar垂直拆表，将不需要更新的字段和需要更新的字段分开。必要时再将需要更新字段组成的表再做水平拆表。

不知道大家有没有这方面的经验，欢迎大家提供更好的方案

foo

bar

user

9 条回复 • 1970-01-01 08:00:00 +08:00

master

2013-09-06 14:19:38 +08:00

只是foo.user_id = user.user_id, foo.foo_id = bar.bar_id这样的关系的话，其实可以考虑下 NoSQL

BeanYoung

2013-09-06 14:28:44 +08:00

@master 写错了，是foo.foo_id = bar.foo_id

master

2013-09-06 14:37:53 +08:00

@BeanYoung
喔喔，其实主要看这些数据更新记录以后还需要什么样的查询，
如果只是这种这种关系场景的更新我觉得用NoSQL没问题

zhangrentina

2013-09-07 07:36:37 +08:00

水平拆表，读写用master slave分离。有ssd最好了

saharabear

2013-09-07 08:02:55 +08:00

换个好硬件？

yangqi

2013-09-07 10:26:22 +08:00

这个级别肯定要上mysql cluster了，去管网了解一下

likuku

2013-09-08 01:12:56 +08:00

一个master　只管写，「foo表每天增加1w，bar表每天增加200w」，这种普通硬盘RAID足够了。

多个 slave 从 master 同步，最好都是ssd的raid，cpu 也要强，mysql 5.6 以前 slave 单线程从 master 同步，所以CPU和io要足够强才能即时追上master的更新速度。

memcached 机群一定要用，有个日本人作的补丁，可以让多台 memcached 互相自动同步互备。

likuku

2013-09-08 01:30:52 +08:00

抱歉没看到「有上百台服务器，每台服务器有50个左右的mysql连接（无法做连接池）。数据库并发连接数在4000左右，且每个链接都是更新操作为主。」

这个需求貌似在 mysql 上只有 6楼 @yangqi 讲的　“mysql cluster” 才可了。

VYSE

2013-09-08 02:00:03 +08:00

@likuku 用CLUSTER的就要注意简单一句join foo.user_id = user.user_id这种千万级的数据，用完这辈子结果就能跑出来了。
可能只有SCI的连接方案（没试过）解决。
如果只是select/update一个表，倒是没啥大问题，只要注意ndb偶尔crash（log直接显示代码多少多少行有问题或干脆承认就是有个unknown bug会crash）时有个脚本负责花几十分钟冷重启就行了