ElasticSearch + Cassandra的实际限制

Question

我打算使用ElasticSearch来索引我的Cassandra数据库。我想知道是否有人看到ElasticSearch的实际限制。事情在PB级范围内变慢了吗？另外，有谁使用ElasticSearch索引Cassandra有任何问题？

Answer 1

请参阅2011年的this thread，其中提到了ElasticSearch配置，每个容量为1700个分片，分辨率为200GB，分辨率为1/3 PB。我期望ElasticSearch的体系结构将支持几乎无限的水平可伸缩性，因为每个分片索引都与所有其他分片分开工作。

实际限制（也适用于任何其他解决方案）包括首先实际加载大量数据所需的时间。管理这种大小的Cassandra集群（或任何其他分布式数据存储）也将涉及很大的工作量，仅用于维护，负载平衡等。

Answer 2

Sonian是该公司kimchy在该主题中的暗示。我们跨多个ES群集在AWS上拥有超过1 PB的性能。 ES的水平伸展距离没有技术限制，但正如DNA提到的那样存在实际问题。目前最大的是网络。它适用于每个分布式数据存储。你一次只能在电线上移动很多东西。当ES必须从故障中恢复时，必须移动数据。最好的选择是在更多的节点上使用更小的分片（更多并发传输），但是你有更高的失败率和更高的每字节成本风险。

Answer 3

提到DNA DNA，1700个碎片，但它不是1700个碎片，但有1700个索引，每个碎片有1个碎片和1个副本。所以很有可能这1700个指数不是在单机上存在，而是在多台机器上分开。 因此，这是从来没有一个问题

Answer 4

我现在开始Elisandra（Elasticsearch +卡桑德拉）工作

我也是，具有elasticsearch问题索引卡桑德拉。我的问题基本上是节点配置。

做$ nodetool status你可以看到Host ID，然后破坏：

curl -XGET http://localhost:9200/_cluster/state/?pretty=true

您可以检查node:的一个是相同的名称作为Host ID