2010-11-05 139 views
3

嘿。我将要建立一个真正非常巨大的数据库。分布式数据库解决方案?

我一直在使用标准的MySQL的大部分我的东西,但这个特殊的问题将得到高达TB的,我会希望能够做到几百个查询的第二个。

所以从设计我的数据库架构使得它不会突突和快速的硬盘速度,什么是我最大的瓶颈,什么样的解决方案预留建议在此。

是否有意义散布到多台计算机的数据库上我的内联网,因此可以与CPU/RAM等比例如果是这样的软件有这个或数据库解决方案呢?

感谢您的帮助! 我搜索了与此相关的问题,但如果已经询问过,则找不到任何内容。

回答

1

数据库可伸缩性是一个非常复杂的问题;整个过程中都会遇到很多问题。

首先,考虑最低的水果;你有单独的表(或列)将包含大量的数据吗?包含每个大于4MB的BLOB的列?这些可以从数据库中提取并存储在平面文件存储系统中,并且仅从数据库引用;就在那里,这可能会将许多难以实施的解决方案降到可管理的水平。

如果没有,你有没有表的不同子组深感不同的使用模式?如果是这样,那么就有机会将您的数据库分割成不同的功能数据库,这些数据库可以分割到不同的服务器上。这方面的一个很好的例子就是大多数读取数据,比如web服务器,很少生成(认为用户特定的主页数据),但频繁读取;该类型的数据可以分离到与用户数据的其余部分分离的数据库中(或者,再次,带有引用的flatfile)。

考虑你的数据库的事务性要求;你能清楚地隔离你的交易界限,还是会有数据库中存在深度混合的交易?如果你能够隔离你的交易界限,那么还有另一个潜在的有用边界。

这只是触及了一些参与这样的事情的问题。值得考虑的一件事是,你是否真的需要一个实际上会很庞大的数据库,或者你只是想将数据库用作持久层。如果您仅将数据库用作持久层,那么您可能会重新考虑是否实际上需要数据库的关系特性,或者是否可以在较简单的持久层之上使用较小的关系覆盖层。 (我这样说是因为解决方案的大量看起来他们可以逃脱过大的持久层薄薄的关系层,这是值得考虑的。)

+0

给你一些关于手头实际问题的更多信息,我们将从大量数据源中提取大量数据,并从每个条目中解析大量统计数据。每天数据库将处理100,000个新条目,每条条目都有100个统计数据。每个条目的实际文件大小为prob <1KB,并且一旦其解析不需要使用。我们将在每个不断增长的数据集上实时运行大量不同的查询,并最终为其他人提供相同的平台。 – 2010-11-05 18:38:36

+1

@nextgenneo:是的,你在那里有点问题。我仍然建议您尽可能地合理分区数据库;是否有某种你不会穿越的时空视界,或者类似的?因为如果你真的有一个庞大的,不可分区的关系数据集,你可能需要结束一个(非常昂贵的)商业解决方案。我不是甲骨文的粉丝(至少可以这么说),但他们比任何人都更了解史诗级的扩展。 – 2010-11-05 19:22:57

1

好吧,首先,我需要你点here.我不不认为MySQL会像你想要的那样执行。我有一种不好的感觉,当我说你需要看看甲骨文的安装时,你会说,“我们没有现金。”但是,当我说得到最新/最好的SQL Server时,你会说,“我们没有实现它的硬件。”恐怕TB级数据才会粉碎你的MySQL安装。

+1

鉴于他在上面对我的回答的评论中作了澄清,我觉得你可能是对的;你对甲骨文的观点是完全正确的。甲骨文非常适合作为一个收银机,一旦你和他们在一起,就没有回头路;那就是说,他们真的是城里唯一的游戏,当他们专注于可扩展性的类型时...... – 2010-11-05 19:25:21

0

正在构建新一代的NewSQL数据库,以准确解决在多个服务器上分配资源的问题。数据库(从头开始构建为MySQL替代品)是一个提供近线性规模的示例 - 当CPU /内存耗尽时,您可以简单地添加节点。

0

数据库可伸缩性是一个棘手的问题,您应该考虑可以为您解决的解决方案。我相信MySQL可以作为解决问题的基础。

水平可伸缩性;能够水平扩展数据库的能力(又称向外扩展)是解决非常大的表和数据库问题的好技术。