mysql 数据量太大的设计方案 ~200T
现在公司要做一个数据库方案，总体目标是要存约 200T 的数据，机器不是问题。

已知：表结构很简单，关链是数据量实在是太大。对查询有较高的要求(基本上要让客户体会不到时延)，而且数据会时不时地添加（添加的量也很大，大概一年会升个数量级）

有没有人能给点意见，能大致给个方向，不胜感激。

------解决方案--------------------
难！ 很难！ 200T 的数据，建议你能预估一下，会有多少记录。 表结构大概如何？ 

特别是 "对查询有较高的要求(基本上要让客户体会不到时延)" ，这个很难实现，只能想办法预知用户的查询主要有哪些，然后做针对性的优化。

常见的优化有， 分区，物化查询,等手段。但都必须先预测用户的查询是什么。
------解决方案--------------------

探讨

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

------解决方案--------------------
试试Cassandra
------解决方案--------------------
看看http://www.toplee.com/blog/71.html，
http://www.dbanotes.net/web/technorati_db_arch.html，虽然说的是大型网站，还是可以借鉴的
------解决方案--------------------
1）其实到了这个数据基本无论是用什么数据库都是一个极大瓶颈，所以，我觉得楼主要精心选择数据库以外，更加多的功夫应该放在程序架构和使用。如：自己程序上建立一些关键的索引等，数据是按这些索引在不同机器分布。

2）MySQL 在这方面优势不是太大。因为MySQL 主要优点是自我维护性比较强（基本不需要怎么打理）。当数据超过了百万级别以后，运行速度不如db2 和 Oracle；
不过，若想挑战一下自己，MySQL 百万级别后可整空间比较大；基本要看你自己个人能力。 

3）技术是死的，人是生的。用什么技术可能要你自己摸索，不过，我不太建议你用数据仓库。我感觉还是不太成熟，不时会出现这样或者那样的。
------解决方案--------------------
http://www.dbanotes.net/web/technorati_db_arch.html
------解决方案--------------------
集群吧, 超过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



------解决方案--------------------
noSQL+mysql
前面应该先noSQL然后再+mysql
------解决方案--------------------
这么大的数据量，优化也不能光靠数据库本身，网络、缓存，最重要的还是在应用架构设计上下功夫