2014-11-05 58 views
2

我正在构建可从ElasticSearch中受益匪浅的应用程序。在我目前的版本中,我使用1个单一索引:只有1种类型的“消息”:“消息”。为相同数据弹性搜索一个索引或多个索引

消息由以下格式(平均10KB)的:

messages 
- id 
- subject (string) 
- date (date) (format: dateOptionalTime) 
- account_id (integer) 
- body (string) 
- receivers (nested) 
    properties: 
     name (string) 
     email (string) 
- files (nested) 
    properties: 
     content_type (string) 
     filename (string) 
     size (long) 

搜索当前的ACCOUNT_ID基础上(添加过滤器,以每个查询)。在我的mySQL数据库中,每个账户都有一个company_id(一个公司可以有多个账户)。将来,我可能愿意允许用户在公司范围内进行搜索,而不是在一个帐户中进行搜索。我的数据集是一个很大(> 50米的文件)。

我的问题是什么是最好的,只是使用单一类型(消息)这个单一的索引(消息),或者做一个公司范围内的索引,我会为每个公司创建一个新的索引像messages_%company_id%)。

我的数据集每月增长1 - 5M个文档,文档几乎不需要删除。旧数据在这里可以像新插入的文档一样有价值。

回答

1

我会坚持使用单一索引和单一类型。

ES“索引”类似于SQL“数据库”。 ES“类型”类似于SQL“表”。你会为单独的公司创建单独的数据库还是单独的表格?可能不会。

ES非常好地缩放,并且可以很容易地通过任何类型的内容进行搜索。只要给ES提供必要的硬件,50M文档就不会有问题。

另外一个注意事项:如果有什么诱惑让ES成为您的唯一数据存储,我会抵制它。我认为它还没有到位。保持MySQL数据库为“权威”存储引擎,并使用ES进行搜索。

+0

目前我是mySQL作为我的主数据存储,S3文档的一些(重要的)元数据位于其中,其余的位于S3的原始文件中。所以ES确实为我提供了搜索功能,但我总是能够通过mySQL和S3完全重建/恢复。 – Floris 2014-11-06 07:27:25

+0

是的,只要你能够从MySQL + S3重建,你应该没问题! – yahermann 2014-11-06 15:35:15

+0

所以我不能获得更好的性能或更少的资源,如果我创建像多个索引和/或类型。 – Floris 2014-11-06 17:58:41