ElasticSearch 或 Couchbase 或其他

Question

背景： 我有一个巨大的数据流 - 每小时最多 1000000 条记录，ttl 是 3 小时......每个“文档”包含大约 20 个属性，我需要使用“==”同时搜索多达 15 个属性，“ IN”和“BETWEEN”比较。

由于几乎没有不可搜索的属性，因此没有理由将文档存储两次（在 Couchbase 和 ElasticSearch 索引中），所以我认为只将它存储在 ElasticSearch 中是个好主意。我是对的？

或者也许有人可以推荐我更好的数据库来完成这项任务？我将来需要一个easy水平扩展（MySQL的自定义分片不是一个选项）...... 这些数据是某种缓存，因此最终的一致性和较差的持久性是可以的......

根据 CAP 定理，我主要需要 A 和 P...

Answer 1

关于性能，只要您使用大小合适的硬件，每小时索引 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 会处理其余的工作，自动将分片迁移到新节点。在您的用例中，您可能希望使用复制因子，因为跨更多节点的更多副本是提高查询性能的简单方法。

Answer 2

对于缓存（类似缓存的系统）的用例，我认为 Elasticsearch 只会在未来给你带来问题。我假设您根本不需要索引，因为您没有查看类似搜索的功能。

我没有使用过 Couchbase，但我听说过它的好消息。我听说过一些用例，例如使用 Couchbase 用于更多过滤目的，使用 Elasticsearch 用于更多类似搜索的目的（以及 Couchbase 不能做的事情）。

对于可扩展性，据我所知，从非常高的角度来看，两者看起来很相似。两者都支持简单的分片和复制，当集群中的节点出现故障时，通过重新平衡分片和辅助副本提升到主副本。具体情况可能有所不同。

但老实说，您必须自己尝试一下，并使用流量等生产环境进行测试。我曾与 Elasticsearch 合作过，我知道您不能总是只说它是否是您的用例的正确选择，因为它在生产中的应用程序的行为方式可能与它在性能方面的行为方式不同。

但我认为你在正确的轨道上。