七座城堡⓵ OLTP(上)

梁敬彬梁敬弘兄弟出品

1. 快乐王国的突发事件

在宇宙深处有一个神奇的数据库星球,叫快乐星球,星球上有一个充满活力的王国,国王姓王自称老王,大家也都这么称呼他这个,这个王国就叫快乐王国。

在这里插入图片描述

某天,快乐王国出大事了。主管国家安全事务的老安突然失踪了,连续三天未露面后才被证实他已携巨款潜逃到了国外。老王震惊,亲自带人去档案馆取老安的档案进行调查,结果大家在偌大的档案馆找了许久,才发现其档案也早已不见了,看来老安早有预谋。

在这里插入图片描述

老王怒不可遏,下令彻查此事,命人收集老安经手的所有项目,同时也对和老安有工作交接的所有人员进行逐一调查。由于交接信息均为纸面材料,且又在分散在不同机构,所以调查工作进展缓慢,干系人中的不法之徒也早已闻风而逃。

毕竟老王是一位有智慧的人,他很快冷静下来,在安排人员继续开展调查追捕工作的同时,开始反思为什么会发生这件事。他认为如果能实时了解资金走向、项目进度及人员信息,就不至于巨款被卷、人员出逃都未能及时发现。眼下必须打造出高效的数据收集与项目监控的能力,以避免重蹈覆辙,而这种能力实现的核心即数据库技术。于是老王下令,让科技主管老柯组织整合力量,打造一座数据库城堡,

2. OLTP城堡的诞生

不久,一座名为OLTP城堡的宏伟建筑在快乐王国的土地上拔地而起。所有关键部门人员的个人档案信息、所有国家级关键项目的工程信息、所有公民的个人身份信息等均保存在城堡内,老王得知后大喜过望,在老柯的陪同下对城堡进行了检阅。

老柯在老王面前演示了查询他自己档案信息的过程,一眨眼的功夫,老柯的个人信息就在一个超级大屏前展示出来。老王想起之前在档案馆找安全主管信息时的费劲程度,感到又高兴又惊讶。

在这里插入图片描述

“怎么查这么快,难道数据库城堡中的记录很少吗?” 老王有些不解。

老柯:“老王,这是全国人员的信息库,记录可是数以亿计啊。”

老王:“之前只有重要岗位人员的档案,档案馆里区区几千人的信息就让我们查得那么辛苦,现在这里汇聚了全国数以亿计人员的全部档案,居然可以查的这么快,看来数据库还真是神奇啊!”

3. OLTP操作本就应该很快

老柯:咱们先撇开专业的数据库体系不谈,就在逻辑层面通俗的给您解释解释。数据是以行的形式被存在表中,行则由多列组成,如人员表的每行都包括工号、姓名、性别、收入、年龄、学历等等,如部门表的每行包括编号、名称、负责人等等。

虽说人员表存了数亿的全国人员信息,记录非常多,表很庞大。但此时如果只查我老柯的信息,返回记录是不是就很少了?

老王:是的。

老柯:“如果是分析类操作,如全国人员平均收入、各年龄段就业率等。这需要访问表中大部分甚至全部记录才能找到答案,干的活多了自然就慢。而仅查我的个人信息的交易类操作,则只需要访问表中和我相关的区区几条记录即可找到答案,干的活少自然就快。

老王: 哦,听起来确实如此。

老柯: 这种查询或更新表中少量记录的交易类操作,有一个专业的术语,叫OLTP(Online Transaction Processing),主要就是针对高并发、实时、可靠的交易处理。而我提到访问表中大量记录的分析类操作,也有一个专业术语,叫OLAP(Online Analytical Processing)。
您可以先记一个重要结论:在没有特殊情况下,OLTP操作都应该很快,而OLAP操作则理所当然更慢。

在这里插入图片描述

老王:老柯,我怎么觉得有点不对劲。即便是OLTP操作,如果不把表从头到尾搜个遍,怎么保证不会漏了你要的记录?如果都要全表搜个遍,那只查一条和查所有记录难道不是一样费劲吗?

老柯:居然被您想到这点,厉害啊我的国王!其实问题的焦点已经出来了,即如何确保OLTP只搜索表的局部数据而非全部?

老王:是啊。

老柯: 您有没有想过这样的一个问题,假如数据的存储是有顺序的会怎么样?

老王:哦,我明白你意思了!如果存储是有顺序的,就可以只搜索表的局部数据了。这好比同仓库有规律的存放货物,找货物时就不每个角落都搜寻了。

老柯:您真是善于类比,确实是如此,比如数据按姓名的规律进行有序存储,这样当查询我老柯时,柯的拼音是K开头,如果你搜到拼音是L开头的,就知道接下来永远不会再搜到K开头的数据了,于是停止搜索,从而避免全表找个遍。

老王:“有道理!等等,好像不对啊…

老柯:怎么不对?

老王:比如仓库有序存储货物,或按出厂日期新旧存放,或按价位高低存放,或按照尺寸大小存放,可我们永远只能选择其中一种排序方式啊。如果按出厂日期存储,根据出厂日期找某货物很方便,但是根据价位找某货物就麻烦了,这满足不了多样化需求,数据库难道不是同样道理吗?

老柯:您仅凭逻辑推理就犀利地发现问题,佩服!确实存在这个问题,而且即便就按一种顺序存储方式,且查询需求也只匹配这个存储顺序,还是有问题。

老王:哦,那还能有什么问题?

老柯:货物存储要有序,可进货操作不一定有序,如此一来货仓里为了确保有序,就需要不停的调整货物位置,这不仅影响效率还容易对货物造成损坏,数据库也是如此。

老王:哦,对啊!那怎么办?

老柯:有一个办法,在生产数据之外再引进一种辅助数据结构,把表数据的排序动作转移到辅助数据结构上,同时建立辅助数据和表数据的关联关系。由于只对辅助数据排序,不影响生产数据,就安全高效多了。好比我们不用去一直调整货物位置,货物的各种隐患也就减少了。此外这种辅助数据很灵活,可建多个以适应多样的需求。

老王:我倒是没想到这种方式,有意思,真想知道具体如何实现。对了,这辅助数据有专业的名称吗?

老柯:有的,这种辅助数据结构就叫——索引。

未完待续…
七座城堡⓵ OLTP(下)

三分钟讲述个人感悟——感恩,回馈

系列回顾

“大白话人工智能” 系列
“数据库拍案惊奇” 系列
“世事洞明皆学问” 系列

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

收获不止数据库

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值