1
reus 2012-04-17 23:34:12 +08:00
分表,升硬件,调参数,换引擎,总能撑得住的
|
2
ElmerZhang 2012-04-17 23:40:12 +08:00
分表喽。。。
|
3
whtsky 2012-04-17 23:42:57 +08:00 via Android
拆表...
|
4
napoleonu 2012-04-17 23:49:59 +08:00
没有这样的说法。
|
5
mywaiting 2012-04-17 23:52:39 +08:00
要是那样FB不是早就挂了啊!
|
7
summic 2012-04-18 00:06:30 +08:00
我们的一个单表就有2000万,有点慢,不一定非要分库分表,看业务,用partition也可以解决
|
8
reus 2012-04-18 00:08:26 +08:00
http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
Facebook uses MySQL, but primarily as a key-value persistent storage, moving joins and logic onto the web servers since optimizations are easier to perform there (on the “other side” of the Memcached layer). 也不会只用一种数据库系统的。 |
11
virushuo 2012-04-18 00:22:41 +08:00
处理的好就没问题。抓虾当年以每天几百万的速度写入mysql,总量惊人。当然他们做了不少优化。
|
14
Johnny 2012-04-18 06:37:10 +08:00
2000w 你要是不用复杂查询的话 小意思
|
15
feiandxs 2012-04-18 08:00:20 +08:00
既然楼主说的是听说,那说明楼主还没遇到2000万记录+严重性能问题。
在从听说变成遇到的时间内,我觉得智慧的楼主完全能够解决这个问题~~ 你想想你见过的一些还在用早期版本的discuz论坛,轻松过2kw帖子,也挺欢快的。 |
16
darasion OP @feiandxs 听说是不假;
但是最近项目决策换用一种改进后的 mysql ,其中有一条原因就是标题中提到的这个2kw。 换用需要做很多的改动,很多的查询不支持,有很多限制,整个代码都要改动。 我就想求证下这种决策是否有必要。我知道我改变不了这个决策,也不想改变什么,只是纯好奇,想知道为啥要这样做。 |
17
likuku 2012-04-18 09:16:45 +08:00 via iPhone
用myisam似乎记得单表有超过1亿记录的。
|
18
vitohe 2012-04-18 09:19:52 +08:00
|
19
likuku 2012-04-18 09:22:50 +08:00 via iPhone
大内存(>64G)+SSD RAID5+多核多CPU,问题不大的
|
20
muxi 2012-04-18 09:24:39 +08:00
这个不能一概而论,2000w不知道楼主从何处得来,或者是多久以前别人得出的结论,现在软件都在发展,MYSQL 5.1和5.5的改进不是一点点,硬件也在改进,内存现在随便就能到32G,即使是5.1,2000w这个数字非常不靠谱,我经历的项目中,有不少单表超过8亿条的数据,适度优化后,增删改查速度也没有很多的下降,还能正常使用,唯一头痛的是当你改变表结构的时候会非常花时间,所以2000w这个数字更多的是出于表结构变更成本上的考虑。
如果你的表结构不是经常变更,没有大量的join操作,2000w这个数字有点保守了,当然坏的数据操作方法其实用不了2000w就会产生大量的慢查询和程序异常。 道听途说是不准的,分表是个好的方法,但首先是要改进你的数据库操作方式,不然即使分表了,依然会有很多问题,而且在某些情况下分表带来的维护工作量远远超过单表,最简单的例子就是当你的查询条件不包含你分表的条件的时候,查询就很痛苦。 |
21
napoleonu 2012-04-18 09:27:58 +08:00
过早优化是万恶之源,等问题来了再解决,身轻如燕。
|
22
magic22cn 2012-04-18 09:36:33 +08:00
table partition
|
23
darasion OP 更新一下,
最后终于大家忍受不住它的不稳定,经过研究和pk,又开始计划换回普通的 mysql 了。 ╮(╯_╰)╭ 而且据开发这个的人说,本来是用来做非常大的数据存储的,开发时并没有考虑功能强大,只是满足巨大的单个表的高并发增删查改需求;并不适合像我们那个项目使用。 |
24
lyxint 2012-06-13 22:46:10 +08:00
我这里的mysql, 九千万条数据, 没有复杂查询,没有问题
|
25
noahasm 2012-06-13 23:53:13 +08:00
单表1.4亿条记录,数据库目录168G,无压力。
|
26
maddot 2012-06-14 00:07:42 +08:00
以前我维护过一个日增50多万记录的表,总数过亿,分区加合适的索引后,没啥问题
|
27
regmach 2012-06-20 06:34:27 +08:00
搭车问4表(其中2个百万左右,2个百以内)同时读取,会不会很影响效率?
|