问题描述
我有一个应用程序，该应用程序在不同的线程上接收事件，每个事件都经过处理，格式化为不同的属性，然后保存到ElasticSearch中.当一个特定的属性值首次出现在任何事件上时，我想在数据库中添加一个新条目(每个事件读取所有先前的事件并验证该值尚未出现).由于应用程序的多线程性质，我需要某种方式来验证我是在第一次遇到该属性时添加条目的，并且只有一次.我想到的最好的解决方案是某种乐观锁定(确保在我提交该属性之前，没有其他线程为此属性添加条目).对此是否有任何ElasticSearch支持?
I have an application that receives events on different threads, each event is processed, formatted into different attributes, and saved into ElasticSearch. I would like to add a new entry in my DB when a specific attribute value first appears on any event (each event reads all previous events and verifies the value did not yet appear).Due to the multithreaded nature of the application i need some way of validating that I am adding the entry when i first encounter the attribute, and only the once. The best solution that comes to my mind is some kind of optimistic locking (making sure no other thread has added an entry for this attribute before i commit it).Is there any ElasticSearch support for this?
推荐答案
是的，Elasticsearch提供了处理冲突的支持，您可以阅读官方的Elasticsearch "> https://www.elastic.co/guide/en/elasticsearch/guide/master/version-control.html 详细解释此问题的文档.
Yes, Elasticsearch provides supports for dealing with conflicts, And you can read the official Elasticsearch https://www.elastic.co/guide/en/elasticsearch/guide/master/version-control.html docs which explain this in details.
如果我们不能正确处理冲突，则可能导致丢失更新问题以及如何处理这些问题，下面将对此进行解释
If we don't deal properly with conflicts then, it can lead to lost update problem and how to deal with them explained below
在数据库世界中，通常使用两种方法来确保在进行并发更新时不会丢失更改:
悲观并发控制:关系数据库广泛使用此方法，该方法假定可能发生冲突的更改，因此阻止对资源的访问以防止冲突.一个典型的示例是在读取一行数据之前将其锁定，以确保只有放置锁的线程才可以更改该行中的数据.
Pessimistic concurrency control: Widely used by relational databases, this approach assumes that conflicting changes are likely to happen and so blocks access to a resource in order to prevent conflicts. A typical example is locking a row before reading its data, ensuring that only the thread that placed the lock is able to make changes to the data in that row.
乐观并发控制，此方法由Elasticsearch使用，它假定冲突不太可能发生，并且不会阻止尝试操作.但是，如果在读写之间修改了基础数据，则更新将失败.然后由应用程序决定如何解决冲突.例如，它可以使用新数据重新尝试更新，或者可以将情况报告给用户.
Optimistic concurrency control Used by Elasticsearch, this approach assumes that conflicts are unlikely to happen and doesn’t block operations from being attempted. However, if the underlying data has been modified between reading and writing, the update will fail. It is then up to the application to decide how it should resolve the conflict. For instance, it could reattempt the update, using the fresh data, or it could report the situation to the user.
对您来说好消息是Elasticsearch支持开放式锁定，因此不会锁定所有文档并提供更好的性能.您可以阅读其官方文档 https://www.elastic.co/guide/zh-CN/elasticsearch/guide/master/optimistic-concurrency-control.html 关于如何实现这一目标.
Good news for you is that Elasticsearch supports optimistic locking hence doesn't lock all the documents and provides a better performance, You can read their official doc https://www.elastic.co/guide/en/elasticsearch/guide/master/optimistic-concurrency-control.html on how to achieve that.
让我知道您是否清楚并有任何疑问.
Let me know if it's clear to you and have any doubts.
这篇关于Elasticsearch乐观锁定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！