本文是一篇转载翻译文章,原文标题是 Is CouchDB The Anti-Redis? 作者在对比了Redis和CouchDB之后得出这样一个结论,这两家伙是反着来的,当然,这个反着来没有对和错,只是适合的应用场景不同,本人觉得其评价还是比较中肯,下面是对其主要内容的摘录和翻译,希望对你有用。
相比来看,CouchDB 的长处正是Redis的短处:存储大量的不易变但会被经常查询的数据。Redis的长处正是CouchDB的短处:存储小量的常变数据。
以一个博客系统为例,CouchDB作为一个文档型数据库,可以用来存储文章,评论,模板及附件等,而Redis以其丰富的数据类型的数据结构,更适合用来存储评论列表,网站实时状态,过滤spam,用户session信息以及页面缓存。
作为一个内存数据库,Redis提供了快速对其数据结构进行复杂操作的功能,另外通过一份顺序的日志来保证其数据可靠性。
CouchDB使用了一种append-only的数据模型,不仅在数据库数据存储上,包括其B-tree和R-tree索引都是append-only的,所以如果你的数据修改操作太多(比如计数器应用),那么CouchDB的数据文件会飞速膨胀。
Redis采用定时将内存数据Flush成RDB文件的方法来实现数据的持久化,而CouchDB的数据需要定时做数据压缩以缩减数据文件的大小,这一过程会把数据文件读入,压缩后再写成新的文件。是一个非常耗时的过程。
Redis提供了简单的索引机制和复杂的数据结构,而CouchDB提供的是复杂的索引和简单的数据结构。Redis适合用来存储实时数据,而CouchDB适合用来存储大量的文档型数据。
下面是一个更详细的各方面对比表格:
| Couchdb | Redis |
Written in | Erlang | C |
License | Apache | BSD |
Release | 1.1.0, 2.0 preview | 2.2.12, 2.4.0RC5 |
API | REST | Telnet-style |
API Speed | Slow | Fast |
Data | JSON documents, binary attachments | Text, binary, hash, list, set, sorted set |
Indexes | B-tree, R-tree, Full-text (with Lucene), any combination of data types via map/reduce | Hash only |
Queries | Predefined view/list/show model, ad-hoc queries require table scans | Individual keys |
Storage | Append-only on disk | In-memory, append-only log |
Updates | MVCC | In-place |
Transactions | Yes, all-or-nothing batches | Yes, with conditional commands |
Compaction | File rewrite | Snapshot |
Threading | Many threads | Single-threaded, forks for snapshots |
Multi-Core | Yes | No |
Memory | Tiny | Large (all data) |
SSD-Friendly | Yes | Yes |
Robust | Yes | Yes |
Backup | Just copy the files | Just copy the files |
Replication | Master-master, automatic | Master-slave, automatic |
Scaling | Clustering (BigCouch) | Clustering (Redis cluster*) |
Scripting | JavaScript, Erlang, others via plugin | Lua* |
Files | One per database | One per database |
Virtual Files | Attachments | No |
Other | Changes feed, Standalone applications | Pub/Sub, Key expiry |
来源:ai.mee.nu