关系型数据库与 Elasticsearch 组合使用要点

关系型数据库局限性

 1.关系型数据库支持有限度的关联查询,一般在业务应用系统中,关联表会控制在 2~3 个表(有 3 个表关联的业务场景需要评估是否容许,开发工程师只容许 2 个表关联),且单表的数据量要平衡考虑,跨同构数据库源关联不容许,而跨异构数据库源更是有心无力。

2. 关系型数据库虽然支持主从同步,支持读写分离,但集群是一种松散式的架构,集群节点感知能力脆弱,不成体系,弹性扩展能力不行。

ES互补性

1. ES默认为所有字段创建索引,任意索引字段可组合使用,且查询效率相当高。业务系统中有很多场景都需要这种任意字段组合查询的能力,简称通用搜索 。

2. ES的数据模型采用 Free Scheme 模式,以 JSON 主体,数据字段可以灵活添加,字段层级位置也可灵活设置 ,关系数据库中需要多表关联查询,在 ES 中可以通过反范式的关联能力,将多个业务表数据合并到一个索引中,采用对象嵌套的方式。

3. Elasticsearch 的索引支持弹性搜索,可以指定一个索引搜索,也可以指定多个索引搜索,搜索结果由 ES 提供过滤合并,为业务系统提供灵活的操作空间,特别是在实时数据与历史数据方面,统一查询条件语法皆可执行。

4. Elasticsearch 支持数据字段与索引字段分离,默认情况下,数据字段与索引字段是同时启用,实际业务场景中,数据表中很多字段无需检索,只是为了存储数据,在查询时方便取回;很多检索字段也无需存储原始数据,只是检索过滤使用。

业务层考虑

 即使采用单业务领域水平分库分表和多业务领域垂直分库分表机制,包括物理层面分库分表,逻辑层面分区等,解决了数据的存储问题,但需要做合并查询不易,业务系统的查询条件一般是动态的,无法固定,更加不可能在分库分表时按照所有动态条件设计。所以需要结合 Elasticsearch,所以

 1. 业务数据存储由关系型数据库负责,有强事务隔离机制,保障数据不丢失、不串乱、不覆盖,实时可靠。

 2. 业务数据查询由 Elasticsearch 负责,分库分表的数据合并同步到 ES 索引;跨领域库表数据合并同步到 ES 索引,这样就可以高效查询。 

组合场景下的业务场景数据模型映射分为以下几种:

单数据表->单索引

一对一映射关系,关系数据库有多少个表,Elasticsearch 就有多少个索引;

关系数据库解决一致性,提供原始数据源,Elasticsearch 替代数据库成为查询引擎,替代列表查询场景,解决查询性能;

单数据表为水平分库分表设计,需要借助Elasticsearch 合并查询;

单数据表业务查询组合条件多,数据库索引查询能力局限,需要借助 Elasticsearch 全字段索引查询能力 

单数据表->多索引

1.一对多映射关系,单数据表映射到多个索引中;

2.单数据表即作为 A索引的主体对象,一对一映射;

3.单数据表也作为 B索引的子对象,嵌入到主体对象下面;

   基于微服务架构设计,在业务系统中,业务系统划分多个子领域,子领域也可以继续细分,如电商行业,订单领域与商品领域,订单表需要映射到订单索引,也需要与商品索引映射,解决DB的关联查询能力瓶颈和DB索引查询能力限制。

多数据表->单索引

1.多个DB表一个索引,多对一映射关系,多个数据表映射到单一索引,索引可以采用宽表结构,也可以采用子对象映射方式;

2.单业务领域,数据表设计时一般会遵循数据库范式,即使是反范式设计,也只会增加些许冗余,如果要多表联合查询,数据库表的关联效率很低,甚至是运行不起来,需要借助 Elasticsearch 合并多个数据表到一个索引中;

3. 跨业务领域的数据表要联合查询,也需要借助 Elasticsearch 整合,提供通用查询能力。

多数据表->多索引

1. 多个DB表多个索引,多对多映射关系,多个数据表映射到多个索引,复杂度高;

2. 一个中型以上的业务系统,会划分成多个领域,单领域会持续细分为多个子领域,领域之间会形成网状关系,业务数据相互关联;

3. 数据库表关联查询效率低,跨库查询能力局限,需要借助 Elasticsearch 合并;

4. 按照领域需求不同,合并为不同的索引文件,各索引应用会有差异,部分是通用型的,面向多个领域公用;部分是特殊型的,面向单个领域专用。

多源数据表->多索引


1.多源多表,多对多映射关系,数据表与索引之间的映射关系是交叉型的,复杂度最高;

2.一个大中型业务系统,不同的业务场景会采用不同的数据存储系统;关系型数据库多样化,如 A项目采用 MySQL,B项目采用 PostgreSQL,C 项目选用 SQLServer,业务系统通用型的查询几乎不能实现;非关系型数据库多样化,如 A项目采用键值类型的 Redis,B项目选用文档型的 MongoDB,业务系统同样也不能实现通用型查询;

基于异构数据源通用查询的场景需求,同样需要借助 Elasticsearch 合并数据实现。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,496评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,407评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,632评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,180评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,198评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,165评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,052评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,910评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,324评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,542评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,711评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,424评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,017评论 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,668评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,823评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,722评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,611评论 2 353