这是一个创建于 3501 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在和同事一起创业，是移动互联网的项目。现在还是设计初期，考虑到后期可能的用户增长，如果用户数达到了千万级，对一张表进行查询肯定会慢，但是要分表可能会有其它问题。我考虑的分表，如果是按月份分，后期的数据一个月内可能就会达到千万级，那这样分就没什么意义了。如果是先创建好所有的分表，按照平均的规则写入到各个表中，查询的时候就不知道怎么查了。特地来这里问问各位，遇到这种问题应该怎么解决呢？
 |
1
willvvvv 2015-05-26 14:58:51 +08:00
具体的业务场景描述一下
|
 |
2
moro 2015-05-26 15:01:09 +08:00
有个标准，就是可以很容易做到水平扩展。
|
 |
3
Septembers 2015-05-26 15:04:58 +08:00
数据规模不是问题 表结构设计合理性 才是大问题
数据规模上来啦无非就是 分库 分表 主写从读 集群化 |
 |
4
wy315700 2015-05-26 15:06:10 +08:00  2
先上线吧 我觉得你们想多了，
|
 |
5
justlikemaki OP @willvvvv 主要是对用户的查询这方面，考虑到后期用户量大，一个登录可能就会很慢，连表的查询也会慢，所以寻求分表的规则或者是标准。
|
|
6
Septembers 2015-05-26 15:06:39 +08:00
数据库选型也很重要 我PgSQL单表几十亿都不是问题
|
|
8
justlikemaki OP @Septembers 就是说可以先用一张表，数据上来了再分开？我现在的主要问题就不知道到底该怎么分表啊。。。
|
|
9
justlikemaki OP @Septembers 我也是打算用pgsql的。
|
|
10
wy315700 2015-05-26 15:10:12 +08:00 1
|
 |
11
ifconfig 2015-05-26 15:10:59 +08:00 1
mysql5.1之后有分区技术，业务都写好了再拆表岂不是要重构代码，而且楼上说的数据库选型也很重要 PgSQL单表几十亿都不是问题
|
|
12
Septembers 2015-05-26 15:13:35 +08:00 1
如果用户真发展到那个规模了 你也不缺钱请DBA
|
 |
13
JoeShu 2015-05-26 15:33:22 +08:00
想太多，过度优化是万恶，技术是可以迭代的，等用户达到那个量级再优化。
|
 |
14
huijiewei 2015-05-26 15:45:05 +08:00
噗。还没开始你就想着千万级的优化？ 想太多了啊
|
 |
15
em70 2015-05-26 15:49:02 +08:00 1
大多数失败的项目,都是败在只有100人的考虑1亿用户的事情,互联网项目需要小步快跑
|
 |
16
vinceguo 2015-05-26 16:00:25 +08:00
数据量这么大为什么还要用mysql?
直接上hadoop, hive, hbase, spark, 随便玩. |
 |
17
gamexg 2015-05-26 16:06:06 +08:00
搭车问一个问题，类似与监控宝ping日志怎么保存比较好？
直接存数据库是不是太坑了？ 1000站点 * (24*60)/5 = 288000。 一天288000条日志，1个月8640000条。 直接存文本文件？查询比较麻烦些... |
 |
18
huobazi 2015-05-26 16:08:34 +08:00
等你一个月千万级时你的钱肯定够买 100 个 DBA 帮你搞定这事情了
|
 |
19
publicID001 2015-05-26 16:10:17 +08:00 1
@gamexg 不坑
|
 |
21
h2ero 2015-05-26 16:15:27 +08:00
过早优化不太好。
|
 |
23
lyragosa 2015-05-26 16:50:51 +08:00
过度优化是万恶！
|
 |
24
wdongxv 2015-05-26 16:54:16 +08:00
现在2千多万，还没分表，啥时候撑不住再分
|
 |
25
zhicheng 2015-05-26 16:58:22 +08:00 via Android
才千万。。。你们也太小瞧数据库了。
|
 |
26
xiaoyuvps 2015-05-26 16:59:33 +08:00
到500W再研究不好么？
|
 |
27
a398058068 2015-05-26 17:15:51 +08:00 1
这个不着急。 主从复制 ， 分库分表。 这些后面弄都可以。 特别是用户表这种一般都有自增长主键 要做分库分表很简单 再加个主从 主写从读 千万不是事
|
 |
28
winnie2012 2015-05-26 17:34:52 +08:00
选 PostgreSQL，另外：先上线吧 我觉得你们想多了。
|
 |
29
server 2015-05-26 17:36:38 +08:00
不要过早优化
|
 |
30
yanze0613 2015-05-26 17:42:42 +08:00
等你们如果用户数达到了千万级，之前，雇个专业的架构师和DBA吧
|
 |
31
wadezhao 2015-05-26 17:50:13 +08:00 1
楼主等你有了一千万用户，我确信解决方案自己biu的就蹦出来了，不是开玩笑…………
|
 |
32
MarsWang 2015-05-26 20:28:41 +08:00 via iPhone
千万级单表没啥问题，量上来在说吧
|
 |
33
wmttom 2015-05-26 20:32:00 +08:00 1
@gamexg
现在在用 InfluxDB 放 API 的请求统计 event，感觉还不错，用的是 StatsD+InfluxDB+Grafana，自己订制的 gunicorn 自动收集每个 API 的请求统计数据。 |
 |
35
tangooricha 2015-05-26 22:38:19 +08:00
@justlikemaki 在我们这，这个级别已经进hadoop集群了。
|
 |
36
billwang 2015-05-27 08:18:37 +08:00 via Android
先把现在做好吧，这是真心话
|
|
37
gamexg 2015-05-27 16:20:13 +08:00
@publicID001 感觉数量多了会挂掉...
@mhycy 印象中mongodb很耗内存，做设备日志记录的时候测试一下。 @wmttom 看着正合适，用的时候细看下... @frankzeng 经典的解决方案。 |
 |
38
rrrrutdk 2015-05-29 14:16:10 +08:00
我就是这样过度优化结果什么也没做出来。
看你的业务规则吧，比如用户登录时需要选定城市或部分等，如果没有的话，按一定的前缀分表： 例如： 如果你的网站支持手机登录，即手机号与用户编号绑定的话，使用号段分表，158, 153, 189等等，查询数据库前自己先判断号段再选择表名； 如果你的网站使用登录名，可以以字母表分表，a-z0-9等等，同样在查询前先判断登录名第一位。当然，要是觉得两位也能接受也行，即aa, ab, ac, .....分表； 如果同时支持手机号与登录名，先手机号再登录名按上述处理。 |
|
39
rrrrutdk 2015-05-29 14:17:23 +08:00
靠，我又没仔细看就在这里BB。钻地中……
|
Select Language