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