ElasticSearch或Couchbase或其他东西

关于性能,如果您使用适当大小的硬件,则不应该每小时索引1M文档.我运行Elasticsearch远远超过了它,没有任何问题.这里有一个详细的文章,您可能会发现有关基准测试和调整大型Elasticsearch集群的大小有用:

针对具有大量聚合的大型群集的ElasticSearch设置

对于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与时间序列索引的讨论很有用:使用Elasticsearch作为时间窗口存储的性能问题

最后,关于简单的水平扩展,Elasticsearch在这里非常好 - 您添加了一个具有正确集群名称的新节点,ES负责其余部分,自动将分片迁移到新节点.在您的用例中,您可能希望使用复制因子,因为更多节点上的更多副本是提高查询性能的简便方法.