RethinkDB介绍

无意中看到redis作者在博客中推荐了RethinkDB,早上来简单了解了下,记录下:

RethinkDB是一个完全支持Memcached协议、数据可持久化的工业级key-value存储系统。

RethinkDB官网介绍如下:

RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn

Simple programming model:

  • JSON data model and immediate consistency.
  • Distributed joins, subqueries, aggregation, atomic updates.
  • Hadoop-style map/reduce.

Easy administration:

  • Friendly web and command-line administration tools.
  • Takes care of machine failures and network interrupts.
  • Multi-datacenter replication and failover.

Horizontal scalability:

  • Sharding and replication to multiple nodes.
  • Queries are automatically parallelized and distributed.
  • Lock-free operation via MVCC concurrency.
以上为官网的简单介绍, 官网也有详细的测试。

在网上查了下一些资料,摘要如下:

RethinkDB的特点:
- 随CPU个数线程扩展
- SSD上速度快十倍
- 节省内存空间
- 断电后及时恢复  
- 细化的持久性控制
- 支持上万的并发连接数
- 支持裸盘设备,多磁盘上自动数据分区 

RethinkDB的设计思想
1.B树会产生大量的随机写操作,对闪存寿命的负面影响很大。
2.闪存具有良好的随机读性能,所以B树和cluster index变得不再重要。
3.基于以上判断,RethinkDB采用append-only的方式来管理数据和索引,消除闪存上的随机写操作

Append-Only的影响
优点:

1.数据一致性(Data Consistency)。
- 所有更新追加到文件尾部,其他部分没有任何修改
- 文件的其余部分提供了一个完全一致的数据库
2.热备份(Hot Backups)。
- 在数据库文件被修改的同时可以拷贝一致数据
- 可简单地实现增量备份
3.及时恢复(Instantaneous Recovery)
- 数据库本身就类似于一个事务日志
- 恢复时直接截断数据库文件到一个已知一致的事务
缺点:
1) 在一个insert或者update很频繁的workload下,大量数据很快就会过期;
2) append-only消除了数据组织的数据局部性,虽然在SSD上随机读代价很小,但是仍旧是一个问题;
3) 对于索引结构来说,每50MB的数据会生成2GB的数据存储,需要有效地进行垃圾回收。


上面内容来自一PPT,RethinkDB & TokuDB调研测试报告 有兴趣可以下载。

从PPT中查看到,其相关性能在并发足够大时,相关性能相比Memcache还是更占优势。

但memcache只是缓存,它可以支持持久化存储,且完全支持Memcache协议!

更多是针对SSD做的优化。


目前官网有免费版与商业版!以上内容只供参考!



  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
RethinkDB 设计用来存储 JSON 文档的分布式数据库,可通过简单操作实现多机分布式存储。支持表的联合和分组查询。什么是RethinkDB?RethinkDB 是从头打造的第一个开源、可扩展的JSON数据库,用于搭建实时网页。全新的访问模型颠覆了传统的数据库结构:开发者只需告诉RethinkDB,实时连 续地将查询更新结果推送到应用就可以了,不用每次都去poll一遍。RethinkDB的实时推送结构为搭建可扩展实时应用节省了大量时间精力。除了为实时应用提供了全新的设计之外,RethinkDB 还提供了一种灵活的查询语言、直观的操作和监控API,安装学习起来也非常容易。你可以查看这篇 Advancing the realtime web 得到更多RethinkDB计划的技术细节。什么时候RethinkDB是一个好的选择?当你的应用很大程度上有赖于数据的实时反馈时,RethinkDB 就会成为一个很棒的选择。“查询-响应”式的数据库访问模型在web上的确很有用,它可以直接映射到HTTP的“请求-响应”。而现代应用则需要将数据直接实时地传送到客户端。能够最大化得益于RethinkDB实时推送架构的例子包括:协作网站和移动应用数据流分析应用多人在线游戏实时交易场所设备联机举个例子:在协作设计一个app的时候,其中一个用户改变了某个按钮的位置,服务器就必须在第一时间通知所有在完成同一项目的其他用户。网页浏览器 能够通过WebSockets和http持久连接来支持这一功能,但数据库系统要迎合实时需求仍然是一个大的工程难题。而RethinkDB作为第一个开 源、可扩展的数据库,就是特别为实时推送数据到应用而设计的。哪些人在用 RethinkDB?RethinkDB 的用户包括上百个科技创业公司、咨询工作室和世界五百强企业。这里是其中的一些:Jive Software 和 Mediafly 使用RethinkDB搭建强大的响应式网页和移动应用Pristine.io 和 Narrative Clip 使用RethinkDB搭建用于设备连接的云架构Platzi 和 Workshape.io 使用RethinkDB进行实时分析CMUNE 和 NodeCraft 使用RethinkDB构建大规模可扩展多人游戏RethinkDB 拥有超过十万开发者的活跃社区和上百个来自世界各地的代码贡献者。RethinkDB是基于现有技术的吗?高效实现实时推送架构需要重新设计绝大部分的数据库成分,包括查询执行引擎、分布式系统、超高速缓存子系统和存储引擎。因为架构影响到每一个数据库 组成部分,RethinkDB不得不从C 开始一步步写起来。RethinkDB 是由数据库专家组成的团队花了五年时间做出来的,还得到了来自世界各地上百个代码贡献者的帮助。RethinkDB和realtime sync不同在哪里?和Firebase, PubNub 或者Pusher 这类实时同步API相比,RethinkDB主要不同在以下三个方面:首先,实时同步API是云服务,而RethinkDB 是开源项目。RethinkDB也有云端,可以通过我们的合作伙伴 Compose.io 和 Amazon AWS获得。它还可以部署在你自己的架构中,没有任何限制。其次,同步实时API只局限于同步文档,而RethinkDB是一个有着更普遍应用范围的数据库系统。 在RethinkDB中你可以运行任意query,包括table joins, subqueries, geospatial queries, aggregation, 还有map-reduce。实时同步服务有更多查询功能上的限制。最后,实时同步API的设计是直接从浏览器访问。这使得基本的app能够快速地跑起来,然而一旦app扩展了,灵活性就会受到限制。 RethinkDB的设计是从应用服务器进行访问,这一点上更像是传统的数据库。可能会要多花一点设置代码,但拥有足够的灵活性去适应应用的成熟。RethinkDB和MongoDB又不同在哪里?RethinkDB所基于的架构和MongoDB非常不同。开发者只需告诉RethinkDB,实时连续地将查询更新结果推送到应用就可以了,不用 每次都去poll一遍。你同样可以在RethinkDB上用传统的“查询-响应”范式来书写应用。然后在你开始为app添加实时功能时再去订阅实时数据 流。举个例子,这是你让RethinkDB查询一个文件时的命令:r.table('users').get('coffeemug').run()然后这是你从RethinkDB订阅更新流时用到的语句,在任何时候文档发生了变化就会推送:r.table('users').get('coffeemug').changes().run()RethinkDB的实时架构可以和MongoDB的oplog相提并论,但前者提供了更高层次的抽象。RethinkDB的数据流与查询计算引擎无缝整合,并允许你订阅查询结果的变化,而不仅仅是把数据复制过来。这种架构大幅度地减少了搭建实时app所需的时间和精力。除了实时推送架构,RethinkDB 还有许多胜过 MongoDB的地方:一种高级的查询语言,能够支持table joins, subqueries 和大规模并行式分布计算。融合了查询语言的操作和监控API,大幅度降低了RethinkDB扩展的难度。简洁美观的UI 易于复制转发,拥有在线文档支持和查询语言建议。可以看看这篇 technical comparison of RethinkDB and MongoDB 里面的评论比较中立一些。想听听个人观点的,请看@coffeemug 的what makes RethinkDB different.什么时候RethinkDB是一个不好的选择?当你需要用到完整ACID支持或者更强大的架构实施,RethinkDB就不大好用了。在这种情况下你最好用一些传统的MySQL或者PostgreSQL数据库。如果你需要做深度、密集型计算分析的话,你最好用Hadoop或者类似于Verticaa的面向列的存储工具。在某些情况下RethinkDB会在一定程度上牺牲书写可用性(write availability)来保证数据一致性(data consistency)。如果高要求的书写可用性对你来讲很重要,那你也不要纠结了,像Riak这样的Dynamo式系统可能更适合你。想要更多地学习RethinkDB?阅读 ten-minute guide 开始学习RethinkDB。对于熟悉分布式系统的程序员可以直接阅读 architecture overview 。走捷径用 cookbook,你可以看到许多常用的 RethinkDB查询例子。 标签:分布式数据库
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值