背景：我有大量的数据流 - 每小时最多可获得1000000条记录，ttl为3小时......每个“文档”包含大约20个属性，我需要使用“==”同时搜索多达15个属性，“IN”和“BETWEEN”比较。
由于几乎没有不可搜索的属性，因此没有理由将文档存储两次（在Couchbase和ElasticSearch索引中），所以我认为将它存储在ElasticSearch中是个好主意。我是正确的？
或者有人可以推荐我更好的数据库来完成这样的任务？我将来需要一个简单的水平扩展（MySQL的自定义分片不是一个选项）...这个数据是某种缓存所以最终的一致性和差的耐久性是可以的...
根据CAP定理，我主要需要A和P ......
关于性能，如果您使用适当大小的硬件，则不应该每小时索引1M文档。我运行的Elasticsearch远远超过了它，没有任何问题。这里有一个详细的文章，您可能会发现有关基准测试和调整大型Elasticsearch集群的大小有用：
ElasticSearch setup for a large cluster with heavy aggregations
对于TTL仅为3小时的短暂缓存系统，我同意将数据存储在多个存储库中是浪费。您可以将数据存储在Couchbase中并实时或接近实时地将其复制到Elasticsearch中，但为什么还要烦恼呢？不确定在两个地方获得数据会带来什么好处。
对于与您的特定用例有关的性能问题，我强烈建议您进行基准测试。我发现Elasticsearch（以及Solr）的一个优势是，在搜索多个非文本字段时，他们（对我而言）的性能出乎意料地强劲。您倾向于将ES视为文本搜索目的（它确实擅长），但它也是一个不错的通用数据库。我发现，与其他一些NoSQL解决方案相比，它在搜索多个参数时具有很强的性能。
就个人而言，在这个用例中对ES进行基准测试时，我会看一些不同的索引选项。 ES支持文档的TTL，因此可以轻松自动清除缓存：
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html
但是，您可能希望每小时都有不同的索引 - 关于ES的一件事（由于它使用Lucene进行索引和文件存储），删除工作的方式与大多数数据库不同。文档被标记为已删除但未被删除，然后将定期合并下面的文件（称为段），此时将创建新段而不删除已删除的文档。对于单个索引中的大量删除大量用例，这可能会导致相当数量的磁盘活动。解决这个问题的方法是为每小时创建一个新索引，然后在其中的数据超过3个小时之后完整地删除索引。
您可能会发现之前关于Elasticsearch中TTL与时间序列索引的讨论很有用：Performance issues using Elasticsearch as a time window storage
最后，关于简单的水平扩展，Elasticsearch在这里非常好 - 您添加了一个具有正确集群名称的新节点，ES负责其余部分，自动将分片迁移到新节点。在您的用例中，您可能希望使用复制因子，因为更多节点上的更多副本是提高查询性能的简便方法。
对于缓存（类缓存系统）的用例，我认为Elasticsearch将来只会给你带来问题。我假设您根本不需要索引，因为您没有查看类似搜索的功能。
我没有使用过Couchbase，但我听说过它的好消息。我听说过使用Couchbase进行更多过滤的用例和Elasticsearch用于更多搜索目的（以及Couchbase无法做到的事情）。
对于可伸缩性，据我所知，从非常高的角度来看，两者看起来相似。当群集中的节点出现故障时，两者都支持轻松分片和复制，并重新平衡分片和辅助副本升级到主分片。细节可能不同。
但说实话，你必须自己尝试一下，然后像流量一样进行测试。我曾与Elasticsearch合作，我知道你不能总是说它是否是你的用例的正确选择，因为它在生产中对于应用程序的行为方式可能因其在性能方面的行为而有所不同。
但我认为你走在正确的轨道上。