最近刷了很多爱豆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.
