mysql 数据量太大的设计方案 ~200T,该怎么处理

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




这么大的数据量,优化也不能光靠数据库本身,网络、缓存,最重要的还是在应用架构设计上下功夫

mysql 数据量太大的设计方案 ~200T,该怎么处理

相关文章:

你感兴趣的文章:

标签云: