[譯] RethinkDB compared to MongoDB

原文：RethinkDB compared to MongoDB

許多人會問 RethinkDB 與 MongoDB 以及其餘 NoSQL 數據庫有什麼不一樣。咱們首先嚐試經過在高層面的技術概覽比較 RethinkDB 和 MongoDB 來回答這個問題。可是，概覽意味着中立，就必然會忽略一些使 RethinkDB 不同凡響的有趣的事情（就好比咱們對 Dota 的癡迷）。在本文中，我想站在更加私人的角度來描述這個產品。

一箭雙鵰

第一代 NoSQL 產品大體能夠分紅兩類——面向開發者的和麪向運維的。

面向開發者的產品包括 MongoDB 和 CouchDB。他們一般關注易用性，擁有富文檔結構，以及靈活的查詢功能。然而，當與他們的同行（面向運維的NoSQL）相比時，將他們部署到分片環境和規模大的負載要更加困難。

面向運維的產品包括 Cassandra 和 Riak 。這些產品是爲了高可用部署和大規模而設計的。不像面向開發者的產品，以目前的形式面向運維的產品一般較少有強大的查詢功能，也不會太關注易用性。

得益於前車可鑑以及三年的技術工做，RethinkDB 旨在融合二者的理念，提供一個一箭雙鵰的產品。它被設計成很是易用，擁有豐富的數據模型，而且支持及其靈活的查詢功能。經過幾下點擊就能將 RethinkDB 的節點進行分片。

提升標準

咱們還致力於怎樣延伸 NoSQL 系統的可能性。RethinkDB 添加了現代查詢語言，大規模並行分佈式架構，支持分佈式 join 和 subqueries，還提供了一個既簡單又漂亮的管理工具，下邊是咱們的早期用戶以爲 RethinkDB 亦可賽艇的一些理由。

現代查詢語言

在全部我見過的新型數據庫中， RethinkDB 擁有最好的查詢語言 @rauchg

ReQL 是一個數據驅動的，抽象的，多態查詢語言。它很容易學習而且極其靈活。
爲主流編程語言（目前有 Python，Ruby，Java 和 JavaScript）提供了定製的、高度集成的 DSL。
不一樣於大多數的 NoSQL 系統，RethinkDB 支持服務端 subqueries 和分佈式 join 操做，這消除了複雜的客戶端代碼和多個數據庫服務器的往返。
ReQL 並不基於字符串解析，因此被注入攻擊的風險大大下降。
這並非說 ReQL 已經完美了，咱們還在不斷給它添加更多的功能和操做。

管理後臺：簡單與美貌並存

WOW，RethinkDB 的管理界面簡直難以想象。很容易就能安裝到 OSX 上。你們快來看看。@mjackson

幾下點擊就能完成分片和複製。
全部的集羣操做均可以用 ReQL 腳本化。
內置數據資源管理器提供了在線文檔和查詢建議。
不少產品都很易用，但咱們認爲 RethinkDB 是其中最漂亮的。

大規模並行分佈式架構

WOW 跨分片 join，分佈是數據不是夢 。@kapso
全部的查詢，包括 join、aggregation、subqueries，都會自動編譯成分佈式程序而且跨級羣執行，用戶不費吹灰之力。
數據密集型操做自動編譯成 map-reduce 做業來充分利用分佈式結構。
集羣協議是對等的，不須要細條節點。這使得集羣很是容易設置和操做。

固然，咱們一直都在提升性能，一直致力於消除更多的性能和可擴展性瓶頸。

魯棒實現

RethinkDB 看起來像是作對了的 MongoDB：MVCC，非阻塞寫入，默認的穩定性，v8，增量 vacuum，容易分片。@herodiade

一個無鎖的架構和多版本併發控制系統容許不一樣的工做負載在一個集羣中共存。
一個自定義的，B-Tree aware buffer cache 中有效地操做數據集要遠遠大於可用 RAM 的數量。
一個異步的、事件驅動架構，基於高度優化的協同程序代碼尺度跨越多個核和處理器、網卡、和存儲系統。
一個併發的自定義日誌結構化存儲引擎，增量磁盤上垃圾壓實機利用不一樣類型的存儲硬件。

侷限性

RethinkDB 在不少項目上均可以工做的很好，但並非銀彈。選型時請閱讀 何時 RethinkDB 不是一個好的選擇