最近刷了不少爱豆antirez(redis做者)的博客。今天读了很老的一篇,以为写得有点意思。读书的时候很喜欢英语,差点去学了语言专业。想来历来没尝试过翻译,心血来潮暂且拿这篇试试。redis
MongoDB and Redis: a different interpretation of what's wrong with Relational DBmongodb
作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理论上都尝试解决同一个问题,但对问题的分析却截然不同。bash
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是如何工做的。它的核心观点是创造对象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的开发者的思路是这样的:app
关系型数据库对不少问题来讲简直是杀鸡用牛刀,那些问题根本不须要这么复杂的设计。关系型数据库变成了庞然大物,所以又慢又难搬。可是它的数据模型仍是好的,表、索引以及支持各类复杂的查询语句都没有问题。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. ide
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.