ElasticSearch + Cassandra 的实际限制答案

【问题标题】：Practical Limits of ElasticSearch + CassandraElasticSearch + Cassandra 的实际限制
【发布时间】：2011-06-15 14:31:35
【问题描述】：

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

【问题讨论】：

标签： cassandra elasticsearch limits

【解决方案1】：

参见 2011 年的 this thread，其中提到了 ElasticSearch 配置，每个 200GB 有 1700 个分片，在 1/3 PB 范围内。我希望 ElasticSearch 的架构能够支持几乎无限的水平可扩展性，因为每个分片索引都独立于所有其他分片工作。

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

【讨论】：

感谢 DNA 的回复。这很有帮助。

【解决方案2】：

Sonian 是 kimchy 在该线程中提到的公司。我们在 AWS 上跨多个 ES 集群拥有超过 PB 的数据。 ES 的水平扩展范围没有技术限制，但正如 DNA 所述，存在实际问题。迄今为止最大的是网络。它适用于每个分布式数据存储。你一次只能在电线上移动这么多。当 ES 必须从故障中恢复时，它必须移动数据。最好的选择是在更多的节点上使用更小的分片（更多的并发传输），但是你会冒更高的失败率和高昂的每字节成本。

【讨论】：

【解决方案3】：

正如 DNA 提到的，1700 个分片，但不是 1700 个分片，而是有 1700 个索引，每个索引有 1 个分片和 1 个副本。因此，这 1700 个索引很可能不会出现在单台机器上，而是分散在多台机器上。所以这从来都不是问题

【讨论】：

【解决方案4】：

我目前开始使用 Elisandra (Elasticsearch + Cassandra)

我也遇到了用 elasticsearch 索引 Cassandra 的问题。我的问题基本上是节点配置。

做$ nodetool status你可以看到Host ID然后毁了：

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

您可以检查node: 之一是否与Host ID 同名

【讨论】：

这不是答案