是否有一个键值存储将给我以下内容:
允许我简单地添加和删除节点,并自动重新分配数据
允许我删除节点,仍然有2个额外的数据节点来提供冗余
允许我存储最大1GB的文本或图像
可以存储高达100TB数据的小尺寸数据
快速(因此将允许在其上执行查询)
使所有这些对客户端透明
适用于Ubuntu/FreeBSD或Mac
免费或开源
我基本上想要一些我可以使用"单一"的东西,而不必担心有memcached,db和几个存储组件所以是的,我确实想要一个数据库"银弹"你可以说.
谢谢
祖拜尔
到目前为止的答案:在BackBlaze之上的MogileFS - 据我所知,这只是一个文件系统,经过一些研究,它似乎只适用于大型图像文件
东京暴君 - 需要lightcloud.添加新节点时,这不会自动缩放.我确实研究了这个问题,但对于适合单个节点的查询来说,它似乎非常快
Riak - 我正在调查这个,但我还没有任何结果
亚马逊S3 - 有人使用它作为生产中唯一的持久层吗？从我所看到的它似乎用于存储图像,因为复杂的查询太昂贵
@shaman建议Cassandra - 绝对是我正在研究的
到目前为止,似乎没有数据库或键值存储符合我提到的标准,即使在提供100分的赏金之后,问题也得到了解答!
你对开源软件的要求太高了.
如果您的预算有几十万美元用于某些企业级软件,那么有几种解决方案.没有什么可以做你想要的开箱即用,但有些公司的产品接近你想要的产品.
"快速(因此将允许在其上执行查询)"
如果你有一个键值存储,一切都应该非常快.但问题是,如果没有在键值存储之上构建的本体或数据模式,您将最终遍历每个查询的整个数据库.您需要一个索引,其中包含要存储的每个"类型"数据的键.
在这种情况下,您通常可以针对所有~15,000台计算机并行执行查询.瓶颈在于便宜的硬盘驱动器每秒可以达到50次.如果您的数据集适合RAM,那么您的性能将非常高.但是,如果密钥存储在RAM中但没有足够的RAM来存储值,则系统将在几乎所有键值查找上转到光盘.每个键位于驱动器上的随机位置.
这限制了每台服务器每秒50次键值查找.而当键值对存储在RAM中时,在商用硬件上每个服务器每秒获得100k操作并不罕见(例如Redis).
然而,串行盘读取性能非常高.我已经在串行读取时寻找50 MB/s(800 Mb/s)的驱动器.因此,如果要在光盘上存储值,则必须对存储进行结构化,以便可以连续读取需要从光盘读取的值.
那就是问题所在.除非您将键值对完全存储在RAM中(或者RAM中的键与SSD驱动器上的值一起存储),或者如果您定义某种类型的架构或键入系统,否则您无法在vanilla键值存储上获得良好的性能.键然后将数据聚集在光盘上,以便通过串行光盘读取轻松检索给定类型的所有键.
如果密钥有多种类型(例如,如果数据库中有数据类型继承关系),则密钥将是多个索引表的元素.在这种情况下,您将不得不进行时空权衡以构造值,以便可以从光盘中串行读取它们.这需要存储密钥值的冗余副本.
你想要的是比键值存储更先进,特别是如果你打算进行查询.然而,存储大文件的问题是没有问题的.假装您的系统可以输入高达50兆的密钥.然后,您只需将1 gig文件拆分为50 meg段,并将键与每个段值相关联.使用简单的服务器,可以直接将所需文件的一部分转换为键值查找操作.
实现冗余的问题更加困难.它很容易将"喷泉代码"或"部分文件"作为服务器的键值表,以便服务器的数据可以以线速(1 Gb/s)重建到备用服务器上(如果特定服务器死机).通常,您可以使用"心跳"系统检测服务器死亡,如果服务器10秒钟没有响应,则会触发该系统.甚至可以对部分文件编码的键值表进行键值查找,但这样做效率很低,但仍然可以为服务器故障事件提供备份.更大的问题几乎不可能使备份保持最新,数据可能是3分钟.如果您正在进行大量写入,则备份功能将引入一些性能开销,
我不是在故障模式下维护数据库一致性和完整性约束的专家,所以我不确定这个要求会引入什么问题.如果您不必担心这一点,它极大地简化了系统的设计及其要求.
快速(因此将允许在其上执行查询)
首先,当数据库很大时,忘记连接或任何比n*log(n)更快扩展的操作.您可以通过两件事来替换通常使用连接实现的功能.您既可以构建数据,也可以不需要进行连接,也可以"预编译"正在执行的查询,并进行时间间隔权衡并预先计算连接并将其存储以便提前查找.
对于语义Web数据库,我认为我们将看到人们预先编译查询并进行时空权衡,以便在即使是适度大小的数据集上实现良好的性能.我认为这可以由数据库后端自动且透明地完成,而不需要应用程序员的任何努力.但是,我们才开始看到为关系数据库实现这些技术的企业数据库.据我所知,没有开源产品可以做到这一点,如果有人试图在横向可扩展数据库中为链接数据执行此操作,我会感到惊讶.
对于这些类型的系统,如果您有额外的RAM或存储空间,最好使用它是出于性能原因预先计算和存储公共子查询的结果,而不是向键值存储添加更多冗余.通过要查询的键预先计算结果和顺序,以将n ^ 2联接转换为log(n)查找.任何比n*log(n)更差的查询或子查询都需要在键值存储中执行和缓存结果.
如果您正在执行大量写入操作,则缓存的子查询将比处理它们更快地失效,并且没有性能优势.处理缓存子查询的缓存失效是另一个难以解决的问题.我认为解决方案是可行的,但我还没有看到它.
欢迎来到地狱.您不应该期望在未来的20年内免费获得这样的系统.
到目前为止,似乎没有数据库或键值存储符合我提到的标准,即使在提供100分的赏金之后,问题也得到了解答!
你在寻求奇迹.等待20年,直到我们拥有开源奇迹数据库,或者您应该愿意为根据您的应用程序需求定制的解决方案付钱.
Amazon S3是一种存储解决方案,而不是数据库.
如果您只需要简单的键/值,那么最好的选择是将Amazon SimpleDB与S3结合使用.大文件存储在S3上,而用于搜索的元数据存储在SimpleDB中.这为您提供了可直接访问S3的水平可扩展键/值系统.
京公网安备 11010802040832号 | 京ICP备19059560号-6 