我正在搜索有关 ElasticSearch 如何随其索引中的数据量进行扩展的信息，并且很惊讶我在该主题上找不到多少。也许这里人群的一些经验可以帮助我。
我们目前正在使用 CloudSearch 索引 ≈ 700 万份文档；在 CloudSearch 中，这会产生 2 个类型为 m2.xlarge 的实例。我们正在考虑改用 ElasticSearch 以降低成本。但我在 ElasticSearch 的扩展上发现的只是它的扩展性很好，可以分布在多个实例上等。
但是我需要什么样的机器（内存、磁盘）来存储这种数据？
如果我将数据量增加 12 倍（≈ 8000 万份文档），情况会如何变化？
正如贾瓦娜所说，这取决于。主要是：（1）索引率；(2) 文件大小；(3) 搜索的速率和延迟要求；(4) 搜索类型。
考虑到这一点，我们能提供的最好的帮助就是举例。在我们的网站（新闻监控）上，我们：
OR使用很多术语进行查询，这些术语是最难的术语之一。我们还对两个单值字段进行分面。并对日期方面进行一些实验（以显示随着时间的推移的发布率）。我们使用 4 个 EC2 的m1.large实例来完成所有这些工作。现在我们计划迁移到刚刚发布的 ES 0.9 版本，以获得 Lucene 4.0 的所有优点和性能改进。
现在把例子放在一边。ElasticSearch 具有很强的可扩展性。很简单，用N个shards和M个replicas创建索引，然后用ES创建X台机器。它将相应地分配所有分片和副本。您可以随时更改副本数量（针对每个索引）。
一个缺点是您无法在创建索引后更改分片数量。但是您仍然可以事先“过度分片”，以便在需要时为扩展留出空间。或者创建一个具有正确数量的分片的新索引并重新索引所有内容（我们这样做）。
最后，ElasticSearch（以及Solr）在底层使用了 Lucene Search 库，这是一个非常成熟且广为人知的库。
实际上，我最近在我工作的公司从使用 CloudSearch 切换到了托管的 ElasticSearch 服务。我们的特定应用程序有超过 1 亿个文档，并且每天都在增长。到目前为止，我们对 ElasticSearch 的体验绝对是美妙的。搜索性能平均约为 250 毫秒，即使进行了所有排序、过滤和分面。索引文档也相对较快，尽管我们每隔几个小时使用批量 API 通过 HTTP 传输几 MB 的负载。刷新率似乎也接近即时。
对于我们的 ~100M doc / 12GB 索引，我们使用了 4 个分片 / 2 个副本（如果性能下降，将增加到 3 个副本）分布在 4 个节点上。在建立索引之前，我们的团队花了几天时间研究 ElasticSearch 集群部署/维护，并选择使用http://qbox.io来节省金钱和时间。我们非常害怕选择将索引托管在像 Qbox 这样的专用集群上的性能和规模问题，但到目前为止，体验非常棒。
由于我们的索引位于专用集群上，我们无法访问具体的节点级配置设置，因此我在 ES 部署方面的技术专长仍然非常有限。话虽如此，我无法确定我们在指数上所经历的性能究竟需要多少性能周。但是，我知道 Qbox 的集群使用 SSD ......所以这肯定会产生重大影响。
以防万一，ElasticSearch 已经无缝扩展。我强烈推荐切换（即使只是为了节省 $$，CloudSearch 也非常昂贵）。希望这些信息有帮助！
CloudSearch 最近降价了，现在可能比在 EC2 上维护自己的搜索基础设施更便宜 - http://aws.amazon.com/blogs/aws/cloudsearch-price-reduction-plus-features/