我正在为用 Ruby on Rails 或 Merb 编写的应用程序寻找后端解决方案,以处理具有数十亿条记录的数据。我有一种感觉,我应该使用分布式模型,而此刻我看着
在我看来,HBase 解决方案存在问题——对 ruby 的支持不是很强,而且 Couchdb 还没有达到 1.0 版本。
对于如此大量的数据,您有什么建议吗?
数据有时需要一次相当快的导入 30-40Mb,但导入将分批进行。因此,大约 95% 的时间数据将是只读的。
人们使用了许多不同的解决方案。根据我的经验,它实际上更多地取决于您与该数据相关的使用模式,而不是每个表的绝对行数。
例如,“每秒发生了多少次插入/更新”。诸如此类的问题将影响您决定选择哪种后端数据库解决方案。
以 Google 为例:实际上并不存在满足他们需求的存储/搜索解决方案,因此他们基于 Map/Reduce 模型创建了自己的解决方案。
根据您的实际数据使用情况,MySQL 或 Postgres 应该能够在正确的硬件上处理数十亿条记录。如果您有特别大量的请求,这两个数据库都可以跨多个服务器复制(并且读取复制非常容易设置(与多个主/写复制相比)。
将 RDBMS 与 Rails 或 Merb 一起使用的最大优势是您可以访问所有出色的工具支持来访问这些类型的数据库。
我的建议是在其中几个系统中实际分析您的数据并从那里获取。
关于 HBase 和其他类似项目的警告(对 CouchDB 一无所知——我认为它根本不是一个数据库,只是一个键值存储):
Hive 项目也建立在 Hadoop 之上,确实支持连接;Pig也是如此(但它不是真正的sql)。第 1 点适用于两者。它们适用于繁重的数据处理任务,而不是您可能使用 Rails 进行的处理类型。
如果您想要 Web 应用程序的可扩展性,基本上唯一可行的策略是对数据进行分区并尽可能确保分区是隔离的(不需要相互通信)。这对 Rails 来说有点棘手,因为它默认假设有一个中央数据库。自从我大约一年半前研究这个问题以来,这方面可能已经有所改进。如果您可以对数据进行分区,则可以水平扩展相当宽的范围。一台 MySQL 机器可以处理几百万行(PostgreSQL 可能可以扩展到更多的行,但可能会慢一些)。
另一种可行的策略是设置主从设置,其中所有写入都由主控完成,读取在从属(可能还有主控)之间共享。显然,这必须相当小心地完成!假设读/写比率很高,这可以很好地扩展。
如果您的组织财力雄厚,请查看 Vertica、AsterData 和 Greenplum 提供的服务。
后端将取决于数据以及如何访问数据。
但是对于 ORM,我很可能会使用 DataMapper 并编写一个自定义 DataObjects 适配器来访问您选择的任何后端。
我不确定 CouchDB 不在 1.0 与它有什么关系。我建议用它做一些测试(只生成十亿个随机文档),看看它是否能坚持下去。我会说它会,尽管没有特定的版本号。
在分区/分片数据方面,CouchDB 将为您提供很多帮助,似乎它可能适合您的项目 - 特别是如果您的数据格式将来可能会更改(添加或删除字段),因为 CouchDB 数据库没有架构.
CouchDB 中也有很多针对读取量大的应用程序的优化,根据我的使用经验,这就是它真正闪耀的地方。