版权声明 本站原创文章 由 萌叔 发表
转载请注明 萌叔 | http://vearne.cc

1. 前言

之所以写这篇文章是因为我已经在不止一个群里,看到有人问如何在ES中存储关联关系。

2. 答案

你可能会在网上看到有说Join datatypeNested data type的,但是其实这都不是ES该有的玩法。

  • Join datatypeNested data type都会涉及多次查询的开销
  • Join datatype本身的数据就是在不同的表中,对于分布式数据库,还涉及数据从不同的节点上拉取和组装的开销。

那么应该怎么做?答案就是用冗余的宽表来存储关联关系

举例说明

假如我需要在ES中存储的实体有书籍、书籍有作者信息、书名等等信息,显然实体之间有如下关系

如果在传统的关系型数据库中,就需要创建2张表,一张表表示作者,一张表代表书。但是对于nosql数据库,只需要一张表(书)即可,doc结构形如:

{
    "name":"zhangsan",
    "publisher_identifier": "xxx-xxxx-xxx"
    "author":{
        "name": "jobs",
        "phone": "111111111"
    }
}

作者信息作为书的属性存储在一起,放一个doc中即可。
这样的做法必然是会带来数据冗余,但是以空间换时间,查询速度就有了保障。

现代的nosql数据库大多应对的海量数据的存储查询的问题,因此大都是分布式结构。在这种情况下,整体的设计方案必须足够简单,才能够易于维护和扩展。同样的做法,也完全适用于HBase。

3. 说几句某些人可能不爱听的话

  • ES集群的使用成本其实是很贵的,用了就别怕贵,觉得烧钱就别用
  • ES自身的性能优化工作做得还是很好的,对大多数人而言,不需要考虑优化,性能不够,就老老实实的加硬件就行。高版本相比低版本性能和稳定性都有很大的提升,优先考虑高版本
  • SSD对ES的性能提升非常明显(便宜不一定不是好货,但好货一定不便宜)

4. 参考资料

1.Join datatype
2.Nested data type
3.宽表和窄表的区别


打赏我

微信支付码

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据