Elasticsearch可以用作“NoSQL”数据库吗？NoSQL在不同的环境中有不同的含义，而且它实际上与SQL没有任何关系。一开始，我们只是觉得它是“可能的”，于是仔细研究了Elasticsearch的各种特性，包括它已经被用来实现最灵活、可扩展和高性能的分析查询引擎的那些特性。什么是NoSQL数据库？NoSQL-database将NoSQL定义为“主要解决以下问题的下一代数据库：非关系型、分布式、开放式、可扁平扩展”。换句话说，它不是一个精确的定义。它与SQL无关。例如，Hive查询语言显然受到了SQL的启发。Esper查询语言也是如此，只是它对流而不是关系进行操作。你知道PostgreSQL曾经被命名为“Postgres”并使用“Quel”作为它的查询语言吗？首先作为一个关系数据库管理系统（ORDBMS），它现在还具有许多使其能够进行无模式文档存储的特性。它也与ACID-properties无关。Hyperdex是NoSQL-database的一个例子，其目标是提供ACID-transactionalcapabilities。MySQL，确实是一个SQL-database，在历史上有一个解释ACID真正含义的模糊时期.关系？虽然大多数NoSQL数据库不支持加入传统关系数据的相同功能，但有些支持并将其留给用户练习。RethinkDB、Hive和Pig等。Neo4j，面向图形的数据库，isindeedfordealingrelationships-itisgoodattraversingrelationshipsinagraph(eg,edgesinagraph).Elasticsearch有一个概念叫做“查询时间”用于连接父子关系和“索引时间”用于连接嵌套类型。分销商泰德？已经有一些分布式SQL数据库，并且一些项目旨在做类似NoSQLite的事情，新一代的数据库倾向于以某种方式分布。总而言之，NoSQL没有理由做没有一个准确的定义，Elasticsearch不能简单的说是一个“文档存储”型的NoSQL-数据库。在我写这篇文章时，nosql-database.org列出了20多个这样的东西。在下一节中，我们将重点关注一些重要的属性，并了解Elasticsearch实现或不实现它们的原因。TransactionlessLucene是Elasticsearch的构建基础。它基于事务的概念。其他方面，Elasticsearch没有典型的事务。没有办法回滚一个已经提交的文件，你也不能提交一组文件并对全部或部分文件进行索引。然而，它拥有的是一个预写日志，可以确保业务流程的持久性，而无需进行昂贵的Lucene提交。还可以指定索引操作的一致性级别，保证多少副本可以在返回前确认操作条件。默认是一个quorum，比如逐片处理方式中的?n2?。当一个索引被刷新时，默认是每秒一次，这是需要控制变化的Visibility。通过对提交文档进行版本控制，可以实现乐观并发控制。Elasticsearch追求的是速度。支持分布式事务是一项很大的工作。不支持分布式事务让很多事情变得简单。只要我们可以接受我们读取的数据是陈旧的并且每个人都在同一时间点看到数据，那么Elasticsearch就可以通过缓存提供很多服务——这对我们所钟爱的超快性能至关重要。架构灵活性Elasticsearch不要求您先指定架构。给它一个JSON文档，它会进行一些训练有素的猜测来推断其类型。它可以很好地处理数字、布尔值和时间戳。对于字符串，它使用“规范化”解析，这通常是一个好的开始。从您不必指定模式的意义上说，它可以说是“无模式”的，我们更愿意将其视为“模式灵活”。为了进行大规模的搜索、分析，您确实需要对架构进行微调。Elasticsearch有大量强大的工具可以帮助您，例如动态模板、多字段对象等。这在我们关于映射的文章中有更多介绍。关系和约束Elasticsearch是一个面向文档的数据库。您要搜索的整个对象关系图都需要被索引，并且在文档被索引之前，它们必须首先被非规范化。反规范化提高了查询性能（因为不需要进行关系查询），使用了更多的存储空间（因为数据必须多次存储），但是更难维护数据的一致性和实时性（因为任何数据更改必须写入所有实例）。不过对于一次写频读的工作场景，表现还是相当不错的。例如，假设您在数据库中存储了客户、订单和产品等数据，现在您想要按产品名称和客户名称查找订单。您可以通过在为订单编制索引时包含有关客户和产品的所有必要信息来解决此问题。这样查询就很简单了，但是当你想改变一个商品的名称时会发生什么呢？在规范化良好的关系模型中，您只需要修改与产品对应的单个记录。.这就是关系型数据库所擅长的。然而，在非规范化文档数据库中，与产品相关的所有订单都必须更新。换句话说，在面向文档的数据库中，例如Elasticsearch，我们映射和存储文档只是为了优化查询和信息检索性能。如介绍中所述，Elasticsearch可以使用父/子关系进行“查询时”连接，或使用嵌入式类型进行“索引时”连接。我们将在以后的文章中深入讨论这个主题。我们推荐MartijnvanGroningen的文章“DocumentrelationswithElasticsearch”。大多数关系数据库还允许您指定约束关系来定义什么需要保持一致，什么不需要。例如，参照完整性和唯一性都是强制性的。可以要求账户变动金额必须是正数等，面向文档的数据库一般不会这样，而Elasticsearch会。健壮性数据库应该是健壮的，尤其是当它是您的权威记录系统时。理想情况下，应该撤消资源密集型查询，并且您当然不希望数据库停止工作，除非您告诉它。不幸的是，Elasticsearch（及其组件）目前不能很好地处理OutOfMemory错误。我们在ElasticsearchinProduction,OutOfMemory-CausedCrashes中更深入地讨论了这个问题。因此，为Elasticsearch配置足够的内存非常重要，并小心运行无法预测生产集群中将消耗多少内存的查询。不过，随着Elasticsearch的成熟，这个问题可能会有所改善，记住Elasticsearch的目标是追求速度，所以它假设内存永远是足够的。分布式另请参阅：生产环境中的Elasticsearch、网络。ShayBanon在创建Elasticsearch之前曾在Compass工作。意识到很难变成一个分布式搜索引擎，他从头开始创建了Elasticsearch1。Elasticsearch旨在实现分布式和轻松扩展，以在商品硬件上处理大量数据。作为一个分布式系统，Elasticsearch的上手和使用非常简单，但分布式系统本身很复杂。我们在Elasticsearch的Production,Networking中对此进行了更多讨论，因此下面只是一个简短的总结。分布式系统的固有特性意味着很多事情都可能出错。同样，不同的数据库系统力求具有不同的优势：一些力求强大的安全保证，另一些力求高可用性，即使有时（甚至大部分时间）出现问题。而且，正如KyleKingsbury在他关于网络分区风险的优秀系列文章中指出的那样，当问题确实发生时，数据库系统实际上并没有像他们声称的那样处理它们。简而言之，他发现虽然分布式数据库表现良好并且天空晴朗，但当它们遭受大量可能的问题时，绝大多数数据库努力都会失败。在一致性、可用性和分区容错性方面，Elasticsearch是一个CP系统，对“一致性”的定义相当不稳定。如果您有只读工作负载，Elasticsearch允许您以宽松的“最小主节点”要求（例如，不需要法定人数）来实现AP行为。但是，通常您需要集群中有大量节点可用。写入没有大量节点的配置错误的集群，例如“裂脑”集群，可能会导致不可恢复的数据丢失。这不仅仅是Elasticsearch特有的。Elasticsearch选择自己的主节点。然而，这是一个相当简单且不是很健壮的算法，在现实世界的网络压力下可能会导致很多问题。事实上，我们管理着数百个集群，经常会看到主节点选择问题，所以我们主动将主节点移到ZooKeeper中，尽管我们也有其他目的。在可扩展性方面，索引被分成一个或多个分片。这是在创建索引时指定的，不能更改。因此，随着预期的增长，一个指数应该被适当地拆分。随着更多节点添加到Elasticsearch集群，它可以很好地重新分配和移动分片。因此，Elasticsearch易于扩展。安全性另请参阅：生产环境中的Elasticsearch、安全性。Elasticsearch不提供授权和身份验证功能。您可以认为任何可以连接到您的Elasticsearch集群的人都拥有“超级用户”权限，尤其是在启用了Elasticsearch强大的脚本功能的情况下。总结如果本文描述的任何限制都不能阻止您，您当然可以使用Elasticsearch作为您的主要存储库。一个很好的例子是当您使用Logstash时。Logstash是一个用于管理日志并将其导入Elasticsearch的神奇工具，您可以对日志进行备份以防万一。日志一次写入，多次读取。不需要升级，不需要事务支持，没有完整性约束等。还有像Postgres这样具有全文搜索和ACID事务的系统呢？（其他例子包括MySQL、MongoDB、Riak等的全文搜索能力）你当然可以通过Postgres实现基本的搜索，但是在性能和??功能上与ElasticSearch存在巨大差距。正如我们在事务部分提到的，Elasticsearch做了很多缓存，因此有可能“欺骗”我们而不关心版本之间的并发控制和其他复杂的事情。搜索不仅仅是在一段文本中查找关键字：它是关于使用特定领域的知识来实现??良好的相关性模型，该模型提供整个结果空间的概览，并执行拼写检查和自动完成等操作工作。所有这些都在快速进行。Elasticsearch通常用作其他数据库的补充。这样的数据库系统必须具备强大的数据约束保证、容错性和健壮性、高可用性以及支持事务的数据更新能力。它维护核心数据——这些数据随后将被异步推送到Elasticsearch（并且可能是提取，前提是你使用Elasticsearch的“河流”之一）。保持数据同步是我们打算在以后的文章中深入探讨的主题。这里，在Found网站的文章中，我们使用具有代表性的PostgreSQL和ZooKeeper提供源数据，并将这些数据输入到Elasticsearch中，提供强大的搜索功能。与其他一切一样，没有灵丹妙药，也没有一个数据库可以做所有事情。也许这将永远持续下去，所以一定要了解您的数据库的优势和劣势！原文链接：https://www.found.no/foundation/elasticsearch-as-nosql/翻译链接：http://www.oschina.net/translate/elasticsearch-as-nosql
