一篇antirez的舊文，redis和mongoDB

最近刷了不少愛豆antirez（redis做者）的博客。今天讀了很老的一篇，以爲寫得有點意思。讀書的時候很喜歡英語，差點去學了語言專業。想來歷來沒嘗試過翻譯，心血來潮暫且拿這篇試試。

MongoDB和Redis：關係型數據庫問題的兩種解釋

MongoDB and Redis: a different interpretation of what's wrong with Relational DB

作redis相關的工做讓我感受很不錯：這無關於金錢，沒有排期，也不用管不一樣意我想法的甲方；這項工做更多的是盡我綿薄之力，以求幫助推進這個領域發展。作本身喜歡的事真是使人開心，尤爲當你感覺到其實本身並不想要去贏，只要本身的一些想法能多多少少有些助益就好。這就像科學同樣，最重要的是求知，找到問題更好的解決方案。

Working to Redis is a good feeling for me: it's not something about money, or deadlines, or customers not agreeing with me, but about trying to do my 2 cents in order to help the field to go forward. It's a joy to work to things you love, especially if you have the feeling that you don't want to win: even if a few ideas of your work will be useful for another experiment or implementation it is already worth it. It's like science, what matters is to know more, to find better solutions to problems, and so on.

抱着這種心態我研究了其餘基於鍵值對設計的數據庫，我建議有興趣的朋友能夠研究一下MongoDB。我對mongoDB很感興趣，十分有趣的一點是redis和mongoDB理論上都嘗試解決同一個問題，但對問題的分析卻截然不同。

So I check other work on other key value databases, and suggest this databases to people interested in something different than Redis. For instance this MongoDB slides are good and worth a look. MongoDB seems an interesting project to me, and the interesting thing is how Redis and MongoDB try to solve the same problem in theory but with a very different analysis of it.

「若是全部工做都依靠關係型數據庫來承擔，那恐怕會有問題」，redis和mongoDB都是圍繞這個觀點而創建項目。MongoDB在本身的展現文稿裏說：「關係型數據庫就像一個錘子，可是不是全部的問題都是釘子」 。這個話題咱們能夠討論到天荒地老，可是最關鍵的是，面對「不是釘子」的問題，兩個工具採起了什麼樣的不一樣措施。

Both the projects are about there is something wrong if we use an RDBMS for all the kind of works. Not all the problems look like a nail but too much databases look like an hammer, the slide says, and indeed it's a colorful imagine to communicate. But it is remarkable how, in response to the same non-nail problems, this two tools taken different paths.

MongoDB

在分析以前，我想先說說MongoDB是如何工做的。它的核心觀點是創造對象objects，這些objects其實是命名字段field和值value的集合。一個MongoDB對象看起來是這個樣子：

Before to continue I want to spend some word about how MongoDB works. The idea is to have objects, that are actually a sum of named fields with values. A Mongo DB object looks like this:

Name: Salvatore
Surname: Sanfilippo
Foo: yes
Bar: no
age: 32
複製代碼

實際上這和關係型數據庫的表很是像。而後咱們就能夠針對這些objects執行各類有趣的query：

db.collection.find.({'Name':'John'}) # Finds all Johns
db.collection.find.({$where:'this.age >= 6 && this.age <= 20'})
複製代碼

同關係型數據庫同樣，mongoDB的字段上能夠創建索引，進行排序、取件查詢、使用limit語句等等。基本上，mongodb的數據模型和關係型數據庫是同樣的。在我看來，mongoDB的開發者的思路是這樣的：

關係型數據庫對不少問題來講簡直是殺雞用牛刀，那些問題根本不須要這麼複雜的設計。關係型數據庫變成了龐然大物，所以又慢又難搬。可是它的數據模型仍是好的，表、索引以及支持各類複雜的查詢語句都沒有問題。

You can have indexes in given fields, like in RDBMS, and can sort your queries against some field, order it, get a range using LIMIT, and so on. Basically the data model is the same as an RDBMS, so the MongoDB developers main idea is the following, in my opinion: What's wrong with RDBMS when used for (many) tasks that don't need all this complexity? They are bloated, thus slow and a pain to replicate, shard, ... But the data model is right, to have tables and index and run complex queries against data.

Redis 的方式

Redis一樣但願解決那些不是「釘子」的問題。可是咱們的思路不同：redis提供的數據結構和大家在計算機教科書上學到的數據結構很接近，好比說鏈表、集合，而redis服務端只是對這些數據結構作簡單的操做。使用Redis就像使用本身內存裏的數據結構同樣簡單，並且Redis的數據結構仍是持久化的。固然使用Redis沒有使用服務器自己的內存塊，畢竟中間隔了網絡。

Redis tries to solve non nail problems too indeed. But in a different way: what Redis provides are data structures much more similar to the data structures you find in a computer science book, linked lists, Sets, and server side operations against this kind of values. Programming with Redis is just like doing everything with Lists and Hashes inside memory with your favorite dynamic programming language, but the dataset is persistent and of course not as fast as accessing directly to your PC's memory (there is a networking layer in the middle).

那麼Redis如何詮釋關係型數據庫的問題呢？

Redis認爲關係型數據庫的數據模型並不適合那些不是「釘子戶」的問題。它的數據模型不易擴展，時間複雜度很難精確預測，在不少問題上的建模也很差。儘管今天各類替代方案的價值很難被衡量，但我期待在將來的幾年裏，關係型數據庫的真正問題會被你們探討清晰。數據庫模式的變化不會特別快，也許不少人以爲基於鍵值對的數據庫發展迅猛；但考慮到關係型數據庫今天已經發展的很是成熟了，其餘數據庫真的想要替代它還有一條很長的路要走。

What's wrong with RDBMS when used for (many) tasks that don't need all this complexity? The data model: non scalable, time complexity hard to predict, and can't model many common problems well enough. I expect that in a few years what was the real problem with RDBMS is going to be very clear, even if now it can look confusing enough and there are different alternatives and it is very hard to meter the relative value of the different solutions proposed. This kind of changes appear to be very fast, with all the key-value hype growing every week, but actually it's going to take much more time before to start considering RDBMS alternatives as conceptually mature as we look at RDBMS today.