Elasticsearch from the Bottom Up, Part 1

自下而上认识 Elasticsearch：第 1 部分

<p><strong>更新：</strong>本文提及我们的托管式 Elasticsearch 产品时使用的是旧称 Found。请注意，Found 现在称为 Elastic Cloud。<a href="https://www.elastic.co/cn/cloud/as-a-service/signup">托管式 Elasticsearch 可在 Elastic Cloud 上免费试用 14 天</a>。</p><p>Elasticsearch 可以用作“NoSQL”数据库吗？NoSQL 在不同的上下文中有不同的含义，有趣的是，它实际上与 SQL 无关。我们将从一种“不确定的情况”入手，了解 Elasticsearch 的各种属性，以及它为了成为迄今为止最灵活、最具可扩展性、性能最佳的搜索和分析引擎之一而牺牲的那些属性。
</p><section id="what-is-a-nosql-database-anyway" class="level2">
<h2><a href="#what-is-a-nosql-database-anyway">究竟什么是 NoSQL 数据库？</a></h2>
<p><a href="http://nosql-database.org/">NoSQL 数据库</a>将 NoSQL 定义为“下一代数据库，主要涉及到以下几点特征：非关系型、分布式、开源以及可横向扩展”。<em></em><em></em>换句话说，这不是非常精确的定义。
</p>
<p>它并不是专门针对 SQL 的。例如，<a href="http://hive.apache.org/">Hive</a> 的查询语言显然受到了 SQL 的启发。<a href="http://esper.codehaus.org/">Esper</a> 的查询语言也是如此，它对流而不是关系进行操作。另外，您知道过去 PostgreSQL 被命名为“Postgres”，并且使用“Quel”作为查询语言吗？虽然首先是 ORDBMS，但它现在同样有许多<a href="http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-database/">特性使其具备不区分模式的文档存储能力</a>。
</p>
<p>而且，与 ACID 特性也无关。<a href="http://hyperdex.org/">Hyperdex</a> 是 NoSQL 数据库的一个示例，旨在提供 ACID 事务。MySQL（当然是 SQL 数据库）对 ACID 的真正含义一直以来有着令人怀疑的解释。
</p>
<p>关系？虽然大多数 NoSQL 数据库不支持与传统关系型数据库相同意义上的连接，并需要用户自行解决这一问题，但也有一些数据库能够提供支持。比如，<a href="http://www.rethinkdb.com/">RethinkDB</a>、<a href="http://hive.apache.org/">Hive</a> 和 <a href="http://pig.apache.org/">Pig</a> 等等。<a href="http://www.neo4j.org/">Neo4j</a> 是面向图形的数据库，当然会处理关系 — 它非常擅长遍历图形中的关系（即边）。在 Elasticsearch 中，可以使用<a href="/guide/reference/mapping/parent-field">父/子关系</a>进行“查询时”连接，也可以使用<a href="/guide/reference/mapping/nested-type">嵌套类型</a>进行“索引时”连接。
</p>
<p>分布式？虽然存在一些分布式 SQL 数据库，也有<a href="https://github.com/petersirka/nosql">一些</a><a href="http://ejdb.org/">项目</a>旨在成为像 NoSQLite 一样的数据库，但更新一代的数据库往往采用某种分布形式。
</p>
<p>总而言之，准确地定义 NoSQL，或者简单地说 Elasticsearch 是“文档存储”类型的 NoSQL 数据库，都没有意义。在撰写本文时，<a href="http://nosql-database.org/">nosql-database.org</a> 列出了其中的 20 多个属性。
</p>
<p>在接下来的部分中，我们将了解一些重要属性，以及 Elasticsearch 如何实现或不实现这些属性。
</p>
</section><section id="transactions" class="level2">
<h2><a href="#transactions">无事务</a></h2>
<p>Lucene（Elasticsearch 在它的基础上构建而成）有事务的概念。相反，Elasticsearch 没有典型意义上的事务。无法回滚已提交的文档，而且您不能提交一组文档，并对全部文档都编制索引或都不编制索引。然而，Elasticsearch 所拥有的是一个预写日志，旨在确保操作的持久性，而不必进行开销高昂的 Lucene 提交。此外，您还可以指定索引操作的一致性级别，即返回之前必须确认操作的副本数。默认为法定数量，即 <span class="math">$\lfloor\frac{n}{2}\rfloor + 1$</span>。
</p>
<p>更改的可见性是在刷新索引时控制的，默认情况下每秒刷新一次，并且是逐个分片进行的。
</p>
<p>乐观并发控制是通过指定已提交文档的版本来实现的。
</p>
<p>Elasticsearch 追求的是速度。执行分布式事务是一项繁重的工作。<em></em>不提供分布式事务会让很多事情变得更容易。只要我们能接受读取到的数据可能有些陈旧，而且所有人看到的是同一时间点的数据，那么 Elasticsearch 就可以利用缓存提供很多服务 — 这对于我们钟爱的极速性能来说是至关重要的。
</p>
</section><section id="schema-flexible" class="level2">
<h2><a href="#schema-flexible">模式灵活</a></h2>
<p>Elasticsearch 不要求您预先指定模式。<em></em>扔给 Elasticsearch 一个 JSON 文档，它就会进行一些有根据的猜测来推断这个文档的类型。Elasticsearch 可以很好地处理数字、布尔值和时间戳等数据。对于字符串，它会使用“标准”分析器，这通常很容易上手。
</p>
<p>虽然 Elasticsearch 可以说是“无模式”的，从某种意义上说，您不必指定模式，但我们更愿意将其视为“模式灵活”。<em></em><em></em>为了开发出色的搜索和/或分析，您确实需要对模式进行微调。Elasticsearch 有一系列功能强大的工具可以为您提供帮助，如动态模板、多字段对象等。我们在关于映射的一篇文章中对此进行了详细介绍。
</p>
</section><section id="relations-and-constraints" class="level2">
<h2><a href="#relations-and-constraints">关系和约束</a></h2>
<p>Elasticsearch 是一种面向文档的数据库。需要对要搜索的整个对象图形编制索引，因此在对文档编制索引之前，必须对其进行<em>反规范化</em>处理。反规范化可提高检索性能（因为不需要查询连接），会使用更多的空间（因为必须多次存储数据），但要保持数据一致性和实时性则更加困难（因为任何数据更改都必须应用到所有实例中）。不过，对于一次写入频繁读取的工作负载，它的表现相当优异。
</p>
<p>举例来说，假设您在数据库中存储了客户、订单和产品等数据，并且您想要通过产品名称和客户姓名来搜索订单。要解决这个问题，可以在为订单编制索引时把客户和产品的所有必要信息都加进来。这样的话，搜索起来就非常简单，但如果您想要更改某个产品的名称会出现什么情况呢？在进行了良好规范化的关系型设计中，您只需要更新相应的产品就可以搞定。这正是关系型数据库所擅长的。而在反规范化的文档数据库中，将不得不更新与该产品有关的所有订单。
</p>
<p>换句话说，在面向文档的数据库（如 Elasticsearch）中，我们对文档进行映射和存储设计只是为了优化搜索和检索的性能。
</p>
<p>在简介中已经提到，Elasticsearch 中可以使用<a href="/guide/reference/mapping/parent-field">父/子关系</a>进行“查询时”连接，也可以使用<a href="/guide/reference/mapping/nested-type">嵌套类型</a>进行“索引时”连接。我们会在以后的文章中对该主题进行深入介绍。在此我们推荐 Martijn van Groningen 的演讲“<a href="/cn/videos/bbuzz2013-document-relations-with-elasticsearch">Document relations with Elasticsearch</a>”（使用 Elasticsearch 记录关系）。
</p>
<p>大多数关系型数据库还允许您通过指定约束来定义哪些数据需要保持一致性，哪些不需要保持一致性。比如，参照完整性和唯一性都是强制性的。您可以要求帐户变动的金额必须是正数，等等。面向文档的数据库往往不会这样做，Elasticsearch 也不例外。
</p>
</section><section id="robustness" class="level2">
<h2><a href="#robustness">稳健性</a></h2>
<p>数据库应该稳定可靠，尤其是当它是您的权威记录系统时。理想情况下，耗费资源的查询应当可以取消，并且您肯定不希望数据库停止工作，除非您命令它停下来。
</p>
<p>遗憾的是，Elasticsearch（及其组件）目前并不能很好地处理 <code>OutOfMemory</code> 错误。我们在<a href="/cn/blog/found-elasticsearch-in-production">生产环境中的 Elasticsearch - OutOfMemory 导致的崩溃</a>一文中更深入地介绍了这一点。因此，为 Elasticsearch 配置足够多的内存就显得非常重要，而且要在生产集群上谨慎运行那些无法预知将会耗费多少内存的查询。
</p>
<p>不过，随着 Elasticsearch 越来越成熟，这个问题很可能会得到改善，但重要的是要记住，Elasticsearch 的目标是提升速度，所以它假设内存是充足的。<em></em>
</p>
</section><section id="distributed" class="level2">
<h2><a href="#distributed">分布式</a></h2>
<p>另请参阅：<a href="/cn/elasticsearch">生产环境中的 Elasticsearch - 网络</a>。
</p>
<p>在创建 Elasticsearch 之前， Shay Banon 一直在开发 <a href="https://thedudeabides.com/articles/the_future_of_compass">Compass</a>。由于意识到很难将其转变成一个分布式的搜索引擎，他就从头开始创建了 Elasticsearch<span class="citation" data-cites="future-of-compass"><a href="#fn1" class="footnoteRef" id="fnref1"><sup>1</sup></a></span>。Elasticsearch 采用分布式且易于扩展的设计，可以在商用硬件上处理海量数据。<em></em>
</p>
<p>作为一个分布式的系统，Elasticsearch 的上手和使用都非常简单，但是分布式系统本身是很复杂的。<em></em>关于这一点，我们在<a href="/cn/blog/found-elasticsearch-in-production">生产环境中的 Elasticsearch - 网络</a>一文中有更多的介绍，所以下面只是一个简短的摘要。
</p>
<p>分布式系统天生的特性，意味着很多事情都可能会出错。因此，不同的数据库系统侧重于不同的优势：有些力争强大的安全保证，另外一些则致力于始终可用，即使某些时候（甚至多数时候）出现错误也在所不惜。而且，正如 <a href="http://aphyr.com/">Kyle Kingsbury</a> 在他关于 <a href="http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions">perils of network partitions</a>（网络分区的危险）的优秀系列文章中所指出的那样，在出现问题时，实际上数据库系统并没有像它们所宣称的那样来处理问题。<em></em><em></em>简言之，他发现，虽然分布式数据库在阳光明媚的日子里运行良好，但绝大部分数据库在遭受到<a href="http://aphyr.com/posts/288-the-network-is-reliable">大量可能的问题时所做的努力，都会以失败而告终</a>。
</p>
<p>就一致性、可用性和分区容错性而言，Elasticsearch 是一个 CP 系统，对于“一致性”的定义相当不靠谱。如果您有一个只读工作负载，Elasticsearch 允许您通过不严格的“最小主节点”要求（即不需要法定数量）来实现 AP 行为。然而，通常情况下，您需要集群中的大多数节点是可用的。写入一个配置错误（无法保证大多数节点可用）的集群，即“脑裂”集群，可能会导致无法恢复的数据丢失。这绝不只特定于 Elasticsearch。
</p>
<p>就扩展而言，一个索引可以被划分为一个或多个分片。这是在创建索引时指定的，不能更改。因此，随着预期的增长，应将一个索引合理地进行分片。随着越来越多的节点被添加到 Elasticsearch 集群中，它在重新分配和移动分片方面表现良好。因此，Elasticsearch 很容易横向扩展。
</p>
</section><section id="security" class="level2">
<h2><a href="#security">安全性</a></h2>
<p>另请参阅：<a href="/cn/security">生产环境中的 Elasticsearch - 安全性</a>。
</p>
<p>Elasticsearch 没有任何身份验证或授权特性。您可以这样认为：任何人只要能连接到您的 Elasticsearch 集群，就拥有了“超级用户”权限，尤其是在启用了 Elasticsearch 强大的脚本功能的情况下。
</p>
</section><section id="summary" class="level2">
<h2><a href="#summary">总结</a></h2>
<p>如果本文描述的这些限制都不能阻止您，您当然可以将 Elasticsearch 用作主存储。使用 <a href="/cn/logstash">Logstash</a> 就是一个很好的例子。Logstash 是一个非常棒的工具，用来管理日志并把它们导入到 Elasticsearch 中，也许还可以将日志归档到其他地方以备不时之需。日志都是一次写入，多次读取的。不需要更新，不需要事务支持，也没有完整性约束等。
</p>
<p>那么像 Postgres 这样带有<a href="http://www.postgresql.org/docs/current/static/textsearch.html">全文搜索</a><em>和</em> ACID 事务的系统呢？（其他示例包括 MySQL、MongoDB、Riak 等的全文检索能力。） 虽然您可以用 Postgres 来实现基本的搜索，但在性能和功能上与 Elasticsearch 都有很大的差距。正如我们在<a href="#transactions">事务</a>部分所提到的，Elasticsearch 会进行大量缓存，所以可能会“欺骗”我们，而且不关心多版本之间的并发控制和其他复杂的事情。搜索也远不止在一段文本中找到一个关键字那么简单：它涉及到运用领域特定的知识来实现良好的相关性模型，由此给出整个结果空间的一个全貌，并且能做拼写检查和自动补全之类的工作。而且，所有这些操作都要保证速度。<em></em>
</p>
<p>Elasticsearch 通常被用作其他数据库的补充。<em></em>这类数据库系统更注重约束、正确性和稳健性，并且随时可进行事务更新，拥有主记录 – 这些记录随后会被异步推送到 Elasticsearch。（也可能是拉取，前提是您使用了 Elasticsearch 的某一种“river”。） 保持数据同步是我们打算将来撰文深入探讨的话题。在 Found 中，我们通常使用 PostgreSQL 和 ZooKeeper 作为真实数据的来源，我们将这些数据输入给 Elasticsearch 来提供出色的搜索体验。
</p>
<p>就像所有其他事情一样，没有包治百病的灵丹妙药，没有一个数据库可以做到所有的事情。也许这种情况会永远持续下去，所以要清楚您的数据库的优点和弱点！
</p>
<div class="references">
	<h2><a href="/">参考资料</a></h2>
	<p>Shay Banon：<em>The future of compass & elasticSearch</em>（Compass 和 Elasticsearch 的未来）– <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>
	</p>
</div>
</section><section class="footnotes">
<hr>
<ol>
	<li id="fn1">Shay Banon，<em>The future of compass & elasticSearch</em>（Compass 和 Elasticsearch 的未来）– <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>。<a href="#fnref1">↩</a></li>
</ol>
</section>

Elasticsearch as a NoSQL Database

把 Elasticsearch 用作 NoSQL 数据库

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/elastic-cloud-account-terms" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。</p>

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

本页内容尚不支持所选语言。Elastic 正在不断努力，以实现对多种语言内容的支持。感谢您在此期间给予的耐心与陪伴！

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

查看本次网络研讨会在我的时区的开始时间

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

无法实时参加？注册后我们会给您发送录像。您还将收到相关内容的电子邮件。

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

You'll also receive an email with related content

你将会收到一封相关内容的电邮。

Thank you for registering. We will send you a confirmation email soon.

谢谢注册。我们会尽快给您发送确认邮件。

What to explore next...

Load more news

Filters

Load more press releases

Share on Twitter

Continue reading

<p>Elasticsearch 背后的一个关键原则是，让您可以充分利用您的数据。最初，搜索是一种只读业务，搜索引擎从单一源加载数据。随着使用量的增加，Elasticsearch 在应用程序中的重要性与日俱增，数据需要由多个组件更新。多个组件会导致并发，而并发又导致了冲突。Elasticsearch 的版本控制系统就是帮助解决这些冲突的。</p><h2>举例说明版本控制的必要性</h2><p>为了说明情况，我们假设有一个网站，人们用它来评价 T 恤的设计。这个网站很简单。它列出了所有设计，用户可以对设计竖起大拇指，也可以使用拇指向下图标对设计投反对票。对于每件 T 恤，网站都会显示当前的赞成票与反对票的对比情况。</p><p>每个搜索引擎的记录如下：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1' -d'<br/>{<br/>    "name": "elasticsearch",<br/>    "votes": 999<br/>}'<br/></pre><p>可以看到，每件 T 恤的设计都有一个名称和一个票数计数器，用于跟踪当前的对比情况。</p><p>为了保持简单化和可扩展性，网站是完全无状态的。当有人浏览页面并点击赞成票按钮时，系统会向服务器发送一个 AJAX 请求，指示 Elasticsearch 更新计数器。为此，一个简单的实现方法是，获取当前的票数值，将其递增 1，然后发送给 Elasticsearch：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1' -d'<br/>{<br/>    "name": "elasticsearch",<br/>    "votes": 1000<br/>}'<br/></pre><p>这种做法有一个严重的缺陷，那就是可能会丢失票数。假设 Adam 和 Eve 同时在查看同一个页面。此时该页面显示票数为 999。由于这两个人都是支持者，他们都点击了赞成票按钮。现在，Elasticsearch 收到了上述请求的两个相同副本来更新文档，它很乐意这样做。这意味着总票数不再是 1001 票，而是现在的 1000 票。糟糕！</p><p>当然， 使用更新 API 可以变得更加智能，并传达这样一个事实：投票数可以递增，而不是设置为特定值：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/_update' -d'<br/>{<br/>   "script" : "ctx._source.votes += 1"<br/>}'<br/></pre><p>这样做的逻辑是，Elasticsearch 首先在内部检索文档，执行更新，然后再次执行索引。虽然这样做更有可能成功，但仍然存在与先前相同的潜在问题。在检索文档和再次执行索引之间的一个短暂的时间段内，可能会出现错误。</p><p>为了处理上述情况，帮助解决更复杂的问题，Elasticsearch 提供了内置的版本控制系统。</p><h2>Elasticsearch 的版本控制系统</h2><p>您存储在 Elasticsearch 中的每一个文档都有一个相关的版本号。这个版本号是介于 1 和 2 <sup>63</sup>-1（包含本数）之间的一个正数。当您第一次对文档进行索引时，它会得到版本号 1，您可以在 Elasticsearch 返回的响应中看到这一点。例如，以下是本博文中第一个 cURL 命令的结果：</p><pre class="programlisting prettyprint lang-js">{<br/>   "ok": true,<br/>   "_index": "designs",<br/>   "_type": "shirt",<br/>   "_id": "1",<br/>   "_version": 1<br/>}<br/></pre><p>每次对这个文档执行写入操作（无论是 索引、更新还是删除），Elasticsearch 都会将版本号递增 1。这种递增是原子性的，并且保证会在操作成功返回时进行递增。</p><p>Elasticsearch 还会在 get 操作的响应中返回文档的当前版本（请注意，这些都是实时的），此外，还会 收到指示，在每次搜索结果中都返回当前版本。</p><h2>乐观锁定</h2><p>回到我们的示例中，我们需要解决两个用户同时尝试更新同一文档的问题。传统的解决方法是锁定：在更新文档之前，一个人将获取文档锁，完成更新后再释放锁。对文档执行锁定后，就可以保证没有人能更改该文档。</p><p>在许多应用程序中，这也意味着如果有人正在修改文档，则在修改完成之前，其他人都无法读取该文档。这种锁定方式虽然有效，但也需要付出代价。在高吞吐量的系统环境下，它有两个主要缺点：</p><ul><li>在许多情况下，根本不需要这样做。如果操作得当，极少会发生冲突。当然，冲突也会发生，但只占系统操作的一小部分。</li><li>锁定的前提是您真的需要这样做。如果您只是想要呈现一个网页，可以获取一些略微过时但一致的值，即使系统知道这些值即刻会发生变化也没关系。读取操作并不总是需要等到正在进行的写入操作完成。</li></ul><p>借助 Elasticsearch 的版本控制系统，可以轻松地使用另一种模式，即乐观锁定。不需要每次都获取锁，而是让 Elasticsearch 知道您希望找到哪个版本的文档。如果文档在此期间没有发生变化，则操作成功，不会锁定。如果文档中的某些内容发生了变化，有了更新的版本，Elasticsearch 会向您发出信号，让您适当地进行处理。</p><p>回到上面的搜索引擎投票示例，来看看它的工作原理。当我们呈现一个关于衬衫设计的页面时，会记下文档的当前版本。这会随我们对页面发起的 get 请求的响应一起返回：</p><pre class="programlisting prettyprint lang-js">curl -XGET 'http://localhost:9200/designs/shirt/1'<br/>{<br/>   "_index": "designs",<br/>   "_type": "shirt",<br/>   "_id": "1",<br/>   "_version": 4,<br/>   "exists": true,<br/>   "_source": {<br/>      "name": "elasticsearch",<br/>      "votes": 1002<br/>   }<br/>}<br/></pre><p>在用户投票后，如果在此期间没有发生任何更改，我们可以指示 Elasticsearch 仅索引新值 (1003)：（注意额外的 version 查询字符串参数）</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1?version=4' -d'<br/>{<br/>    "name": "elasticsearch",<br/>    "votes": 1003<br/>}'<br/></pre><p>在内部，Elasticsearch 要做的是比较两个版本号。这比获取锁和释放锁要简单很多。如果没有人更改文档，操作将成功，状态代码为 200 OK。不过，如果有人更改了文档（导致内部版本号增大），操作将失败，状态代码为 409 Conflict。现在，我们的网站可以做出正确的响应。它会检索新文档，增加投票数，然后使用新版本值重试。这很有可能会成功。如果不成功，我们只需要重复执行上述过程。</p><p>这种模式非常常见，Elasticsearch 的 更新终端都可以为您执行此操作。您可以设置 retry_on_conflict 参数，让它在版本发生冲突的情况下重试操作。在与脚本更新结合使用时，尤其方便。例如，下面这个 cURL 将告诉 Elasticsearch 在失败之前尝试更新文档最多 5 次：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/_update?retry_on_conflict=5' -d'<br/>{<br/>   "script" : "ctx._source.votes += 1"<br/>}'<br/></pre><p>请注意，版本控制检查是一个完全可选的功能。您可以选择在更新某些字段（比如 votes）时强制执行版本控制，而在更新其他字段（通常是文本字段，比如 name）时忽略版本控制。这完全取决于应用程序的需求和您的权衡。</p><h2>已经有版本控制系统了吗？</h2><p>除了内部支持外，Elasticsearch 还可以很好地与其他系统维护的文档版本配合使用。例如，您可能将数据存储在另一个数据库中，它会为您维护版本控制，或者可能有一些应用程序特定的逻辑来决定版本控制的行为方式。在这种情况下，您仍然可以使用 Elasticsearch 的版本控制支持，指示它使用 external 版本类型。Elasticsearch 可以与任何数值的版本控制系统（1:2<sup>63</sup>-1 范围内）配合使用，前提是保证每次对文档进行更改时，版本号的数值都会增大。</p><p>若要让 Elasticssearch 使用外部版本控制，请在 <em>每个</em>更改数据的请求中添加 version_type 参数和 version 参数。例如：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1?version=526&amp;version_type=external' -d'<br/>{<br/>    "name": "elasticsearch",<br/>    "votes": 1003<br/>}'<br/></pre><p>在其他平台维护版本控制意味着 Elasticsearch 不一定知道其中的每一次更改。这对版本控制的实现有细微的影响。</p><p>我们来看看上面的索引命令。使用 internal 版本控制，意味着“仅在文档的当前版本等于 526 时，才会对该文档更新进行索引”。如果版本匹配，Elasticsearch 会将版本号增加 1，并存储该文档。但是，如果使用外部版本控制系统，就无法强制执行此要求。版本控制系统可能并不是每次都递增 1。它或许会使用任意数字跳级增加（想想基于时间的版本控制）。或者，可能很难将每一次版本变更都传达给 Elasticsearch。鉴于所有这些原因，external 版本控制支持的行为会略有不同。</p><p>将 version_type 设置为 external 后，Elasticsearch 将按照指定的版本号存储，不会递增版本号。此外，Elasticsearch 不会检查是否完全匹配，只会在当前存储的版本大于或等于索引命令中的版本时返回版本冲突错误。这实际上意味着“只有在没有其他人同时提供相同或更新版本的情况下，才会存储此信息”。具体来说，如果存储的版本号小于 526，上述请求就会成功。如果大于或等于 526，将导致请求失败。</p><p><strong>重要提示：</strong>使用 external 版本控制时，请确保始终将当前 version（和 version_type）添加到任何索引、更新或删除调用中。如果您忘记这样做，Elasticsearch 将使用它的内部系统来处理该请求，这会导致错误地递增版本号。</p><h2>最后关于删除的一些内容。</h2><p>删除数据可能会导致版本控制系统出现问题。一旦删除了数据，系统就无法正确地知道新请求是否已经过期，或者是否实际上包含了新信息。例如，假设我们运行以下代码来删除一条记录：</p><pre class="programlisting prettyprint lang-js">curl -XDELETE 'http://localhost:9200/designs/shirt/1?version=1000&amp;version_type=external'<br/></pre><p>这个删除操作是文档的第 1000 个版本。如果我们将知道的所有信息都删除，未同步的后续请求就会出错：</p><pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/?version=999&amp;version_type=external' -d'<br/>{<br/>    "name": "elasticsearch",<br/>    "votes": 3001<br/>}'<br/></pre><p>如果我们忘记了该文档曾经存在过，就会接受这个调用，并创建一个新文档。但是，实际上，该操作的版本 (999) 指示这是旧版本，应继续删除该文档。</p><p>您可能会说，这很简单，并不是真的删除所有内容，而是要记住删除操作、它们所引用的文档 ID 及其版本。虽然这确实解决了这个问题，但也有代价。如果有人重复执行索引文档再删除文档的操作，资源很快就会耗尽。</p><p>Elasticsearch 搜索在两者之间实现了平衡。它会保留删除记录，但一分钟后就会忘记这些记录。这就是删除垃圾收集。对于大多数实际用例来说，60 秒足以让系统跟上进度，并让延迟的请求到达。如果您认为不够，可以进行更改，将索引的 index.gc_deletes 设置为其他时间范围。</p>

Elasticsearch Versioning Support

Elasticsearch 版本控制支持

<table style="background-image: initial;background-position-x: initial;background-position-y: initial;background-size: initial;background-repeat-x: initial;background-repeat-y: initial;background-attachment: initial;background-origin: initial;background-clip: initial;background-color: rgb(255, 255, 210);">
    <tbody>
      <tr>
        <td>编者按：&nbsp;这篇文章包含过时的信息。请参考<a href="/guide/index.html" target="_self">我们的文档</a>、<a href="/cn/blog" target="_self">我们最新的博文</a>和<a href="https://discuss.elastic.co" target="_self">我们的论坛</a>，了解最新和最棒的解决方案。谢谢。</td>
      </tr>
    </tbody>
  </table>
  <p>Elasticsearch 中的索引究竟是什么？尽管这是一个非常基础的问题，但答案却出人意料的细致入微。</p>
  <h3>基本定义</h3>
  <p>索引的<a href="/guide/en/elasticsearch/reference/current/glossary.html#index" target="_self">定义</a>如下：</p>
  <blockquote>索引就像关系型数据库中的“数据库”。它有一个映射，可以定义多种类型。<br />一个索引就是一个逻辑命名空间，可映射到一个或多个主分片，并且可以有零个或多个副本分片。</blockquote>
  <p>对了。这个定义包含两个概念。首先，索引是某种类型的数据组织机制，允许用户以某种方式对数据进行分区。第二个概念与副本和分片有关，这是 Elasticsearch 用于在集群中分发数据的机制。</p>
  <p>下面我们先来看第一个概念：使用索引来组织数据。</p>
  <h2>关系索引</h2>
  <p>下面这种最简单、最熟悉的布局克隆了您期望从关系型数据库中获得的内容。您可以（非常粗略地）将索引想象成数据库。</p>
  <ul>
    <li>MySQL => 数据库 => 表 => 列/行</li>
    <li>Elasticsearch => 索引 => 类型 => 带有属性的文档</li>
  </ul>
  <p>一个 Elasticsearch 集群可以包含多个索引（数据库），而这些索引又包含多个类型（表）。这些类型包含多个文档（行），并且每个文档都具有属性（列）。</p>
  <p>比如，在汽车制造业场景中，您可能有一个 SubaruFactory 索引。在这个索引中，有三种不同的类型：</p>
  <ul>
    <li>People</li>
    <li>Cars</li>
    <li>Spare_Parts</li>
  </ul>
  <p>然后，每个类型都包含与该类型对应的文档（例如，Subaru Imprezza 文档位于 Cars 类型中。这个文档包含了关于那辆车的所有详细信息）。</p>
  <p>搜索和查询采用以下格式：http://localhost:9200/[index]/[type]/[operation]</p>
  <p>因此，要检索 Subaru 文档，我可以执行以下代码：<br /></p><pre class="prettyprint lang-bash"><strong>$ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza<br/></strong><br/></pre>
  <h2>日志索引</h2>
  <p>现在，实际情况是，索引/类型比我们习惯在 RDBM 中使用的数据库/表抽象概念灵活得多。您可以把它看成实用的数据组织机制，而且性能优势更大，具体取决于您设置数据的方式。</p>
  <p>为了展示一种截然不同的方法，很多人使用 Elasticsearch 进行日志记录。标准格式是为每一天分配一个新的索引。您的索引列表可能如下所示：</p>
  <ul>
    <li>logs-2013-02-22</li>
    <li>logs-2013-02-21</li>
    <li>logs-2013-02-20</li>
  </ul>
  <p>Elasticsearch 允许您同时查询多个索引，因此执行以下操作并不成问题：</p><pre class="prettyprint lang-bash"><strong>$ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search?query="q:Error Message"<br/></strong><br/></pre>
  <p>这样可以同时搜索最近两天的日志。鉴于日志的性质（大多数日志从来不会有人查看，组织形式采用线性时间流），这种格式优势很大。为每个日志编制一个索引更符合逻辑，并且可提供更好的搜索性能。</p>
  <p>它类似于按时间范围对 RDBM 表进行分区，只是我们要为每个分区创建新的索引。这是一个会被 RDBM 嘲笑的概念，每天创建一个新的数据库？太疯狂了！</p>
  <p>索引是相当轻量级的数据组织机制，因此 Elasticsearch 很乐意让您创建数百个索引。</p>
  <h2>用户索引</h2>
  <p>另一种截然不同的方法是，为每个用户创建一个索引。假设您有一个社交网站，其中每个用户都有大量的随机数据。您可以为每个用户创建一个索引。网站结构可能如下所示：</p>
  <ul>
    <li>Zach 的索引<ul>
        <li>Hobbies 类型</li>
        <li>Friends 类型</li>
        <li>Pictures 类型</li>
      </ul>
    </li>
    <li>Fred 的索引<ul>
        <li>Hobbies 类型</li>
        <li>Friends 类型</li>
        <li>Pictures 类型</li>
      </ul>
    </li>
  </ul>
  <p>请注意，采用传统的 RDBM 方式如何轻松完成这种设置（例如，“用户”索引，包含 hobbies/friends/pictures 类型）。然后，将所有用户编入一个单一的巨大的索引中。</p>
  <p>但出于数据组织和性能考虑，有时需要对数据进行拆分。在这个场景中，我们假设每个用户都有<em>大量</em>数据，而且我们希望这些数据是分开的。这时，我们就可以使用 Elasticsearch 为每个用户创建一个索引。</p>
  <h3>数据分布索引</h3>
  <p>前三个示例讲的都是应如何在逻辑上将数据分开，从而实现自然有效地表示。</p>
  <p>但是，索引的定义还包括关于分片和副本的部分。在所有索引、类型和文档的下面，Elasticsearch 必须将数据存储在<em>某个地方</em>。这个功能存储在分片（主分片或副本分片）中。</p>
  <p>每个索引都是为一定数量的主分片和副本分片配置的。因此，以上面的“用户”为例，如果您为每个用户创建了一个索引，那么您也要为每个用户创建一组分片。</p>
  <p>这无所谓好坏，只是在规划集群时要考虑的一个问题。不同的分片布局有利于不同的性能要求。我有意把这一节写得很短，因为要真正介绍分片需要一篇单独的文章。</p>
  <p>请记住，索引不仅从逻辑上组织数据，而且还可以通过底层分片以物理方式组织数据。</p>

What is an Elasticsearch Index?

Elasticsearch 索引是什么？

Elasticsearch Platform

ELK Stack

Elastic Cloud

可观测性

安全性

搜索

按行业

按解决方案

客户聚焦

开发人员

保持联系

学习

帮助

了解 Elastic 的最新动态

<

2013

<

september

自下而上认识 Elasticsearch：第 1 部分

把 Elasticsearch 用作 NoSQL 数据库

关注我们

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖