这是一个创建于 3801 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在和同事一起创业，是移动互联网的项目。现在还是设计初期，考虑到后期可能的用户增长，如果用户数达到了千万级，对一张表进行查询肯定会慢，但是要分表可能会有其它问题。我考虑的分表，如果是按月份分，后期的数据一个月内可能就会达到千万级，那这样分就没什么意义了。如果是先创建好所有的分表，按照平均的规则写入到个表中，查询的时候就不知道怎么查了。特地来这里问问各位，遇到这种问题应该怎么解决呢？
 | 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 过早优化不太好。 |
 | 22 immjun 2015-05-26 16:19:02 +08:00 @mhycy 试试 PostgreSQL 如何 ? |
 | 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 E2gCaBAT5I87sw1M 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 @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