我正在阅读ArangoDB,它更有趣但我无法在文档中找到ArangoDB如何扩展的位置.ArangoDB是否可以扩展,是否可以像MongoDB或CouchDB一样使用分片？
小智 14
编辑
自2.0版以来,ArangoDB支持分片.
版本3.0将带来VelocyPack,这是一种二进制JSON表示,针对紧凑性,可解析性和可组合性进行了优化.它取代了形状概念/形状JSON.
/编辑
我是ArangoDB的首席架构师.
monkegjinni是对的,ArangoDB不支持分片,而是复制.为什么？
为图形和文档等相当复杂的数据模型提供支持会与分片的工作方式发生冲突.但是,随着现代SSD和计算机的效率,我们相信几乎所有项目都不再需要分片.今天的计算机可以轻松地将所有数据存储在单个节点上.这些项目需要的是ArangoDB支持的负载分配复制.
实际上有单独的缩放问题.
第一个问题是在多个服务器上分发请求以平衡请求负载.
ArangoDB将通过写入的同步复制和读取请求的分发来支持这一点.
请注意,大多数数据库系统遵循非常类似的路径,即它们支持使用受限制的一致性保证来分发请求,或者它们仅允许在一个节点上进行写入并分发读取请求.他们有这个限制,因为分发写请求和支持完全一致性是不可能有效地完成的.而低效率地做会否定我们希望通过分配实现的收益.
第二个问题是通过多个服务器分发数据以允许更大的数据集.
ArangoDB不支持通过多个服务器分发数据.
我们做出了这个决定,因为在几台服务器上分发数据总是要付出代价.
这个价格可以非常明确.例如,数据模型可能非常有限.这是Dynamo或RIAK等关键值存储的路径.这里数据模型和支持的查询非常简单,始终可以将查询定向到请求值所在的服务器(或少量服务器).
请注意,我们确实认为这种方法对某些应用程序(例如Amazons数据库)有效.但我们认为真正需要存储大量数据的应用程序数量必须将访问模式限制在大量服务器上,因此必须将访问模式限制为键值非常小.
或者价格可以隐藏.例如,如果数据是分布式的并且数据库系统允许一般查询,则是这种情况.在这种情况下,查询必须分布在所有服务器上(因为您要查找的数据可能存在于任何服务器上).这使得查询效率低下.
ArangoDB方法更适合挤压到一台服务器上(ArangoDB支持多台服务器 - 但支持可用性).为此,它使用两种主要策略.
一种策略是使用SSD.请注意,固态硬盘的容量正在以惊人的速度增长(您可以购买太字节固态硬盘的价格远远低于第二台服务器的成本).耐久性(可以写入SSD的数据总量)上升到PB级(现在供应商最终得到了磨损均衡算法) - 因此SSD的可靠性不再是问题.而且这些SSD的性能非常好(离主内存比普通磁盘更近).
另一种策略是有效地存储数据.ArangoDB使用形状来存储文档:形状是文档具有属性和属性类型的信息 - 具有相同形状的所有文档共享此信息的表示.这意味着文档可以存储在比JSON或BSON表示所需的空间更少的空间中.
| 归档时间： |
|
| 查看次数： |
789 次 |
| 最近记录： |