把 ElasticSearch 当成是 NoSQL 数据库 【已翻译100%】

Elasticsearch 可以被当成一个 "NoSQL"-数据库来使用么? NoSQL 意味着在不同的环境下存在不同的东西, 而erestingly 它并不是真的跟 SQL 有啥关系. 我们开始只会觉得 "可能"而已, 所以细细研究了 Elasticsearch 的各种属性，包括它已经为了成就最具灵活性，可伸缩性和性能优异的分析查询引擎的那些属性.

NoSQL 数据库是什么?

NoSQL-数据库 将 NoSQL 定义为“下一代主要解决如下问题的数据库: 非关系型的，分布式的，开元的并且可以扁平扩展.”. 换言之，它并不是一个精确的定义.

它尤其与SQL无关. 比方说， Hive 查询语言的灵感显然来自 SQL.  Esper查询语言同样如此, 只是它操作的是流而不是关系. 还有你知道 PostgreSQL 过去被命名为 “Postgres” 并使用 “Quel” 作为它的查询语言么? 而首先作为一个关系型数据库管理系统（ ORDBMS）, 它现在同样有许多的特性使其具备无模式文档存储的能力.

它同样也和ACID-特性无关. Hyperdex 就是一个 NoSQL-数据库的例子，它的目标就是提供 ACID-事务能力. MySQL, 确实是一个 SQL-数据库, 历史上它有一段解释 ACID 的真正意义的暧昧时期.

关系型的? 虽然大多数的 NoSQL-数据库并不支持加入传统关系型数据意义相同的功能，但还是有一些那样做了，并将其留给用户当做练习使用. RethinkDB, Hive 还有 Pig, 等等. Neo4j, 面向图形的数据库, 确实是处理关系用的 - 它擅于遍历图中的关系 (比如，图中的边) . Elasticsearch 有一个概念叫做加入父子关系的“查询时间”和加入嵌套类型的“索引时间“.

分布式的? 已经有一些分布式的 SQL-数据库 了, 并以 一些项目 旨在做一些像一个NoSQLite那样的事情, 更新一代的数据库趋向于在某些方式上具备分布式能力.

总而言之, 既没有道理给 NoSQL 做出精确的定义, 也不能简单的说 Elasticsearch 是一个“文档存储”-类型的NoSQL-数据库. 在我写这篇文章的时候, nosql-database.org 列出了超过20 个那样的东西.

在下一节，我们将关注一些重要的属性并且看看 Elasticsearch 为什么要实现或者不去实现它们.

无事务

Lucene, 是 Elasticsearch 的构建的基础, 它是由一个事务的概念的. 而Elasticsearch在另外的方面, 并没有典型意义的事务. 对于已经提交的文档并没有办法回滚, 而你也不能提交一组文档并且为它们所有或者其中一些建立索引. 然而它所具备的, 是一个用来确保业务过程持久性而不用做昂贵的Lucene提交的预写日志. 你也可以指定索引操作的一致性级别, 以确保在返回之前有多少副本可以拿来确认操作条件. 默认的是法定人数, 例如 ⌊n2⌋

在逐个切片进行处理的方式中，当一个索引被刷新时，默认是一秒钟一次，就需要对变更的可见性进行控制。

通过制定提交文档的版本，可以进行乐观并发控制。

Elasticsearch追求的是速度。支持分布式事务是一大块工作。不支持分布式事务会使得很多事情变得容易起来。只要我们能接受读取到的数据有些陈旧，而且所有人看到的是同一时间点的数据，那么Elasticsearch就可以利用缓存提供很多服务 - 这对于我们钟爱的极速性能来说是至关重要的。

模式灵活

Elasticsearch 不要求你先指定模式。扔给它一个 JSON 文档，它就会进行一些训练有素的猜测来推断其类型。对于数值、布尔、时间戳它可以做的很好。对于字符串，它会使用“标准化”的分析，这通常是良好的开始。

它是有商榷的“无模式”，在这个意义上你不必指定一个模式，我们更愿意把它认做是“模式灵活”。为了开发大规模的搜索、分析，你确实需要对模式进行微调。Elasticsearch 有大量的强大工具可以帮助你，例如动态模板、多字段对象等。这在我们关于映射的文章里会谈及更多。

关系和约束

Elasticsearch是一种面向文档的数据库。你想要对之进行搜索的整个对象关系图，都需要进行索引，在对文档进行索引之前，它们必须先被反规范化。反规范化提升了查询性能(因为不再需要进行关联查询)，使用了更多存储空间(因为数据必须被存储多次)，但是，要保持数据一致性和实时性则更加困难(因为任何数据改变都必须被写入到所有实例中去)。不过，对于一次写入频繁读取的工作场景，它的表现相当优异。

举例来说，假设你在数据库中存储了客户、订单和产品等数据，现在你想要通过产品名字和客户姓名来查找订单。可以这样来解决这个问题：在对订单进行索引时，把客户和产品的所有必要信息都加进来。这样的话，查询就非常简单，但是当你想要改变某个产品的名字时会出现什么情况呢? 在进行了良好规范化的关系型模型中，你只需要修改该产品对应的单条记录就搞定了。这是关系型数据库所擅长的。而在反规范化的文档数据库中，将不得不更新与该产品有关的所有订单。

换句话说，在面向文档类型的数据库中，比如Elasticsearch, 我们对文档进行映射和存储设计只是为了优化查询和信息获取的性能。

在介绍中已经提到，Elasticsearch中可以使用父/子-关系进行“查询时”连结，也可以使用内嵌类型进行“索引时”连结。我们会在以后的文章中对该主题进行深入介绍。我们推荐Martijn van Groningen的一篇文章“Document relations with Elasticsearch”.

大多数关系型数据库也会允许你指定约束关系，来定义什么需要保持一致性，什么不需要保持一致性。比如，参照完整性和唯一性都是强制性的。你可以要求账户变更金额必须是正数，等等。而面向文档的数据库不倾向于这么做，Elasticsearch就是如此。