mysql 数据量太大的设计方案 ~200T

Question

现在公司要做一个数据库方案，总体目标是要存约 200T 的数据，机器不是问题。已知：表结构很简单，关链是数据量实在是太大。对查询有较高的要求(基本上要让客户体会不到时延)，而且数据会时不时地添加（添加的量也很大，大概一年会升个数量级）有没有人能给点意见，能大致给个方向，不胜感激。

Answer 1

机器不是问题？very good200t拆成20000台机器，每台机器放10g（），基本上能搞定你的需求

Answer 2

机器不是问题？？来个大型机咯
分服务器，分数据库，分表，分区都可以优化，具体看客户需求(例如：客户是否有需求从200T的数据中提取资料？)这么大的数据量，建议还是用orcale吧。

Answer 3

关键看用户的查询。 如果是 select * from table1 什么where 都没有，则什么方法都不行。 如果查询是从每台机的记录集中各取一条，这个时间也不会快。

Answer 4

机器不是问题，话说大了吧？有钱买机器不能买个oracle数据库？

Answer 5

机器不是问题，指空间跟cpu上不用考虑，否则也没设计的前提了。只要拿出合理方案，分配几千个CPU什么的是没问题的。但是在cpu的使用率一定要达到一个级别。如平均35%要不然就是非常严重的浪费。存储也是一个道理，需要用多少就用多少，不够的时候想添就添。

Answer 6

可以考虑用oracle但主要是，用oracle也没有办法啊

Answer 7

oracle的DataWarehouse技术去看看，说不定能找到需要的。
你这里应该是200T的OLAP＋当年的OLTP。数据量大的OLTP，只能用数据仓库了。

Answer 8

建议用oracle 数据库 。

Answer 9

感觉单单oracle也解决不了问题，呵呵。
学习学习。

Answer 10

这里笔误，数据量大的OLAP用DW。sorry。

Answer 11

oracle的BI与数据仓库官方中文文档地址：
http://www.oracle.com/technology/global/cn/tech/bi/index.html
oracle的BI与数据仓库官方英文文档地址：
http://www.oracle.com/technology/tech/bi/index.html

Answer 12

看看http://www.toplee.com/blog/71.html，
http://www.dbanotes.net/web/technorati_db_arch.html，虽然说的是大型网站，还是可以借鉴的

Answer 13

1）其实到了这个数据基本无论是用什么数据库都是一个极大瓶颈，所以，我觉得楼主要精心选择数据库以外，更加多的功夫应该放在程序架构和使用。如：自己程序上建立一些关键的索引等，数据是按这些索引在不同机器分布。2）MySQL 在这方面优势不是太大。因为MySQL 主要优点是自我维护性比较强（基本不需要怎么打理）。当数据超过了百万级别以后，运行速度不如db2 和 Oracle；
不过，若想挑战一下自己，MySQL 百万级别后可整空间比较大；基本要看你自己个人能力。 3）技术是死的，人是生的。用什么技术可能要你自己摸索，不过，我不太建议你用数据仓库。我感觉还是不太成熟，不时会出现这样或者那样的。

Answer 14

http://www.dbanotes.net/web/technorati_db_arch.html

Answer 15

http://www.dbanotes.net/web/technorati_db_arch.html

Answer 16

建议使用SYBASE IQ ,是数据仓库但是使用起来接近数据库，查询速度超快！

Answer 17

集群吧, 超过100G, 怎么样都是恐怖.
最大量200T;
比如1991 年的数据 放在 DB服务器A里, 10T 
       数据库D1
          根据数据特征分表放数据(表结构完全相同)
          表1(字段A,字段B,字段C)
          表2(字段A,字段B,字段C)
          表3(字段A,字段B,字段C)
       数据库D2(500G 根据MYSQL特征 超过500G的性能可能)
          根据数据特征分表放数据(表结构完全相同)
          表1(字段A,字段B,字段C)
          表2(字段A,字段B,字段C)
          表3(字段A,字段B,字段C)
       相关DB操作服务.
    1992 年的数据 放在 DB服务器B里, 10T
         
                      

Answer 18

虚拟化技术 + nosql db

Answer 19

关键看用户的查询。 如果是 select * from table1 什么where 都没有，则什么方法都不行。 如果查询是从每台机的记录集中各取一条，这个时间也不会快。

Answer 20

关键看用户的查询。 如果是 select * from table1 什么where 都没有，则什么方法都不行。 如果查询是从每台机的记录集中各取一条，这个时间也不会快。

Answer 21

使用no sql可能能解决问题。
也可以装几百台MySQL服务器，对应每台数据库服务器创建一个数据访问层，用户通过几百个线程来访问数据库，查询完后将结果合并就成了。
当然如果是双核的CPU，计算机可以省一半，四核的可以省3/4。
我觉得可以做到

Answer 22

如果这样，那么按时间来分表吧
数据层用 ibatis

Answer 23

比如说只让客户查询某一年度的数据
另外还要做 cluster 

Answer 24

建议用oracle 数据库 。

Answer 25

ibatis封装的jdbc，有什么用？比直接jdbc快？不要误导。

Answer 26

建议用oracle 数据库 。

Answer 27

 同意 就是，这么大的数据量，还用Mysql啊？？？？ 考虑一下换数据库吧！！！

Answer 28

但觉得编程难学不应该是其中的一个。我相信，编软件的能力，与读书写字一样，应该是人们的一项基本的能力。如果你对此抱有怀疑，也许可以参考一下古代社会，那时有能力读书写字的人就被称为有文化，并被高称为识文断字。如果那时候有人说，读书写字将是人们正常社会生活中的一项基本能力，会有多少人认同呢？我想编软件的能力也是同样的。与其说学习编程是一种能力的养成，莫如说是一种信心的养成。无论如何，读者都可以跟随故事中的人物一起做一尝试。编程语言学习以Delphi为例，因为其使用简单而人性化，适用于多种类型的软件开发。各种软件语言的内在相似性很高，都起源于近代数学的可计算性理论。对一门语言的研究到了一定程度之后，所

Answer 29

这么大的数据量，指望一劳永逸的解决方案是不可能的，即便换oracle也没用，一般考虑数据水平切分既然表结构简单，可以考虑自己写程序实现分布式的数据检索方案

Answer 30

还有人可以回答这个问题啊，这样的需求谁敢答应，用Oracle就能解决问题啊

Answer 31

器不是问题，话说大了吧？有钱买机器不能买个oracle数据库？ 
 

Answer 32

200T数据Select 无延时,不用DataWarehouse, 或不将记录分散出去真的很难。

Answer 33

oracle数据库太贵了,
一个ORACLE的许可证(6万美/1CPU/金3年 )  可以买多少台高配置的服务器了.
MYSQL很便宜 MySQL Enterprise Silver (1999美金/1SEVER/1年)200T 起码也要几十台机器吧,还有可能是多路CPU, 如果50台的话别算算价格差距还是很恐怖的

Answer 34

我觉得应该检索和数据的逻辑分开，
1 检索用solr的分布式，这样的话，没有问题。
2 关于数据的存放，我用过mysql的cluster,不过nosql的分布式应该会不会更好。如果需要详细讨论的话，可以：
msn:[email protected]
tel:[phone]

Answer 35

oracle是很贵的，关键以后升级啊什么的都要给，说实在的真的不是一笔小数目。不能在项目中表现出具体的长处，上头保证是不会答应的。而且mysql的好多方面也是不容小觑的，其实机器没想像的那么贵。用过的朋友应该都能体会。数据保证是机器产生的，但确实在我们公司很有用。数据不考虑压缩的话基本上是没有减少的方法的。刚刚看了google的BigTable技术，觉得有点靠谱了，就是文档太少了，就一遍14页的pdf。而且好多地方用了google的底层服务。有没有类似的能直接应用的 些类nosql技术。

Answer 36

noSQL+mysql
前面应该先noSQL然后再+mysql

Answer 37

机器不是问题？？来个大型机咯
分服务器，分数据库，分表，分区都可以优化，具体看客户需求(例如：客户是否有需求从200T的数据中提取资料？)这么大的数据量，建议还是用orcale吧。

Answer 38

你这么大的数据量没延时基本是不可能的，主要看客户的忍耐程度了！200T如果是纯数据的话那是太大了，不要考虑MYSQL，ORACLE首选。服务器上讲你这个不做数据分布根本不可能搞定，大型机没玩过，不懂，服务器级别的绝对不行，业务上对你的数据进行切分吧，按照时间或者一些关键业务单元切，你说数据表简单，那就按水平切，估算你的数据有多少，把最常用的数据提取出来，最常用的要素提取出来。技术上讲，可用TIMESTEN，物化视图，索引什么的我就不说了，该联合的联合，位图的位图，空间换时间！负载均衡自然是你考虑，关键是数据划分和内存数据库的利用，你说的CPU占用率之类的可以采用负载均衡器。NOSQL比较新颖，出了国外几个大公司成功案例外资料太少，会的人也不多，你要能承担风险你们就研究。不要用数据仓库，那东西不是为了快速检索用的。

Answer 39

当你的一张数据表数据达到一亿时不管什么服务器  数据库都会有瓶颈，毕竟还要考虑磁盘读写，虽然有DATABUFFER技术和高速磁盘读取技术，但是解决不了你的基本无延时，同上，大型机偶不懂，至少IBM部分服务器我没见过能搞定这个的，偶最多做的就几个T的数据，跟你这个比只能提供些经验，可能很多不对的地方HUHU

Answer 40

mysql不适合这种超大量的数据。 

Answer 41

考虑下用分布式存储吧。
建议看下HBase

Answer 42

若机器不是问题，做分布式数据库，建议将Oracle的每个空表间放到不同的电脑上，大表进行表分区，300G的数据我在使用的过程，速度还好。

Answer 43

听说google就是用的mysql，不过是人家自己改造的
你是在做搜索引擎吗，肯定是要用集群了。使用全文搜索加缓存

Answer 44

1、如果是简单的表结构，比如是Key-Value的形式，建议使用Key-Value的Hash数据库
2、将Key拿出来单独做查询结果集，再到Key-Value DB库中去检索具体数据我不方便提供任何所采用的技术名称，你去网上百度一下相关技术吧