把ElasticSearch当成是NoSQL数据库

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

NoSQL 数据库是什么?

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

无事务

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

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

在一致性，可用性，以及分区容错性方面，Elasticsearch 是一个CP系统，一个相当不靠谱的“一致性”定义。如果你有一个只读的工作负载， Elasticsearch 允许你通过不严格的“最小主节点”要求（如不需要quorum）实现AP行为。然而，通常你需要集群中大量节点是可用的。写入一个配置错误的没有大量节点 的集群，像“split brain”集群，可能引起无法恢复的数据丢失。这不只是特定于Elasticsearch的。

总结

如果本文描述的这些限制都不能阻止你，你当然可以使用Elasticsearch作为主存储库。一个不错的例子是，当你使用Logstash时。Logstash是一个神奇的工具，用来管理日志并把它们导入到Elasticsearch中，你可以只是对日志进行备份以防万一。日志都是一次写入，多次读取的。不需要升级，不需要事务支持，没有完整性约束，等等。

那么像Postgres那样的系统怎么样呢，它有全文检索和ACID-事务。 (其它例子包括MySQL, MongoDB, Riak等等的全文检索能力) 你当然可以通过Postgres来实现基本的检索，但是在性能上和功能上与ElasticSearch都有巨大的差距。正如我们在事务那 一节中所提到的，Elasticsearch会做很多缓存，所以有可能会“欺骗”我们，而且不关心多版本之间的并发控制以及其它复杂的事情。搜索远不止在 一段文本中找到一个关键字那么简单:它是利用领域特定知识来实现良好的相关度模型，由此给出整个结果空间的一个全貌，并且能做拼写检查和自动补全之类的工 作。而且所有这些工作都要保证速度。

Elasticsearch通常被用作其它数据库的补充。那样的数据库系统要有强大的数据约束保证、容错性和鲁棒性、高可用性和带事务支持的数据更 新能力，它维护着核心数据 - 这些数据随后会被异步推送到Elasticsearch中去(也可能是抽取，前提是你使用了Elasticsearch的某一种“rivers”)。 保持数据同步是我们打算将来撰文深入探讨的话题。这里，在Found网站的文章中，我们使用具有代表性的PostgreSQL和ZooKeeper来提供 源数据，并把这些数据输入给Elasticsearch来提供强大的搜索。

像其它所有事情一样，没有包治百病的灵丹妙药，没有一个数据库可以做到所有的事情。也许这种情况会永远持续下去，所以一定要了解你的数据库的优点和弱点!