特殊用途
Neo4j V1.5M02 版
开发语言： Java
主要特性： 图形化数据库
许可证： GPL，AGPL（商业用途）
数据传输格式： HTTP/REST（或内嵌在 Java 中）
- 可独立存在，或内嵌在 JAVA 的应用中
- 完全的 ACID 保证（包括正在处理的数据）
- 节点和节点的关系都可以拥有原数据
- 集成基于“模式匹配”的查询语言（Cypher）
- 支持“Gremlin”图形转化语言
- 可对节点与节点关系进行索引
- 良好的自包含网页管理技术
- 多个算法实现高级文件查找功能
- 可对 key 与 key 的关系进行索引
- 优化读性能
- 在 JAVA API 中实现事务处理
- 可运行脚本 Groovy 脚本
- 在商用版本中提供在线备份，高级监控和高可用性功能
应用场景：
使用案例：
搜寻社交关系网、公共传输链、公路路线图、或网络拓扑结构
ElasticSearch 0.20.1 版
开发语言： Java
主要特性： 高级搜索
许可证： Apache
数据传输格式： 通过 HTTP 使用 JSON 进行数据索引（插件：Thrift, memcached）
- 以 JSON 形式保存数据
- 提供版本升级功能
- 有父文档和子文档功能
- 文档有过期时间
- 提供复杂多样的查询指令，可使用脚本
- 支持写操作一致性的三个级别：ONE、QUORUM、ALL
- 支持通过分数排序
- 支持通过地理位置排序
- 支持模糊查询（通过近似数据查询等方式实现）
- 支持异步复制
- 自动升级，也可通过设置脚本升级
- 可以维持自动的“统计组”（对调试很有帮助）
- 只有一个开发者（kimchy）
应用场景：
- 当你有可伸缩性很强的项目并且想拥有“高级搜索”功能。
使用案例：
可布署一个约会服务，提供不同年龄、不同地理位置、不同品味的客户的交友需求。或者可以布署一个基于多项参数的排行榜。
其他
（不怎么有名，但值得在这里介绍一下）
Couchbase (ex-Membase) 2.0 版
开发语言： Erlang 和 C
主要特性： 兼容 Memcache，但数据是持久化的，并且支持集群
许可证： Apache
数据传输格式： 缓存和扩展（memcached + extensions）
- 通过 key 访问数据非常快（20万以上IOPS）
- 数据保存在磁盘（不像 Memcache 保存在内存中 —— 译者注）
- 在主主互备中，所有节点数据是一致的
- 提供类似 Memcache 将数据保存在内存的功能
- 支持重复数据删除功能
- 友好的集群管理 Web 界面
- 支持池和多丛结构的代理（利用 Moxi 项目）
- 支持 Map/reduce 模式
- 支持跨数据中心备份
应用场景：
使用案例：
低延迟可用于广告定投；高并发可用于在线游戏（如星佳公司）。
VoltDB 2.8.4.1版
开发语言： Java
主要特性： 快速的事务处理和数据变更
许可证： GPL 3
数据传输格式： 专有方式
- 运行在内存的关系型数据库
- 可以将数据导入到 Hadoop
- 支持 ANSI SQL
- 在 JAVA 环境中保存操作过程
- 支持跨数据中心备份
应用场景：
使用案例：
销售点数据分析系统；工厂控制系统。
Scalaris 0.5版
开发语言： Erlang
主要特性： 分布式 P2P 键值存储
许可证： Apache
数据传输和存储的方式： 自有方式和 基于JSON的远程过程调用协议
- 数据保存在内存中（使用 Tokyo Cabinet 作为后台时，数据可以持久化到磁盘中）
- 使用 YAWS 作为 Web 服务器
- Has transactions (an adapted Paxos commit)
- 支持事务处理（基于 Paxos 提交）（Paxos 是一种基于消息传递模型的一致性算法 —— 译者注）
- 支持分布式数据的一致性写操作
- 根据 CAP 定理，数据一致性要求高于数据可用性（前提是在一个比较大的网络分区环境下工作）（CAP
定理：数据一致性consistency、数据可用性availability、分隔容忍partition
tolerance是分布式计算系统的三个属性，一个分布式计算系统不可能同时满足全部三项）
应用场景：
- 如果你喜欢 Erlang 并且想要使用 Mnesia 或 DETS 或 ETS，但你需要一个能使用多种语言（并且可扩展性强于 ETS 和 DETS）的技术，那就选它吧。
使用案例：
使用基于 Erlang 的系统，但是想通过 Python、Ruby 或 JAVA 访问数据库
Kyoto Tycoon 0.9.56版
开发语言： C++
主要特性： 轻量级网络数据库管理系统
许可证： GPL
数据传输和存储的方式： HTTP (TSV-RPC or REST)
- 基于 Kyoto Cabinet, 是 Tokyo Cabinet 的成功案例
- 支持多种存储后端：Hash，树、目录等等（所有概念都是从 Kyoto Cabinet 那里来的）
- Kyoto Cabinet 可以达到每秒100万次插入/查询操作（但是 Tycoon 由于瓶颈问题，性能比 Cabinet 要差点）
- 服务器端支持 Lua 脚本语言
- 支持 C、JAVA、Python、Ruby、Perl、Lua 等语言
- 使用访问者模式开发（visitor patten：让开发者能在不修改类层次结构的前提下，定义该类层次结构的操作 —— 不明白就算了，译者也不明白）
- 支持热备、异步备份
- 支持内存数据库在后端执行快照
- 自动过期处理（可用来布署一个缓存服务器）
应用场景：
- 当你想要一个很精准的后端存储算法引擎，并且速度是刚需的时候，玩玩 Kyoto Tycoon 吧。
使用案例：
缓存服务器；股价查询系统；数据分析系统；实时数据控制系统；实时交互系统；memcached的替代品。
当然，上述系统的特点肯定不止列出来这么点。我只是列出了我认为很关键的信息。另外科技发展迅猛，技术改变得非常快。
附：现在下定论比较孰优孰劣还为时过早。上述数据库的版本号以及特性我会一个一个慢慢更新。相信我，这些数据库的特性不会变得很快。 | 
