如果我是正确的，crate (crate.io)是由Elasticsearch (Lucene)支持的。一个月前不是有几篇文章说ES在高负载下丢失了一些写操作吗?还有其他问题吗?
你是对的，Crate是由Elasticsearch支持的。我们认为elasticsearch在提高数据一致性方面做得很好。一个很好的阅读是http://www.elasticsearch.org/blog/resiliency-elasticsearch/，它提供了一个关于可靠性努力的很好的概述。我们Crate相信这个存储引擎作为主存储是安全的。我们还看到，Lucene和Elasticsearch社区正在积极地解决这方面的问题。
我目前正在评估Crate。IO作为工作的主数据存储。由于上面的答案是模糊和不具体的，也许是时候更新一下这个问题了。2016年12月，Youtube上有一个Jepsen作者Kyle Kingsbury的主题演讲，他调查了Crate。针对Elasticsearch中弹性的一些问题。前8分钟是关于Crate的介绍。IO部分从23:50到31:10。
对于那些不想看完整视频的人，这里有一个简短的总结。首先，测试设置。他们建立了数据库，并随机设置了客户端查询模式。此外，他们还主动为数据库引入了一些问题，比如网络分区。其次，结果。根据Kingsbury的说法，ES的弹性有两个问题。他们都继承了create .io。让我们讨论细节吧……
<标题>脏读第一个问题——es# 20031——如果发生网络分区，ES可能会导致脏读、散列和更新丢失。截至2017年12月，这个问题仍然悬而未决。在我看来，如果一个节点对非常繁重的任务没有响应，比如在广泛的查询、重新索引或垃圾收集期间，也可能发生同样的问题。
<标题>丢失更新根据Kingsbury的说法，ES还有另一个问题("可能导致过时的二进制文件")，当网络分区发生时，会导致更新完全丢失。它被标记为#20384，有一种修复，金斯伯里总结为"部分"。因此，ES仍然可能在写入时导致数据丢失。
ES怎么说?
在ES关于弹性的官方网站上，只提到了两个问题中的一个——#20384。在5.0版本发布说明中，该问题已被标记为已解决，尽管官方网站表示只有部分修复。
Crate。io说什么?
在箱子上。在关于弹性的io文档中，有一个关于Crate的已知问题列表。io弹性。ES错误#20384被注释为部分修复，但仍然导致一个开放的问题。没有提到ES错误#20031。然而，有一段关于网络分区的问题，其中Crate。IO标记为固定的-所以官方页面在这里有点不确定。
结论Kingsbury在2016年12月得出结论，Crate。IO不应该用作主数据存储。当然，它可以用来复制您的主要数据，以受益于Crate的时间序列数据库特性。io提供。他还建议，对于5%的数据丢失不是严重问题的机器数据，可以使用Crate。IO作为主存储是一个可行的选择。我的印象是Kingsbury报告的一些bug可能已经修复了，但不是全部。