performance - Elasticsearch:为每个用户的私有(private)搜索选择索引策略

标签 performance elasticsearch sharding elasticsearch-indices

例如,我有 1000 个用户。每个用户的数据量不大,最大1GB。所以我有 2 个索引策略。

  • 大索引:我将有一个索引。然后每次用户搜索一些数据时,我都会在查询中添加一个user_id
  • 小型索引:每个用户都是一个 Elasticsearch 索引。因为数据不大,我们只需要1-2个分片。

我认为第二种方法要快得多,因为我们不需要将 user_id 添加到查询中。第一种方法可能会比较慢,因为它会转到许多分片,同时,它必须将 user_id 计入查询。

但是,有一些ref1 ref2他们建议我们应该保持分片总数相对较小。

在实际环境中,我的情况有什么好的解决方案?

最佳答案

为每个用户创建一个索引是一种资源浪费,尤其是当您有 1000 多个用户时。如果您的应用程序成功并且您的用户群增长,那么索引的数量和分片的数量也会随之增长。即使每个索引一个分片,拥有 1000 个分片也已经耗尽了大量资源。

拥有一个索引并使用 user_id 字段将所有用户放入其中以区分每个用户的数据会更有效。

关于performance - Elasticsearch:为每个用户的私有(private)搜索选择索引策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60488568/

相关文章:

ruby-on-rails - MongoDB 中的受控数据分片

postgresql - Ruby on Rails 4/ActiveRecord 上大表的更好实践

mysql 分片案例研究链接或论文

javascript - 建议避免 save() restore() 吗? (JavaScript)

performance - Delphi - 如果用户仍在输入则延迟处理

java - Elasticsearch Java 客户端 : can't connect to the remote server

mapping - Elasticsearch - 跨多种类型的搜索效率

elasticsearch - ElasticSearch 是否支持 Unicode/Chinese?

java - 在java中创建昂贵的对象

r - 使用另一个多边形裁剪/剪辑复杂的 SpatialPolygonsDataFrame 的最快方法