资料库 索引混乱:如何避免数据库混乱

索引混乱:如何避免数据库混乱

目录:

Anonim

通过Techopedia Staff,2016年10月5日

要点:主持人Eric Kavanagh与Robin Bloor博士,Dez Blanchfield和IDERA的Bert Scalzo讨论数据库索引。

您目前尚未登录。请登录或注册以观看视频。

Techopedia内容合作伙伴

Techopedia员工隶属于Bloor Group,可以使用右侧的选项与他们联系。 有关我们如何与行业合作伙伴合作的信息,请单击此处。
  • 轮廓
  • 网站

埃里克·卡瓦纳(Eric Kavanagh):女士们,先生们,您好,欢迎再次光临。 这是东部时间的星期三,四点钟,那些了解该程序的人都知道这意味着什么,现在该是热门技术的另一集了。 确实是的。 我的名字叫埃里克·卡瓦纳(Eric Kavanagh),我将主持您今天的会议:“索引疯狂:如何避免数据库混乱”。 或正如我在上一封电子邮件爆炸中提到的那样,“数据库争吵”。这些天的热门术语是“争吵”。每个人都这样做。 确实有一张关于您的幻灯片。 而且对我来说足够了。

因此,Hot Technology系列实际上是为了定义特定的空间而设计的,而不是简报室,后者只是一对一的现场分析师简报,而对于Hot Tech,我们有两名分析师。 今天,这将是我们自己的Robin Bloor医生和我们的数据科学家Dez Blanchfield。 我们谈论的是一个我认为确实象征着当今市场中正在发生的事情的话题。

最重要的是,这些天我们处于一个复杂的世界中。 确实,如果您回顾十五年或二十年,那是一个截然不同的世界,尤其是在数据库技术方面。 数据库曾经非常简单。 他们只有少数。 他们大多数是关系型的。 现在,我们拥有了整个数据库技术。 从字面上看,表上为想要构建应用程序或对数据做某事的任何人的选项。 一切都在变化,这影响了尝试管理这些系统的人员。 今天,我们将与该领域的真正专家Bert Scalzo进行交谈。 他是IDERA的高级产品经理,负责如何处理所有数据。 这样,我将把它交给Robin Bloor医生将其拿走。 罗宾,地板是你的。

Robin Bloor:好的,谢谢您的介绍。 我认为是因为这是两手事,我认为我只是在一般性地谈论数据库优化作为本次热门技术展览的介绍。 我从技术和分析方面开始生活,因为我曾经在DEC VAX平台上撰写有关数据库功能的文章,因此开始生活。 因此,数据库用户经常向我介绍情况。 我想到的是,为什么要有一个数据库? 我的意思是,在那些日子里,有很多人用来创建键值文件,并使用这些键值文件具有我们所谓的索引顺序谬误,但是却要创建某种数据库功能,并且您知道为什么会有还要别的吗?

答案是,我认为迈克尔·斯通布雷克(Michael Stonebraker)给出了最好的答案,他说:“数据库比任何程序都知道更多有关数据的位置和获取速度的信息。” 我认为这很有趣; 这是游戏的本质。 但是在1989年左右(大约是1989年),我开始进行技术分析,您知道,在那个时候,数据库非常简单,而关系数据库却非常简单。 它们的功能太少了,我的意思是,显然,它们可以存储数据,并且您可以备份,并且它们符合ACID要求,但实际上它们的优化器非常薄弱。 实际上,很难说它们完全具有优化器功能。

后来它们变得越来越好,但是,当数据库无法正常运行时(这些袋鼠似乎以一种或另一种方式表明了这一点),运行缓慢的原因可能有很多。 这使我明白了:数据库具有许多功能,但是最重要的功能是查询优化。 如果他们没有这样做,您将不会使用它们。 这是关于快速获取信息,是关于在存在大量并发用户的情况下能够做到这一点,这是一个难题。 当您实际查看它们时,我们可以将它们称为成熟的数据库,如果您愿意-但可以肯定的是Oracle,Microsoft SQL Server(当然可以是Teradata和DB2)在较小的程度上已经有数十年的历史了。建造。 您知道,他们没有-有人没有坐下-六个人参加了一个只有两个人,一年,一个项目的项目,而只是将其中一个人撞在一起了。 它不是那样工作的。 优化能力已逐渐增长,并且需要大量增长。 无论如何,让我们谈谈数据库的背景。 好吧,关于NoSQL数据库,现在有很多说法,甚至对图形数据库也有很多热情。 以及在Hadoop上使用SQL之类的东西。 但是,事情的真相是,如果您现在想要一个数据库,如果您想要一个功能全面,能够进行OLTP和大量查询流量的数据库,那么它就是关系数据库,或者什么也没有。

在关系数据库中,Oracle在流行度方面占主导地位。 我认为,Microsoft SQL Server是第二位。 它们都可以用于OLTP和查询工作负载,但是实际上您真的无法摆脱混合这些工作负载的麻烦。 对于OLTP工作负载和查询工作负载,您需要不同的事件。 有SQL和图形的替代方法。 大多数公司在一个特定的数据库上实现标准化,这就是为什么–我的意思是,在与其他所有参与者争夺数十年之后,Oracle成为了最主要的数据库。 仅仅因为他们最终能够销售公司许可证,所以公司只能在特殊产品中使用替代产品,而Oracle根本不会这样做。 数据库具有战略意义,因为它们也在发展。 而且您知道我对此演示文稿进行了一些研究,并且有一段时间,我会进行研究,但是从DBA的角度来看,它们的发展方式很有趣。 这就是我所谓的无形趋势。 这是摩尔定律。 大致是这样的:最大的数据库是新数据库,没有一个旧数据库要吸收很多数据。 通常,这是一个应用于新问题的数据库。 实际上,它们在数据量方面不断增长。 大概在摩尔的魔方 法。 因此,摩尔定律是每六年的十倍。 VLDB通常每六年增长一千倍。 1991年,1992年,大型数据库以兆字节为单位进行度量。 在'97和'98,以GB为单位。 2003,'4,TB。 2009年'10,您开始看到PB数据库。 我认为目前可能有一个或两个EB数据库,但是我听说的最大数据库是准时200 PB,而且您知道,没有将数据存储到PB数据库中。 但是,最重要的显然是新兴的大型Web 2.0公司,也许您已经使Facebook朝着这个方向前进。

但是无论如何,如果您实际查看该数据,并期望数据库经历这种数量的增长,那么它会提出很多要求。 值得注意的是,它们肯定达到了PB级别,表现还算不错。 我的意思是,我说的是旧产品,而不是新产品。 他们似乎做得非常好。 如果我们查看数据库性能和瓶颈,这将使我回到我以前真正关心它们的时间,并且不得不担心它们。 您从根本上知道这是硬件的故障。 有CPU瓶颈,可能有内存瓶颈,可能有磁盘瓶颈。 可能是引起您悲伤的网络,并且您还可能会遇到锁定问题,这取决于您在做什么,但这通常是因为该程序不知道谁来调用锁定。 因此,如果要调整数据库,则实际上是在尝试对其进行调整,以使其在这五个可能的瓶颈之间以及在可能的瓶颈之间协调一致。 这绝非易事,因为您可以在任何给定服务器上配置的内存量急剧增加。 然后,CPU变成了多核磁盘,好了,我们现在可以做到,即使在商用服务器上,我想即使在商用服务器上,您也可以做到数百TB PB的容量。 因此,在所有这些事情中,您都可以玩,当然网络可以以不同的速度运行,但是大多数情况下,当您在处理数据库时,您确实希望在服务器之间使用光纤电缆,而在此之上没有其他任何运行,特别是那样。

数据库性能因素。 我的意思是,我省略了这一切,因为我知道Dez会谈论它,但是糟糕的数据库设计意味着性能不佳的数据库。 错误的编程设计可能意味着在数据库上抛出非常愚蠢的SQL,这将花费更长的时间。 并发和工作负载混合,太多的并发会导致瓶颈问题。 当您有大型查询与非常小,简短而又尖锐的查询时,工作负载混合会导致问题。 有一个负载平衡问题。 大多数数据库都会解决这个问题,但是如果您还没有完善的产品,那么您知道,仅添加几台服务器就不是您要做的所有事情,如果您确实想增加集群的大小。 在获得最佳性能之前,实际上必须平衡负载。 您需要进行容量规划。 绝对。 尤其是在如今的这些日子里,数据量的增长速度比数据库增长的速度快得多。 整个数据层问题涉及如何摄取数据,如何转移数据。 稍后,无法按时将数据发送到数据库可能会导致性能问题,因为我们已经从Windows中运行的数据库发展到了24 x 7 x 375的操作,并且没有可以减慢运行速度的窗口。数据库关闭,或者现在不太可能出现。

Oracle DBA问题。 这就是我在想的。 我曾经在Oracle 7的Oracle DBA中工作过,我还记得如何调整它。 而且,如果您现在实际看一下Oracle,那就是方法,它是方法,方法是更多的功能。 它具有位图索引之类的功能,但实际上我花了一些时间查看一下,看看目前Oracle数据库中实际上有多少个调整参数。 而且,有超过三百五十个调整参数,还有另外一百个隐藏参数,专业DBA可能会知道,而普通Oracle DBA却不知道。 这意味着调整这种数据库是一件难事。 这根本不是一件简单的事情。 您必须对此有一种感觉,必须已经进行了很长时间,而且您必须确切地知道您认为要解决的问题,因为调试会在性能变差,但可能不是所有性能。 这可能取决于特定查询的性能,您可能能够通过固定某些数据和内存来解决此问题,或者您可能需要通过建立索引来解决它,或者您可能需要开始以其他方式进行分区。 重点是您可以做很多事情。 因此,因此,他们不会立即动脑筋– DBA需要工具。 我想转达给Dez,他会告诉您有关索引的信息。

Eric Kavanagh:好吧Dez,拿走它。

Dez Blanchfield:谢谢Robin,我喜欢封面。 我认为您已经把那只手套扔了下来,让我什至可以近距离接近令人兴奋的事物。 但是我使用了我们的小星系的图像,因为我对当今数据库管理员所面临的挑战的看法已经转变,因为这是我进入环境后往往会联想到的心理图像,而我不再不再需要在该级别上管理数据库或设计数据库。 但是,像您一样,Robin和我作为管理员或开发人员,或者最终成为架构师都参与了数据库领域多年,然后才意识到我可以做得更好,以赚钱。 但这确实让人感觉您正在盯着这个庞大的数据,而今天,正如您所概述的那样,当我们从兆字节扩展到PB时,我们在很短的时间内就达到了exo规模,在宏伟的计划中。 但是我想到的一句话是,数据库索引现在已经成为一种妖术,对于企业级业务应用程序和制定您的类型而言,它们实际上并不是凡人应该钻研的东西只是在谈论。 但是,我想快速回顾一下我在数据库世界中遇到的历史类型,并介绍我们将要得出结论的环境,然后今天与我们的朋友一起阅读一些材料IDERA,因为我认为关于如何进行数据库性能调优有很多不同的想法,其中之一就是在解决问题。 对于我遇到的很多商店,他们总是无法理解在数据库层(尤其是索引层)进行性能调整的要点,直到他们通过艰难的思路思考可以向其扔调谐器。

在我看来,很多人只是对它采取了强硬的态度,而我在这里有了The Flash的照片,因为如果您曾经看过任何老电影,或者肯定是看过The Flash的最新电视节目的,例如Flash Gordon是老角色,现在他被称为“ Flash”,他倾向于跑得非常非常快,而且精力总是耗尽。 当您对数据库性能大加抨击时,就会发生这种情况。 根据我的经验,您始终可以在游戏中投入高性能,艰苦的工作,可以优化操作系统并将它们调整到一定程度。 您可以确保拥有快速的多核,多线程CPU,以使应用程序运行更快,可以在其中投入大量RAM,可以拥有高吞吐量的背板,可以从硬盘驱动器到将硬盘驱动器缓存到固态驱动器以及高性能存储阵列。 甚至现在,人们还在他们的数据库引擎中添加了flash和NVMe之类的东西,以为他们将获得这种登录时间乘以两倍的性能提升。 而且它们的确会有所收获。 但是,所有这些都回到了相同的基本性能调整问题。 许多低延迟的网络连接,因此群集可以快速运行。 在集群数据库基础架构方面,您不仅仅需要一台机器来完成所有工作。 但是您确实会回到相同的基本性能问题,那就是读取数据。 编写数据在大多数情况下是一个相当线性的挑战,除非正确完成。

然后,我们面临着当今世界的挑战:并非所有数据库都是平等创建的。 有数据库和带引号的“数据库”。当我们想到数据库引擎时,人们经常会想到SQL世界中传统的,通常的可疑对象。 您知道,我们拥有Oracle和Microsoft SQL Server,并且在开源世界中,围绕着它的一对夫妇与MySQL(现在归Oracle拥有,但仍然是开源的)。 然后我们得到了不常见的怀疑,NoSQL引擎,它们仍然在索引和性能管理方面存在问题,我将不做详细介绍,但是越来越多的人事情每天都在发生,从开发人员的角度和从性能的角度来看,它们的外观和感觉都像数据库引擎,但是它们是非常不同的野兽,它们在世界上都有自己的小众市场可以开拓内存性能或磁盘上的线性比例。 但这就是数据库世界的样子。 这是2016年,这是该地图的第三版,由一系列产生这张数据库状态图的正在进行的人组成,这就是它的位置-甚至连超人数据库架构师或数据库管理员都没有道理它的。 从字面上看,数百个,数百个和数百个不同的制造商,模型,数据库制造商,始终都与SQL兼容。 有趣的是,他们都回到了相同的挑战。 数据库引擎周围的性能和性能调优,尤其是如何对数据建立索引。

因此,让我们快速介绍一下数据库索引编制,因为这是一个有趣的话题,我相信您必须在演示中更详细地介绍它。 但是,我认为数据库索引性能调优是确保可以快速,快速地访问数据的世界的起点和终点,这是公认的标准行业惯例。 但是什么是数据库索引? 如果我们考虑以我们日常使用的形式进行索引,请考虑一下书中的索引页。 如果您想在书中找到某些东西-特别是百科全书之类的东西,或某种形式的参考资料之类的东西-如果您正在寻找此页面之类的东西,而我正在寻找诸如水坝之类的东西在百科全书中。 我想找到关于水坝,集水区和大面积集水区(通常是人为的)的所有参考。 我将回到后面,在按字母顺序排列的列表中(从A到Z,从左到右)找到它,然后找到D。我会找到“ dams”一词,然后在在第16、38、41页上有一个引用,然后我可以转到这些页面,向下浏览,然后找到对“ dam”一词的引用。在数据库中,这基本上是相同的概念,但从许多方面来看,它现在是一门火箭科学。 如此之多,以至于我所认识的每个数据库管理员实际上都认为索引是任何数据库世界中性能优化的最关键的工具,无论他们的经验如何,或者无论如何。

通常,当我们谈论数据库索引时,有许多常用方法。 数据库索引越复杂,索引数据的方法就越复杂。 但是实质上,当您考虑对数据建立索引时,请想象一下,我们有一个包含名称列表的文件; 它们可能未按字母顺序排序。 让我们想象其中有二十个。 如果要进行排序–如果要从上到下搜索该列表中的数据,则可以说这是一个名称列表。 如果我选择一个随机名称,并且开始以线性格式上下滚动该列表,并且它是无序列表,那么我会考虑两个条件,即平均搜索时间和最大搜索时间–我在第二行中有一个错字,应该是“最大搜索时间”,对不起–但是我的平均搜索时间本质上是N加1除以2,平均来说,这需要我花费50%的时间从列表的顶部扫描到列表的底部以查找该列表中的任何随机对象。 线性下的第二行应该是“最大搜索时间”。但是,最大搜索时间本质上是项数,也就是说,如果我有二十个东西的列表,那么它最多可以花费我的时间在该数据库中搜索内容的方法是从上到下,在这个简化的示例中,假设有20个项目。 这是一个非常缓慢的过程,实际上没有办法对其进行性能调整。 然后,还有其他类型的获取数据和创建索引的方式,实际上是指向实际数据所在位置的简短指针列表,例如二进制,B树,位图,哈希,聚类和非聚类,然后会有不同类型的数据,例如空间,过滤的,XML和全文。

二进制是非常常用的一种,用于将数据借给它的事情。 从历史上看,B树在一般意义上可能是最常见的树,因为它是一种结构化到任何形式的数据的索引的通用方法,并且允许您在围绕指针移动记录器,选择以及插入和删除操作时相对容易引用指针,要点。 还有其他类型,例如位图,其中的数据类型所关心的就像我们有某种形式的关联范围。 散列对于大型对象(尤其是博客和图片)非常有效。 您会看到,存在许多不同类型的科学方法,数学方法来为数据建立索引。 对于仅仅是凡人,在这个级别上谈论它们是一个有趣的挑战。 当您在数据库管理员的性能级别上谈论它时,他们的确成为了火箭科学家,人们也获得了学位。我知道Robin Bloor博士确实做到了,并为IBM和IBM等公司撰写了相关书籍。在过去的几十年中,其他大型品牌。 所以,我的观点是,我们实际上已经度过了一段时光,您曾经知道我可以亲自坐在系统的前面,并且可以将其拆开,并向您展示确切地在命令行或图形用户界面启动工具中发现性能问题的位置,然后开始深入研究数据并告诉您问题出在哪里,并在其中建立索引,子索引或主索引和二级索引数据并开始使用它来查找事物。 但是,当您考虑到这种情况时,我向您展示了我们拥有成百上千个品牌,品牌和型号以及制造商和数据库类型的地方,我们现在已经过去了很长时间,在此之前,人们可以了解我们拥有的数据库引擎的类型。 特别是,即使我们只是回到了像Oracle这样的公司,这些天在关系数据库平台中仍是主要品牌。

他们必须从诸如ERP或HR或财务系统之类的专有平台处理的数据库数量,或者由于各种原因而成为家庭烘焙平台的数据库数量,最终产生的数据库以及数据库表和记录处理只是天文数字,您实际上无法手动完成。 现在,我们又遇到了另外一个麻烦,那就是曾经有一段时间,数据库服务器可能就在您的办公桌下面。 您知道,作为一个放学后的小孩,我曾经在最初的Apple IIes上工作,然后在基于DOS PC的系统(例如dBase II,dBase III)上使用数据库软件,经历了大型机和中端市场的时代。范围,甚至包括VAX,PDP和日志文件。 诸如Sabre之类的东西,然后最终出现了一些SQL数据库。 但是现在,当我们考虑数据库引擎时,它们看起来就像左下角。 数据库服务器不再只是一台坐在桌子下的地板上的机器了; 它是运行数据库引擎和群集副本的数百台机器,它们的确可以扩展到数百TB的数据(如果不是PB的话,也就是数千TB)。 正如罗宾·布洛尔(Robin Bloor)博士所提到的,甚至到了极点,某些特定的用例(尤其是航空公司,尤其是政府机构)也可以达到EB级。 它们仍然相当利基,但是数百TB甚至数十PB的情况已不再罕见,尤其是从互联网泡沫到现在,我们所谓的Web 2.0公司,例如Facebook,Google,Yahoo等等。

现在事情变得复杂了,因为事情正在转向外部服务。 我们拥有基础架构平台和软件即服务的方法来提供基础架构。 特别是平台服务,我们不能仅仅购买Oracle及其云平台,数据库和服务器之类的东西。 因此,这使我们能够非常快速地开发应用程序,只需将数据库重新插入服务器即可。 我们不必考虑背后的问题。 不利的一面是,在数据库开始受到损害并且性能成为问题之前,我们通常不会考虑如何设计和实现数据库,然后最终不得不寻找正确的工具来诊断数据库受到损害的原因,并且性能问题所在。 并且总是将其带回到一个常见的问题,即我们如何对该数据建立索引以及用于该数据的索引类型,然后使我们回到超人的性能要求。 有权使用合适的系统和合适的工具来对这些引擎进行性能调整的人,开始寻找热点,并查看查询的位置,数据的移动位置,查询的类型,查询的结构,谁在进行查询,以及查询是否正在排队以及是否需要缓存。 您要寻找什么复制品?

因此,在我看来,我们现在处于良好状态,即使是世界上最好的数据库专家,从本质上来说,我们的数据库架构师,数据库管理员和性能基础人员,也非常需要开始使用正确的工具为任何数据库引擎提供最佳性能索引调整。 因为我们正在处理的规模和事物的发展速度,我们根本无法手工完成,并且尝试这样做总是会引入其他性能问题,因为我们可能没有在该领域拥有经验。我们正在尝试解决一个问题。我相信这就是我们要交给Bert的地方,我们将要讨论他们如何解决这个各种各样的问题以及他们的工具可以解决的问题这样做,尤其是对于Oracle世界。 到了那儿,伯特,我要转交给你。

伯特·斯卡尔佐:谢谢。 欢迎大家,我叫Bert Scalzo,我为IDERA工作。 我是我们某些数据库产品的高级产品经理。 我将在今天演示其中的一些。 但是我想谈一谈索引,因为我同意每个人在这里所说的一切,尤其是最后一张幻灯片,因为索引非常复杂,您需要一个工具,并且希望说服您。 因此,Oracle索引设计并不像过去那样容易。 许多人在看选择时会不确定自己,我喜欢这样说,我退出了历史,“在这些问题上,唯一可以确定的是,没有什么是确定的。”这就是我的看法感觉这些天的索引,因为即使您认为知道应该对X,Y或Z进行索引,也无法确定是否要尝试,因为这些优化器的行为有时会与您期望的方式不同。 因此,索引设计有很多试验和错误。 现在,在过去的好日子里,如果您需要索引,通常只有两个问题或一个问题。 它是独特的还是不独特的? 您可能已经想到了其他事情,例如“一个表上可以有多少个索引?”,因为太多的索引会降低插入,更新和删除的速度。 您可能也已经在数据库系统中,对多列索引中的列数有限制,因为有时会基于数据库引擎的页面或块大小进行限制,但实际上这很简单在过去的美好时光。 您要么索引了索引,要么没有索引。 实际上,一切都在B树中。 我们可以允许重复与否,仅此而已。 生活是美好的,生活是简单的。

今天,生活不是那么美好或那么简单。 我将红色的Ghostbuster标志按照以前的方式放置,因为现在我们有了B树,位图,位图连接。 我将在稍后解释其中的一些内容。 群集和非群集,唯一或重复,正向或反向顺序,基于函数,已分区或未分区。 如果涉及分区,是全局分区还是局部分区? 我也会解释这一点。 然后还有一个称为索引组织表的东西。 实际上,我还有六个人要离开这里,因为我认为现在我已经足够了,应该可以说服您索引比您想象的要难得多。 在这张特殊的幻灯片中,我将从图表的左上方开始,并有一个表格。 我首先要决定的是,根据您的数据库版本和您的数据库供应商,它们是否允许对象表还是仅是关系表? 我要在右边说,我们正在建立一个关系表。 现在,我要问自己的下一个问题是,它是否在集群中? 而且,许多使用Oracle已有一段时间的人会记住,集群已经恢复了6天。 今天,它们的使用率可能不再很高,但是让我先从该分支开始。

如果要将表放在群集中,则必须在该表上具有群集索引。 现在,在Oracle中,当您对一个表进行集群时,基本上是在存储行或行彼此靠近,并且值相似。 因此,您必须具有聚集索引,并且该聚集索引可能是未分区的。 换句话说,实际上没有任何分区方法可以用来处理群集表。 它是严格未分区的。 而且因为它是未分区的,所以它是全局的。 我将在一分钟内解释什么是全局。 它总是B树。 换句话说,当我下到那个分支时,这很简单,我没有太多选择。 现在,如果我在一个集群表上做了一个非集群索引(在某些版本中是允许的),那么它又再次是非分区的; 如果未分区,则唯一的选择是全局。 因此,您可以选择B树或位图。 同样,它取决于您的数据库版本。 但是现在,让我们回到关系表,再次从右侧向下走,现在我们将拥有一个普通的,旧的,规则的,堆积的表:关系表。 它将会在表空间中。 我有点先在这里走右边。 所以是组织,堆。 我必须问自己的下一个问题是:“我要对这个表进行分区还是不对?”现在,有时您会进行分区,因为您认为:“嘿,优化器将更聪明地优化查询。 “但是许多DBA会告诉您,这样做的原因是出于管理目的。 如果您有一千亿行的表,如果将其分解为分区或存储桶,则当您要将数据添加到最后一个存储桶时,可以删除并索引只有几百万行的数据。 您可以插入该数据,然后可以仅在该存储桶上重建该索引。

尽管对于某些优化技术(例如消除分区)来说这是一种好技术,但其真正的价值在于能够在较小的部件上进行管理或执行管理任务。 当我进入组织堆时,第一个问题是:“是否对它进行分区了?”让我们转到左侧,我不会对表进行分区。 现在,当我告诉您这一点时可能看起来很奇怪,但是您可能有一个未分区的表,然后就无法按照习惯对索引进行分区,或者可以对索引进行分区。 停下来想一想。 就像您一直想的那样,表基本上有一个存储桶,但是索引将有多个存储桶。 发生这种情况时,存储桶和表的数量以及索引中存储桶的数量不匹配,这就是全局的含义。 因此,如果表未分区,并且索引已分区,则将其视为全局表,因为存在不匹配。 现在,让我回到组织堆上,然后回到分区端。 现在,如果我有一个分区表,并且假设该表有四个存储桶,四个分区,那么我的索引可以有四个存储桶,以便索引与我的表设计相匹配。 这样就结束了,结束了,在右侧。 那将被认为是本地的。 本地索引基本上意味着表和索引的分区以相同的方式完成,并且具有相同数量的存储桶。 然后,一旦有了本地索引,它就可以是B树或位图,并且向上的那个绿色箭头向您显示,即使它是B树,仍然可以做出选择。 它可以基于功能。 而且,如果是位图,则有不同类型的位图。 有一种叫做位图连接索引的东西。 如果您正在执行数据仓库,那么这是星形模式或设计的一种非常流行的索引。 发生的是该索引具有指向表中所指向内容的行ID,但它也具有针对父表的行ID,因此,当您–必须加星型设计并且正在寻找时,在事实表上,事实表上的索引将您指向您感兴趣的数据,并将您指向维度中的每一行,因此您只需要一个索引。

实际上,这是由于红砖(Red Brick)已存在的原因,该数据库是很多年前的数据库-许多人可能还记得这一点。 因此,如果您查看这张图片–请记住,由于图片会更大,因此我并未将所有内容都放在这张图片中–仍然有其他问题,我在此处的右上角部分有文字说明。 它是逆序索引吗? 您可能会说:“为什么要建立逆序索引? 嗯,如果您在Oracle的集群环境中,如果您在进行真正的应用程序集群,则要保持索引有序,那么就不要逆序,如果要处理大量的处理,那就好了。相同的值或相同的索引值,将会发生B树的热点区域。 这意味着您可能会争用并可能需要锁定才能尝试访问这些内容,并且您将在网络中的各个节点之间进行操作。 好吧,如果您输入了逆序索引,现在可以撤消该操作。 您可以说:“好吧,相似的值位于树的不同部分,因此我没有单独的节点争夺树中的热点区域。”然后还要注意,唯一性不适用于某些选项。 如果您看的话,我已经编号为3、5、8和11,因此在某些情况下我无法获得唯一索引。 同样,在某些情况下我无法拥有反向索引,然后还有其他问题,例如记录日志或不记录日志,以及并行和非并行。 我可以将内容分配到内存中的特定区域。

而且这遗漏了Oracle中的许多功能。 我想说的是,当您查看Oracle 12时,可能还会再有六件事可以添加到这张图片中。 索引编制确实很复杂,我也确实同意以前的发言者的观点,为了对此进行导航并做出明智的选择,您需要一个工具。 您可能需要这样的图片,以及某种如何选择物品的方法,希望该工具可以帮助您实现目标。 然后将是反复试验。 我总是告诉索引的人,“跳之前先看一下。”然后您会看到这里的小狗,他跳来跳去,他会和鲨鱼一起陷入水中,或者那个家伙准备跳入水中,而他要刺穿自己。 您必须考虑索引问题,因为创建索引并不总是意味着事情会变得更好。 实际上,创建索引会使速度变慢。 选择一个选项可以使查询性能提高一个数量级。 我会给你一个很好的例子。 如果您要进行星型设计,并且在尺寸表上使用一种情况下的位图索引,而在另一种情况下则说“我将使用B树索引”,那么位图与B-树。 我可以告诉您,一个解决方案将比另一个解决方案快一个数量级,或者可能快几个数量级。 但是请记住,在一个环境中(例如在数据仓库环境中)有效的方法在OLTP环境中可能不是一个好的选择。

例如,如果要处理一个事务表,然后将位图索引放在一个事务表上,那么计算和重置位图,这些长字符串就非常昂贵,因此在OLTP表中,您可能会撞到该表,以至于位图索引可能会损坏并降低系统速度,因为它们不适合更新。 它们非常适合快速访问,但不适用于更新。 我确实认为索引需要反复试验。 确实再也没有黄金法则了-这个方程式中有太多不同的变量要知道–最终,您将不得不查看执行或解释数据库中的计划,以查看是否做出了正确的选择。 有时,计划分析本身几乎就是一门科学。 我今天不打算讨论这个问题,这是另一个话题,但是不要把索引设计视为理所当然。 有正当的理由,为什么我在先前的图片中以及先前的发言人谈到的所有这些疯狂的索引类型都向您展示了。 创建这些文件不仅是因为它是一项精巧的功能,它可以为数据库供应商添加清单。 在某些用例或场景中,这些索引很重要,并且会产生重大影响。 现在,我将向您展示我们工具之一中不同类型索引的一些示例。 让我把屏幕打开,以便您可以看到它。 好的,所以我坐在这里–让我最小化此应用程序。 我坐在VMware内部,正在运行Windows Server 2012 VM。

您会看到,我几乎拥有人类已知的所有工具。 作为产品经理,我必须时刻了解自己的竞争,因此,不仅拥有什么工具,而且竞争对手会做什么? 我们这里有一个名为DBArtisan的工具,我已经在运行它,但是我要开始了-所以我将其介绍一下。 您会看到这是一个非常不错的工具,因为不必使用,例如Oracle的企业管理器和SQL Server的SQL Management Studio,MySQL的MySQL Workbench以及我们支持的其他十二个数据库,好吧,我已经将所有数据库都内置在此工具中。 有DB2,有MySQL,Oracle,Postgres,SQL Server和Sybase,那是–在这个特殊的事情上我只有六个数据库,因为我不能这样做–该工具支持十二个数据库,但是我的可怜的VM,同时运行六个数据库,然后尝试进行演示,几乎与我的硬件将为您带来的便利一样。 因此,现在让我回到Oracle,如果您注意到了,所有这些都是一样的。 如果要衡量我在DB2中的性能,那是与在Oracle中相同的选择。 现在,在幕后,我们做了很多不同的事情,因此您不必知道发生了什么,但是我们为您提供了一致的界面,因此您可以成为拥有多个数据库平台的专家。 这将包括使用索引(此讨论的主题)。

让我进入这里,让我首先开始看一些表格,我有一个电影数据库,其中只有几个表格。 而且,如果我在这里查看特定的表(例如客户表),则可以看到我的表设计,这是表中的列以及每列的信息。 我有表的属性,但是请注意,这里有一个用于索引的选项卡,我可以看到这里是表上的索引。 请注意,这些索引之一是我的PK索引,即我的主键。 这些其他索引似乎只是用于改善查询访问的索引,也许我们通过名字或姓氏进行查询,或者我们查​​看电话和邮政编码。 如果我选择一个特定的索引(例如此处的邮政编码),然后双击它,现在我可以看到,嘿,这是一个非唯一索引,还有一些其他类型,位图,非唯一,唯一性,是否进行排序,是否记录日志,是否反向,是否基于函数。 哦,这是我没讲过的一个有趣的故事。 您实际上可以拥有不可见的索引。 然后您会说:“那么,为什么我想做一个无形的索引?”好吧,我给您一个很好的例子。 您在生产系统中,并且遇到性能问题,并且不确定创建索引是否可以解决问题,因此,您不想创建索引并减慢生产速度,但是您希望以某种方式或其他方式能够测试它。 您可以在生产中将索引创建为不可见的,这意味着调用优化程序的应用程序代码将很少使用该索引。 它已创建,有效,但是将不会使用。 然后,您可以进行一个您认为可以帮助该索引的查询或一系列查询,然后可以贴上一个提示,说:“嘿,优化器,那里有一个不可见的索引,我想让您使用并让它我知道我是否已经使事情变得更好。”现在,我已经在生产中测试了某些东西,但是我没有破坏正在运行的生产中的应用程序。 这就是不可见索引的用途。 当您第一次听说它时,它听起来很蠢,但是它很有用。

我们还可以在索引上定义它们是否并行以及跨多少实例。 现在,在非集群或非真实的应用程序集群环境中,因此非机架,并行将意味着我的查询可以带动多少个子流程进行尝试,而工作进程则可以尝试更快地使事物通过。 如果我在一个真实的应用程序集群中,那么并行实例就是说我有十个节点,那么我可以将几个节点拆分为多个工作? 可能是十个中的四个,每个上都有四个子流程。 那是一个例子。 然后我们进行密钥压缩。 您实际上可以压缩索引吗? 是还是不是。 然后,您当然拥有可以在索引上指定的存储参数。 现在,我不介绍这些内容,因为它们实际上实际上是一个存储参数,而不是索引问题。 最后,我们要确定是否将这些分区或未分区。 让我在这里稍等一下。 我要去一个不同的模式。 这是星型模式,例如,此周期表是维度表。 如果您曾经做过星型模式设计,那么通常就需要一个时间维度,因此在此数据库和该星型模式中,期间就是时间维度。 现在,我知道它看起来会很有趣,您会说:“哎呀,看看所有这些列–那个家伙听说过标准化吗?”那么,当您处于数据仓库或星型模式设计中时,您会发现通常有非–您有一个典型的人会看到的表,说:“ Gee,这些表的设计不是很好。”但这就是您在数据仓库环境中这样做的方式。

现在,看看会发生什么,因为,好吧,所有这些列,看看,我在每一列上都有一个索引。 现在,在OLTP环境中,这是不行的。 这会减慢我的所有操作。 在数据仓库环境中,我将在批量加载周期中删除它们。 无需开销或索引即可加载,然后重新创建索引。 而且,如果我对表进行了分区,那么不必在表中的每个存储桶中删除索引,只需在该批处理加载周期中将要存储数据的一个或多个存储桶中删除索引即可。 然后仅重新创建这些存储桶的索引部分。 因此,这非常易于管理。 如果我看一下,那么这是一列“假日标志”,基本上是“是”或“否”。 请注意,这是一个位图索引,对于大多数人来说,您会说:“好吧,这很有意义。”是或否,Y或N,只有两个值才有意义。 而且,因为当您阅读有关位图索引的文档时,它们总是告诉您选择基数较低的内容。

现在让我进入我的事实表之一,所以这里有我的订单。 这是我每天的订单。 现在,您将看到,我又有很多列,而我又要有多个索引。 在这里,我们有一个称为通用价格代码的东西。 这是用于零售商店的,因此在商店购买商品时,您会知道这些小条形码,这是通用价格代码。 现在,有数百万种通用价格代码。 现在,对于这家销售商品的特定公司,它们可能具有1.7到200万个通用价格代码,因此您可以期望这不会成为位图索引,因为170万个不同的值听起来像是高基数。 但是实际上,在数据仓库环境中,您希望将其作为位图。 现在,让我解释一下原因。 好吧,这个通用价格代码可能有170万个不同的值,此订单表中的行数为数亿至数十亿行。 与表的大小或基数相比,我的索引是低基数。 这使其基数较低。 这使位图索引很有用,即使您选择此处的位图具有170万个不同的值是违反直觉的。 现在,如果我知道我想使用位图联接索引,那么当前该产品不支持该索引,那么我将在下一个发行版中添加该索引,但这是此处的另一种选择。 在星型模式中,请记住,位图索引将位于事实表上,而B树中的一个索引将指向事实表中的行,然后指向该事实在维度表中显而易见的每一行。 因此,您还有另一种选择。 因此,让我们来看一下,我现在想离开表格,我只是想快速向您展示在索引下我具有相同的信息,并且我将做同样的基本事情。

现在,我提出这个问题的原因是您可能会注意到,嘿这里没有主键。 主键是通过键约束来完成的,因此约束定义实际上覆盖了主键。 这些将是不属于约束的索引。 现在您可能会说:“好,等等,这看起来像一个外键,而外键是一个约束。”但是,外键和大多数数据库不会自动在外键列上创建索引,即使它是明智的选择,然后又去了–我又有了所有相同的选择。 如果我只想进行压缩就可以进行更改。

现在压缩仅适用于B树索引。 允许的是,当您查看B树中的各个节点时,它允许压缩某些值。 实际上,它不是像表压缩那样的压缩,而是对非叶子节点中B树中存储内容的压缩。 它不会节省大量空间,但可以有所作为。 我注意到,我已经接近时间了,所以我想做的是,我想返回并停止共享。 并且,我们在idera.com上提供了为期14天的试用产品。 这是一个非常好的产品,尤其是在使用多个数据库平台的情况下。 如果您使用两个或三个不同的数据库,则此工具将使您的生活更加轻松。 我们确实有可以帮助您进行索引设计和选择的工具,我们有一个名为DB Optimizer的工具。 今天我只是无法报道,那太过分了。 如果您想与我联系,这里是我的电子邮件地址,或者是您可以在我的私人电子邮件中找到我,并且我有博客,网站,博客和LinkedIn个人资料。 因此,即使与产品无关,也可以随时与我联系,如果您只是想谈论数据库,我是个极客,并且我喜欢涉嫌技术怪癖。

埃里克·卡瓦纳(Eric Kavanagh):好吧,德兹(Dez),罗宾(Robin),我敢肯定你们每个人至少有几个问题,我们这里还有几分钟。 Dez,您怎么看?

Dez Blanchfield:我有一个很好的问题要问你,它一直困扰着我。 您看到过的最疯狂的情况是什么? 我已经读过您的博客,我会密切关注您,您-您可能是生活在几乎每一个不太可能的地方的少数人之一,我认为Robin Bloor博士是我遇到的第二个人我的一生。 但是,您知道,您可能已经见过每一个疯狂的情况,遇到过的最疯狂的情况是什么,就像遇到无法应付的人类一样,您已经设法行走并在整个DBArtisan中执行绝地思维技巧?

Bert Scalzo:我们曾经有一位客户,他们在他们的数据库设计中非常想像他们在文件布局设计中的想法,因此,当您标准化数据库时,您要做的第一件事就是摆脱重复组。 好吧,他们有一列,然后将其设为long或BLOB或CLOB,然后将值,第一,分号,值二,分号,值号,分号放入其中,并且将具有数千个值在那儿,但是他们需要在那一列上搜索,就像,“为什么这东西运行这么慢?”而我想,“嗯,您不能为所做的事情创建索引,这只是因此,我们实际上使用计划向他们展示了他们需要做的就是标准化该表。 不是因为规范化是使事情变得更好的某种学术练习,而是因为他们想要对该领域进行查询,这意味着他们希望能够对其进行索引,并且您无法在重复的组中对其进行索引,或者至少不容易。 因此,这可能是我见过的最糟糕的事情。

Dez Blanchfield:是的,有趣的是您经常遇到什么,我认为数据库面临的挑战,人们忘记了这是一门科学。 在整个空间中都有学位和博士学位的人,在上面写论文,您就写了一大堆东西,包括TOAD手册和其他记忆中的东西。 现在,趋向于引用报价的“大数据”的趋势–我看到很多人都忘记了数据库体系结构和数据库技术,数据库科学的基础知识(如果愿意的话)。 您在该领域中所看到的是,从我们确实有效地摆脱了传统数据库平台和传统数据库思维的转变来看,这仅仅是性能调整和扩展的一种情况。 您是否看到很多人重新学习并有一个经验,他们坐在那里,有一个“ ha-ha”时刻,就像一个尤里卡时刻,他们意识到,这些大数据实际上只是一种非常大的数据库? 那是一件事吗,人们在回答你,有点像:“我们忘记了我们所知道的,您能从黑暗中带回我们吗?”

Bert Scalzo:嗯,不,必须承认这一点很可怕,但是关系数据库供应商也喝了Kool-Aid。 如果您还记得,我不知道,大约十年前,我们开始将非结构化数据放入关系数据库中,这有点奇怪,然后,数据(关系数据库)现在添加了NoSQL类型东西。 实际上,在Oracle 12 CR2中-我知道它还没有发布-但是如果您查看beta,如果您处于beta程序中,则它支持分片。 因此,现在您有了一个关系数据库,该数据库未添加NoSQL分片中的概念。 因此,对于关系方面的人来说,“ a-ha”时刻似乎更多,他们会“ a-ha”。再也没有人再做一次了,甚至没有数据库管理者,所以我们已经必须走过去,加入黑暗的一面。

Dez Blanchfield:好的,所以您说的是转移到许多凌乱的数据,如果我理解正确的话,那么我们现在称之为大数据平台,这很有趣,因为它们不是那么古老,但这是否意味着他们将注意力重新放在关系数据库上的工作上,以期获得更多回报?

Bert Scalzo:不,通常,如果他们有需求–会被引用为“大数据类型需求”,那么他们发现,他们不必去另一个数据库平台就可以在非数据库环境中做某事。关系方式,数据库供应商现在在他们的关系数据库中为他们提供了相同的非关系技术,以执行这些操作。 我的意思是,一个很好的例子是,如果您拥有非结构化数据(例如JSON数据类型或某种其他复杂的数据类型,这些数据具有嵌入数据本身的含义),那么数据库供应商不仅会支持它,还会为您提供ACID符合非结构化数据。 关系数据库已经采用了更新的技术,因此,“ a-ha”似乎并不是更多,“嘿,我们应用程序开发人员没有学到一些东西,我们需要再次学习它,”它是“嘿。 ,我们现在就以这种方式进行操作,如何在您传统的关系数据库中以这种方式进行操作,并且像在这里的数据库中那样进行操作?”这变得越来越普遍,而且就像我说的那样,数据库供应商本身正在启用那。

Dez Blanchfield:是的,在这个领域,DBArtisan工具的传统嫌疑人是谁? 我对您最近写的内容做了一些功课,并从内存中写了一些东西,我认为这是您的博客之一,内容涉及Oracle世界中极高的数据库性能。 我不记得是什么时候了,我想是从记忆中或从去年下半年开始,您已经写了这本书。 在我看来,这是我们今天谈论的主题类型的传统且通常的怀疑者,人们将在其中进入大型数据库环境,并在其中寻找您所谓的最大收益。 您通常会看到谁正在使用DBArtisan并充分利用它?

伯特·斯卡尔佐(Bert Scalzo):嗯,我们有很多客户,实际上,今天我在一家非常大型的政府机构工作,他们实际上拥有近1, 000个我们的软件副本,因为它使人们可以专注于他们的工作。重新做,而不是怎么做。 没关系,我的意思是,每个人都应该知道如何做某事,但是生产力正在完成“什么”工作。 如果企业要求我执行任务,那么这就是他们感兴趣的全部。我什么时候获得复选标记来说明任务何时完成? 我不是用什么技术或什么技术来达到目标​​的。 因此,我们的工具使他们能够专注于内容,并使他们的工作效率大大提高,这的确是巨大的优势,就像我说的那样,某些数据库为他们的数据库平台提供了一种工具。 我们为十二个数据库平台提供它。 我具有相同的工作流程,相同的图形用户界面,相同的导航。 如果您知道如何向用户授予特权,或者如何在数据库中创建表或创建索引,则可以在全部十二个对象中进行操作,因为它们的外观和感觉相同,工作流程相同。 这对我们的客户具有巨大的价值。

Dez Blanchfield:是的,我想,人们希望从人力资源中获得更多收益。 而拥有Oracle,Ingres和DB2专家的日子已经一去不复返了。 人们应该成为所有行业的杰克,所以我认为这件事绝对挽救了他们的生命。

在我交给罗宾·布洛尔医生之前,这只是最后一件事。 您提到有14天的免费下载,怎么办–如果我要继续,我要这样做,顺便说一句,我将其放入Bloor技术实验室并进行旋转自己动手做吧-在今天之前,我没有机会这样做。 您提到了一个为期14天的试用版,您说它是在计算机上的VM上运行的,我假设它是一台笔记本电脑。 什么是入门级设置,让人们可以动手并使用十四天试用期,就在我回到罗宾面前之前,他的问题是什么?

Bert Scalzo:任何Windows环境,因此是Windows 7,具有一个CPU和4个内存的虚拟机。 我们不是一个真正的胖子或昂贵的工具。 现在,如果您想在同一Windows下的同一VM上运行数据库服务器,是的,您需要添加更多,但是如果您是在数据库服务器或单独的VM上运行数据库,则该VM要加载和加载。运行我们的产品非常轻巧:一个CPU,四个内存,几乎任何版本的Windows –我们支持32位和64位安装。 但是您必须安装数据库供应商的客户端。 因此,如果您想连接到Oracle,则必须安装SQL net客户端,因为这是Oracle与数据库对话所需的。

Dez Blanchfield:听起来很简单。 我认为,除了意识到此工具将挽救生命之外,我希望人们能带走的这件事比他们希望的要多得多,那就是他们应该去下载并使用它,鉴于您要提供14天的免费试用。 它可以在当前的笔记本电脑上运行,而无需安装其他任何东西,因为如果他们已经在进行数据库管理,他们已经在使用数据库,那么他们已经拥有了所有这些工具,并且无论它是在本地VM上还是在其本地虚拟机上运行本地桌面,听起来很容易安装和使用。 因此,我强烈建议人们这样做。

罗宾,我确定您有问题,埃里克,您可能已经从听众那里得到了一些信息,所以罗宾,我如何传递给您,然后再回到埃里克?

罗宾·布洛尔(Robin Bloor):是的,好的,我有话要说,我的意思是,我一直都觉得这个领域很迷人,因为那是–我咬牙切齿。 但是事实是,大概从1998年,1999年以来,我一直对Oracle的实际能力不满意。 而且,我知道Sybase和Microsoft SQL Server,与Oracle相比,这两个都相当简单。 当您开始谈论分片时,您让我发笑–我的意思是,我捂住了嘴。 Oracle以前曾这样做过。 Oracle在某个时候推出的,他们对对象关系的想法感到不安,因此他们引入了在Oracle中创建一种对象表示法和对象存储的功能,我和他们的一位工程师进行了交谈,就像几个在他们推出它的几年后,我问有多少人使用它,他说我认为有两个客户尝试过它,仅此而已。 而且我认为,如果他们开始尝试并推动NoSQL趋势发展,同样的事情将会发生。 您知道,我认为这是一个错误,我是说,我对您的想法感兴趣。 当然,他们会喝库尔援助。 他们觉得好像他们必须能够像Cassandra这样的大型NoSQL数据库一样进行声明,但是您知道,这对您有意义吗?

伯特·斯卡尔佐(Bert Scalzo):不,您已经砸到了头上的钉子。 对我来说,如果我要进行关系型,我会选择一个关系型供应商,例如Oracle或SQL Server或DB2或Postgres,但是如果我要做一些非关系型的事情,在大数据空间或NoSQL空间中,我将为正确的工作选择合适的工具。 而且我认为那自然不会先交给我的关系数据库供应商。 然后,向其添加其他皱纹,即云中有什么可用的? 如此众多的人希望脱离自己的数据库。 然后,您必须查看您的云提供商,然后说:“好吧,您是什么提供商,有什么数据库可以满足我的需求,它们的实用性如何?坦率地说,使用该数据库的价格或费用是多少每小时或每天在云中。 而每GB还是TB?”您会发现可能是一些相对较新的数据库,例如Mongo或Cassandra,它们的价格可能更便宜,因此,如果您要处理多PB型的大数据,您可能会发现从成本的角度来看,必须考虑云中的NoSQL数据库,因为它们可能是最经济高效的方式。

罗宾·布洛尔:是的,是的。 我的意思是,根据我的经验,关系数据库已经足够长了,可以肯定会产生伤疤,这是可以肯定的。有很多常识,如果您开始应用它,并且-了解关系实际上是什么,那,我的意思是,我记得曾经与一位客户进行过一次咨询,他们带领我进入一个房间,他们完成了一种实体图并创建了第三种标准形式,即公司主要系统的模型。 它大约有240张桌子,他们说:“好吧,您对此有何看法? 我们将为此建立一个数据库,”他说:“您对此有何看法?”我说:“我认为它不会起作用。”这是完全正确的,因为他们即将结束以便在十一向联接中创建特定的结构。 这就是关于关系的理解。 因此,我对您遇到多少不良设计感兴趣。 我的意思是,我对DBArtisan没任何问题-它做的很明智,而且您实际上可以在多个平台上展示的事实,我认为这很棒-但是您在设计问题所在的地方会遇到多少人们知道,如果他们沦落为星状图谱而不是一头雾水,该如何解决自己的各种心痛呢?

伯特·斯卡尔佐(Bert Scalzo):好吧,我不想听起来像个自大或自大的人,但我会经常说。 显然,我参与其中的大多数数据库都存在问题。 这样做很好,因为我们的工具(如数据库优化器工具)可以帮助他们解决这些问题,但是让我真正有趣的是,很多问题都是一遍又一遍的相同简单问题。 前几天我正和一个有十一路联接查询的客户一起工作,我想:“好吧,为什么不使用with子句?”他们就像是:“嗯,我没有我不知道那是什么。”然后我说:“然后在这里查看相关和不相关的子选择。”我说,“在某些情况下,您的where子句中的层级最高,我说:“就是说,将其移到正确的级别,不要将其嵌入到比必须的深度更深的位置,您将使优化器感到困惑。”然后,通过一些调整,我们花费了大约两个小时的时间,然后将其减少到十分钟,这只是-在那种情况下,我们除了改善他们编写的SQL之外没有做任何其他事情。 我认为问题在于,许多大学和很多人在非学术环境中学习编程,他们以记录时间的过程或面向行的过程来学习它,而关系是天生的面向对象,所以您必须考虑在集合中编写好的SQL。

Robin Bloor:是的,我认为这是完全正确的。 而且您必须了解,诸如此类的事情,人们应该了解此类内容的基础知识。 没关系 如果您没有意识到即使是一个设计良好,建模良好的数据库,联接也将花费时间,排序将花费时间,那么您将无法做理性的事情。 他们之所以这样做,是因为世界从未找到过使它们快速发展的方法。 他们找到了组织数据的方法,因此可以比其他方法更快地运行,而我对NoSQL数据库的很多热情仅是因为他们避免进行联接。 他们只是开始建立具有相同数据散布的数据库,因为如果您加入任何NoSQL数据库,它们的性能将非常强大。 你不觉得吗

伯特·斯卡尔佐:哦,绝对。 我不得不笑,因为,我回到关系数据库之前,回到Ingres还是RTI,关系技术研究所,那时我们没有SQL,而是有SQL之前的关系语言。 我认为在Ingres中,当时称为Quel。 因此,您从网络和更高的图形或层次结构这些旧的数据库范式中获得,几十年后您经历了关系范式,现在对我来说,感觉就像我们又回到了几乎层次结构一样。 几乎就像我们已还原一样。

罗宾·布洛尔:是的,是的。 最好把您交给埃里克(Eric),我花了太多时间,但是埃里克(Eric)观众有什么问题吗?

埃里克·卡瓦纳(Eric Kavanagh):我们做到了,我们有几个。 我们这里要走很长一段时间,但我会给你扔几个。 关于隐式索引,我们有几个问题。 一个问题是,“有人需要使用您的工具才能看到它们吗?”另一个问题是,“好吧,如果您是盲人呢?”

Bert Scalzo:很好。

埃里克·卡瓦纳(Eric Kavanagh):好奇的问题也是如此,仅供参考。

Bert Scalzo:不,您不必拥有我们的工具。 这是Oracle的功能,即不可见索引。 基本上,在数据字典中,Oracle只是保留了一条元数据,上面写着:“优化程序,忽略此索引。 它在这里,但是除非您通过SQL命令中的优化程序提示中的提示实际得到指示,否则不要使用它。”因此,不,您不必拥有我们的工具,并且在各个方面是一个普通的旧索引,您可以在任何工具中看到它,只是优化器会说:“我们将在常规查询处理中将其忽略。”如果要使用它,则必须对其进行定向。 对于我所描述的场景,这很方便,如果您想在生产中建立索引,但又不冒险破坏报告或已经运行的事物,但是想要测试它们,则可以这样做。 那是最有用的。

埃里克·卡瓦纳(Eric Kavanagh):那是好东西,然后这里还有另一个好问题。 “这些新的内存数据库怎么样? 内存数据库技术如何在索引方面改变游戏规则?”

伯特·斯卡尔佐(Bert Scalzo):天哪,我们-很好,我很高兴有人问这个问题,我们将不得不再走半个小时。 不,在内存中,这取决于数据库供应商。 现在,通常来说,我只是对甲骨文所做的一切表示赞赏,因为它们使他们构建的技术令人赞叹,但是当您翻开内幕,看看甲骨文中的内存是什么时,在数据库中,实际上它仍然将行存储在磁盘上,并且将在内存中加载列存储,并且如果没有足够的内存来容纳整个表,它将恢复为部分存储; 它不适合存储在内存中,无法进行行存储,因此您实际上可以对表进行选择,对于一半的表,您正在使用索引来击中表的传统行,而对于另一半选择它实际上是在进行中,只是从内存中搜索中获取所有内容,因此,例如,SQL Server使用其Hekaton技术(您知道)和SQL 2014来实现它的方式有所不同,并且它得到了改进在SQL 2016中,但在某些方面,它们是内存的更真实版本,但是,每个实现都有其优缺点,但是您必须有所了解并实现。 因为,我有一个客户说:“哦,该表在内存中-我将要绘制所有索引,”而我想,“该表大于服务器上的内存,因此在某些时候,某些查询必须进入磁盘。”

埃里克·卡瓦纳(Eric Kavanagh):这是一个很好的描述。 那是好东西。 好吧,伙计们,今年余下的时间里,我们将与这些人再进行一些网络广播,只要您知道伯特正在做演讲,就回来,因为我们知道他知道他的东西。 与专家交谈总是很有趣。 我们确实将所有这些网络广播存档,以供以后查看。 再次是Bert的联系信息,我们将尝试挖掘该链接以进行下载并通过电子邮件将其发送出去,但是您始终可以通过电子邮件真实地向您发送电子邮件:,我们为此安排了很多网络广播一年,我们现在正在编辑,所以,伙计们,如果您真的想了解明年的任何话题,请不要害羞:保重,伙计们,我们下次再聊。 再见。

Techopedia内容合作伙伴

Techopedia员工隶属于Bloor Group,可以使用右侧的选项与他们联系。 有关我们如何与行业合作伙伴合作的信息,请单击此处。
  • 轮廓
  • 网站
索引混乱:如何避免数据库混乱