用C++写出比MySQL快800倍的数据库,ClickHouse创始人:融合数据库该“卷”的还是性能和速度

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: ClickHouse经历了怎样的演进迭代历程?当前数据库行业面临哪些挑战?AIGC火热发展会给数据库带来哪些新机遇?

导读

在近期结束的阿里云瑶池数据库峰会上,阿里云宣布与全球流行的开源分析型数据库ClickHouse正式签订战略合作协议,成为ClickHouse在中国独家的云服务提供商,并提供具备独有企业能力的ClickHouse版本。借此机会,InfoQ有幸独家专访了ClickHouse创始人兼CTO Alexey Milovidov、阿里云数据库事业部OLAP产品部负责人林亮,围绕ClickHouse演进迭代的历程、双方此次合作的契机、当前数据库技术所面临的挑战和机遇,以及OLAP数据库未来发展趋势等问题展开深度对谈。


作者 | 李冬梅、蔡芳芳

采访 | 王一鹏  

本期访谈由阿里云开发者社区、阿里云数据库事业部、InfoQ联合出品


*本文共计8000+字,预计阅读时间约15分钟


5G、AI和云计算等技术的崛起,把数据库这项传统的底层技术推入到了数智化转型的前沿阵地。


新应用诞生的新数据处理需求迫使数据库不得不快速做出反应以紧跟技术潮流,不被淘汰掉。在面对如此多的需要实时响应的场景时,几乎每一个月就更新一次的ClickHouse成为了新数据库时代的一匹黑马。


ClickHouse于2008年创建, 是一个用于在线实时数据分析(OLAP)的列式数据库管理系统,十年前由Yandex公司首次开发,主要为了给Yandex.Metrica提供支持,Metrica是一个和百度统计、Google Analytics类似的网站数据分析服务,当时仅次于Google Analytics,是世界第二大网络分析平台。


ClickHouse的大规模数据分析性能极强,通过提供一个真正的基于列的DBMS,它允许系统以亚秒级的延迟从PB级的原始数据生成报告。当时的系统已经可以提供每秒十万行的服务器吞吐量,ClickHouse将这一速度提高到每秒数亿行。


经过8年磨砺,2016年起,ClickHouse开始走出Yandex并作为开源解决方案为用户提供支持。


虽然商业化时间不长,但得益于极高的查询处理速度和数据存储效率等优势,在此后几年,ClickHouse的受欢迎程度成倍增长,2017 年,ClickHouse引入国内。如今ClickHouse的开发者和用户已经遍布全球各地。国外的Uber、eBay、CloudFlare、Cisco,国内的阿里巴巴、腾讯、字节、携程、有赞、快手等许多头部大厂都在深度使用ClickHouse技术。


其中,阿里云在3年前就上线了全托管的ClickHouse云产品,目前有全球最大规模的商业化ClickHouse云上集群。


不管是大数据还是DevOps或是其他领域,只要涉及在线分析场景,都能找到ClickHouse的影子,越来越多的企业将ClickHouse作为实时分析引擎来使用。


作为ClickHouse的最初设计者、Github上ClickHouse开源项目的主要提交者,Alexey Milovidov也是高性能C++、分析应用程序和SQL数据库方面的专家。


2019年9月,为了让ClickHouse的技术潜力得到充分发挥,创始人Alexey Milovidov决定整合资源成立一家100%专注于ClickHouse的公司。担任联合创始人和总裁的Yury Izrailevsky此前曾在谷歌领导开发者平台和无服务器云产品。公司同时引入了Aaron Katz领导的世界级业务团队,这都会帮助ClickHouse取得更好的发展。


ClickHouse注册成立公司后,宣布筹集到5000万美元A轮融资,而在随后的两个月,ClickHouse再次宣布完成2.5亿美元B轮融资,此次融资后,ClickHouse估值达到20亿美元。


Alexey Milovidov表示:“我们已经赢得了一个由贡献者、开发者和用户组成的伟大社区,他们的支持说明了我们产品的质量。”


那么,从研发至今,ClickHouse经历了怎样的演进迭代历程?当前数据库行业面临哪些挑战?AIGC的火热发展会给数据库带来哪些新机遇?未来行业到底需要一个什么样的OLAP数据库?


以下为本次访谈视频实录和精华文字整理:

点击「链接」查看完整采访视频


ClickHouse的演进与迭代

InfoQ:非常感谢Alexey和林亮老师接受我们的采访。第一个问题想跟Alexey聊聊ClickHouse数据库的发展历程。ClickHouse从研发至今已经过去了十多年的时间了,行业对OLAP的数据库需求也发生了一些变化,相对应的,ClickHouse这些年做了哪些迭代和演进,能不能请Alexey给我们介绍一下?


Alexey:最初,开发ClickHouse的目的是让它只服务公司内部的业务,所以它对我们来说足够用了。但自从它开源之后,我们看到很多公司也开始使用ClickHouse,用法都不太一样,会有不同的优先排序、不同的需求,所以我们会看到有不同的应用案例。  


当我们只在一个公司内部使用ClickHouse,它是非常完美的,但当它走入成千上万家不同的公司时,所产生的效果就会不一样了。不过在不同的用例中反复打磨后,产品的质量有了明显的改进,另外,它很重要的演进就是拓展了一些不同寻常的用例。如果非要举出一个ClickHouse的特点,那就是它的设计能满足某一个应用的实际生产需求,这样的特点让ClickHouse变得越来越强大。


InfoQ:我们知道ClickHouse的性能很强大,但当它进入到企业环境中后,我们就需要考虑它的弹性能力以及云端部署的问题了。2021 年起,ClickHouse 注册成立了公司开始,独立运营团队就在集中精力解决云端部署的问题,我们想了解下,目前 ClickHouse 上云的进展怎么样了?围绕着云端部署做了哪些工作?


Alexey:ClickHouse 是很灵活的,如果用户想要的话,它可以向上扩容到成千的服务器,但是扩容到数千服务器这个过程本身并不容易,它的演进也是另外一个方式,也就是扩展到另外一个架构上,是一种跨架构的扩容。我们知道这种存储对于我们来说是非常常见的,但是它不需要移动数据就能实现扩容,它能够有更好的扩容效果,像阿里云现在就是在使用这样的方式。


InfoQ:这中间还涉及到一些问题,比如 ClickHouse 在数据一致性还是存在一些需要解决的问题,也正在解决吧?


Alexey:你的意思是更新和删除分析数据库中的数据吗?


InfoQ:是的。


Alexey:是的,这个问题并不容易解决,但是现在有很多的系统,假装在解决这个问题。这类系统就是所谓的HTAP,但问题是现存的系统并不适合,或者说这些系统不是针对分析型需求设计的。如果要优化分析处理,必须应用一些特殊的方法来更新或删除数据才能解决问题,不能只靠数据位置的转变就把复杂的事情变简单了。


InfoQ:接下来这个问题也想问一下林亮老师,阿里云这次和ClickHouse的合作,是否跟云原生改造工作有关,能不能简单介绍一下具体内容?


林亮:我们这边从两年多前就上线了阿里云ClickHouse的版本,经过这段时间的演进,收到了很多用户的反馈和需求,他们在使用ClickHouse的过程中也遇到过这样或那样的问题。目前,据我们所知,阿里云拥有全球最大的商业化ClickHouse云上集群,我们积攒了很多的用户、用例和他们的需求。


本次阿里云和ClickHouse公司的独家合作,就是希望能够在中国大陆和亚太为用户提供一站式的产品。这次合作中就包括了云原生ClickHouse的内核。这当中有哪些技术点是客户真正需要的,我们在合作的前期也都进行过讨论。


在阿里云瑶池峰会上我们提到的SharedMergeTree,它可以把整个弹性做得比原来社区版本更高效。刚才提到的轻量更新和删除,这些都是过往用户遇到的痛点。接下来一两年内,我们可能会发布解决上述痛点问题的新版本,所以很期待新的Serverless ClickHouse这个产品能够帮助客户更好地构建分析型场景。


InfoQ:Serverless版本预计在什么时间发布?


林亮:Serverless版本现在正在研发和推进过程中,我们希望在今年年中或者下半年内发布,我们已经开放了早期的白名单注册,我们的内测版本可以提前给到大家来试用一下。


就数据库来讲,上云是必选项吗?

InfoQ:也想问问Alexey怎么看这次在国内和阿里云的合作,对于ClickHouse来说意味着什么?


Alexey:我们会在中国寻找一些云的合作伙伴,目前为止,阿里云对我们来说是最给力的合作伙伴。


InfoQ:现在,大家普遍认为我们正处于云原生时代。在两位看来,对于ClickHouse在内的大数据和数据库类的项目来说,上云是不是一种必然选项?林老师刚刚也提到,服务弹性扩缩容也会对原来的性能有一定的影响。ClickHouse 最开始服务的业务场景可能并不包括云上场景,但是现在在阿里云上的服务就是云上场景,所以这是不是必然的选项?先请林亮老师聊聊。


林亮:就上云问题而言,我们看到目前用户使用数据的方式变得越来越复杂,首先是数据量增长越来越快,随着一些热点的发生,计算也出现很多不可预期性,复杂的查询对系统也带来了一定影响。另一方面,整个用户都在考虑如何能够更好地降本增效,能够更高效地使用当前的系统。


回看整个云时代,从本质上来讲,云是把很多以前每个厂家不同小的“水井”合并在一起,汇聚成了无边无际的江河湖海。当更多的应用上云后,云的资源量使用更大,整个边际成本就开始往下降,这些红利就返回给了客户。


像ClickHouse的云、阿里云自己的产品等这些云原生产品都是在更好地满足客户不同的数据处理和分析的需求,运用云本身所提供的高可用、易运维等特性更好地支持他们的应用场景。


对于是否一定要上云的问题,其实用户的选择各有不同,有些客户出于安全和合规等考虑,依然是在线下的。但是如今,Gartner分析师也指出,数据库的未来就是上云,可以看到,现在绝大数的客户都在往云上迁移,我们也相信这会是数据库未来的发展趋势和演进方向。


InfoQ:现在上云的场景和ClickHouse最开始设计的场景好像是完全不同的,最初设计ClickHouse时它的场景是单机的,但自从独立成立公司后,看起来上云变成了公司非常重要的战略,所以Alexey是怎么看待这个问题的?


Alexey:云确实是很重要的战略,但ClickHouse的优势是在任何地方都可以运行,包括在云上、本地部署、边缘设备上它都能完美地运行。所以显然它也应该匹配云上的需求,云是使用ClickHouse最简单的方式,而且有可能是最好的方式。


InfoQ:但是中间还是经过了相当多的改造工作的吧?因为我知道业内有很多公司和团队其实在围绕ClickHouse做改造。


Alexey:确实有很多部分需要专门为了云重新开发,比如我们不得不专门为云环境实现一个表引擎,原来的ReplicatedMergeTree对云架构匹配不是特别好,尤其当使用对象存储的时候。我们要做一些不一样的事情,我们需要让计算节点能独立于存储节点扩展,实现在所有计算节点之间并行查询,当我们使用不同的存储时都要做到非常高效的查询。


云的对象存储和本地磁盘、内存等是不一样的,需要做不少工作,对象存储是另一种完全不同的“怪兽”。


InfoQ:这些刚才我们提到的发生在公司和组织间的改造,会和我们商业化的路径或者上云的路径形成一种竞争关系吗?这个问题Alexey怎么看?


Alexey:肯定会有竞争关系,竞争是很正常的,这在我们意料之中,大家其实也想效仿ClickHouse与我们进行竞争。换个角度看,ClickHouse和我们正走在行业前列,引领这个行业,让其他人在后面追随。


InfoQ:Alexey提到这个问题恰好是我接下来要问的问题,既然有竞争关系,肯定也要分析彼此的优势在哪里?因为我们是研发了ClickHouse这个产品,我们除了更熟悉它,还有哪些其他方面的优势?


Alexey:其实会有一些很有意思的方向,我只举几个例子。比如ClickHouse不仅是分析型数据库,它也是一个流处理平台。想象一下,如果同时使用 ClickHouse和Kafka,但出于某种原因你对Kafka不满意,觉得Kafka还不足以满足需求,你想把ClickHouse单独使用,而恰巧ClickHouse具备了独立处理、生成、转换数据流在内所有工作,那这时你一定会爱上ClickHouse。还有一种可能,比如让ClickHouse具备批处理能力和ELT,甚至更强的能力,比如内置AI能力,这样用户就能基于AI模型来写函数,这些想法听起来是不是也很让人兴奋?


InfoQ:那您能从团队和人才能力层面聊聊这个问题吗?因为现在很多团队都在做改造,ClickHouse公司作为ClickHouse项目的创始团队,理论上来讲应该是最了解这个产品的,是不是意味未来在发行版或改造版迭代时,我们仍然是最适合大家场景的、最能满足大家需求的这样一个产品?


Alexey:其实,我们团队的大部分成员已经是ClickHouse的贡献者,他们已经对ClickHouse原代码很熟悉了,他们知道ClickHouse是怎样运作的,他们了解ClickHouse代码和架构目标就是要尽可能简单和易于使用。我们可以看阅读源代码、阅读注释,我们更熟悉ClickHouse的代码库,这就是为什么我们社区有很多贡献者。


InfoQ:看来竞争对手先要成为ClickHouse社区的主要贡献者,然后再参与到其中来对吧?


Alexey:是的,有一些从前的社区贡献者后来成立了新公司,可能会直接跟我们竞争,但这也没关系。竞争可以带来一些新构思,我们对此非常欢迎。


InfoQ:林亮老师怎么看待这个问题?


林亮:就像Alexey说的,其实有更多的人参与到这里面来也能更好地帮助整个社区成长。那么为什么ClickHouse在阿里云上会更好?据我们了解,阿里云上的 ClickHouse集群目前是国内最大的ClickHouse集群,这里有多年来积累下来的客户场景、最佳实践和用例,此外,多年来我们和客户一起打磨下来的、更贴近场景的功能是很有竞争力的。


另外,阿里云本身所能提供的安全性、可靠性和整个基础设施迭代上的保证,能够更好地支持这些To B企业安心地基于ClickHouse来构建企业级应用。


最后,我们已经运营了ClickHouse差不多两到三年的时间,我们也期待后面跟 ClickHouse的合作碰撞出更多火花,让产品能够基于阿里云能力之上,借助ClickHouse本身的技术的实力和优势,真正打造出一款最具竞争力的分析型数据库,帮助用户更好的成长。


InfoQ:现在国内最大的ClickHouse集群是在阿里云客户服务这里吗?


林亮:从我们了解到的信息是这样的,无论是单客户还是整体客户体量上我们都是比较大的。


数据库未来的发展趋势

InfoQ:另一个问题想问一下林亮老师,目前业内很多开发者认为大数据行业整体的技术是比较复杂的,涉及到的组件、工具都比较多。ClickHouse最初面世的时候,大家觉得它是在OLAP这个场景下把性能推到了极致。接下来行业内的从业者会面临两个选择,一个是大数据的工具和要写的代码呈现出融合的趋势,大家没有那么复杂的场景和工具需要考虑。还有一个方向仍然是百花齐放的状态,比如你在 OLAP场景用什么、OLTP场景用什么,工具依然相当分散,林老师觉得接下来的演进趋势会是哪一种?


林亮:我觉得有两个演进的趋势:一个趋势是融合。我们也看到业界有两种融合的方向,一种融合是指我们一直在提的湖仓一体,我们看到无论是SnowFlake还是 Databricks,都开始把它的湖往仓这个方向扩展。

另一个融合就是我们刚才提到的HTAP(在线和离线的结合),我们也看到有很多的数仓在往这个方向发展,就是在单产品之内把自己边界真正做到融合的覆盖不同的场景。此外还有我们在瑶池峰会上发布的整体的一站式解决方案。让数据库各个产品之间数据能够更好地自由流通,而不需要搭建这么复杂的组合方案。去年AWS在re:Invent上发布的Aurora和Redshift zero-ETL,其实也是这样的思路和方向。整体目标也是希望用户的数据处理架构和设施搭建起来能够更方便。

另一个趋势是多样化。我们也看到,无论从场景还是使用上,数据分析变得越来越复杂。所以我们觉得后面还是会针对不同的场景和特殊用例思考怎么做得更极致、更高效来设计产品。我觉得业界这种多样化的趋势还会存在的,随着这些场景和产品出来,它们可能后面又会被融合到当前的系统里去,所以我觉得整体上融合和多样化会是并行发展的趋势。本身技术上不一定融合好或者多样化就好,更多还是怎么能够更好地解决用户场景,要让用户真正做到一站式数据的使用,帮助他们真正地解决问题。


InfoQ:Alexey怎么看这个问题,您觉得融合还是会继续各个领域分别发展?

Alexey:我觉得有些公司在将不同的技术用于不同的用例中,但我觉得这不是最佳的方案。如果用十几、二十几个技术,那么架构就会变得更加复杂,甚至可能会崩溃。我觉得很多场景还是在融合,我也看到了不同技术融合在一起的可能性,包括数据分析处理、交易处理、流处理,甚至键值数据库 ETL,他们在用更简单、更加高效的方式将解决方案融合在一起。

为什么不把一个产品变成全能产品呢?虽然不是马上就能实现,但我看到了有这样融合的可能性。如果一个数据库就能解决的问题,为什么要用另外一个数据库呢?如果要用到搜索,为什么分析型数据库不能做搜索?为什么要用专门的数据库进行机器学习的向量搜索?我认为其实不需要专门的数据库,很多个需求都可以融合到一个解决方案中,也可以行之有效。当然有的时候融合并没有那么容易。


InfoQ:可能阻碍大家做融合的第一个问题是性能,是不是融合到一起势必要牺牲一些性能,ClickHouse最开始引得大家这么大的关注,在社区内火的这么快,也是因为ClickHouse性能非常突出,Alexey觉得做融合数据库时会不会牺牲掉一些性能?

Alexey:我认为这主要是聚焦方向的问题,当团队不大的时候一定要找到优先级排序。对于ClickHouse来说,最优先考虑的始终是性能和速度,如果说同一时间任务太多、太分散,有可能最后给到大家的就是一个半吊子的解决方案,哪个方面都不能做到极致。我不希望给到大家一个很普通的东西或者半成品。虽然不能什么都要,但要做就一定要做到最极致。

AI大火,为数据库行业带来哪些机遇?

InfoQ:接下来我们来聊一聊最近非常火的AI。这里想问问林老师,您认为AI能够给数据分析和整个数据库行业带来哪些新的机会或者机遇?过去AI技术和数据分析多有结合,典型的就是BI的场景,但是好像这些年发展下来,至少在国内的发展没有达到大家的预期,接下来ChatGPT通用人工智能的发展会给数据分析带来什么新的机会吗?

林亮:这部分内容我不是专家,我的观点可能是抛砖引玉了。我觉得AI和数据库的互相推动主要体现在两个方面:一方面是数据库本身对数据的清洗、数据的管理能够给AI带来很好的思路。因为很多企业最核心的数据和最有价值的数据还是存在数据库里,这些已经清洗过的、最有价值的数据对AI一个很好的输入。

另一方面,数据库本身所提供的无论是权限,还有对应的可靠性、可用性的能力,是他们想使用 AI 一个更重要的点。很多企业跟我们聊的时候会说,ChatGPT非常火,但要把这个技术变成一个企业级应用的时候,一些数据处理的技术是相当关键的,数据库这么多年积累下来的技术会对这方面的工作有很大帮助。


InfoQ:后面会不会大家在用一个大数据产品的时候,就没有UI的概念,可能提一些(Promote)实现比较复杂的数据服务或者获取一个数据赋能给它的结果?这些对于数据库来说都会是利好吧?

林亮:对,我觉得这会是大的方向。整体来说,我们之前一直提到,数据湖最大的问题就是数据太多了,不同的format、不同的信息散落在各个地方,怎么更好地聚集在一起,更好地分析湖上的数据,这也是湖仓一体系统需要解决的问题。

这些东西通过数据库汇总到一起,整个上层GPT就可以更好地分析。再往前一步讲,现在很多客户进BI报表,一开始都是把几十个图表放在一个页面上,分析起来也很不方便。像微软在PowerBI上已经有Demo出来了,用户提一个问题,Demo直接把关键问题的答案反馈给你,所以如何帮助大家更好地访问和使用数据,把数据的价值充分挖掘出来并创造出更大的价值,这不仅是GPT要解决的问题,也是整个数据库或者数据分析这个产业和所有同行们一直在追求的终极目标。

InfoQ:Alexey怎么看AI热潮给数据库和ClickHouse带来的机会,咱们现在是否也在关注AIGC技术和ClickHouse的结合?

Alexey:是的,我们看到了一些两者相结合的可能性,主要是偏前沿技术方面。现阶段,AI 可以协助设计查询语句、自动补全,目前可能还做不到像我们预期得那么强大,但看上去是可行的。AI能够给出正确的查询,但如果我们需要做更加复杂的工作,它经常会出错。你必须重新调试并检查实际生成的SQL语句,但是确实现在已经证明了它是能做到的。如果我们能让AI变得更加强大同时降低成本,不需要再花几千万去训练,我觉得那个时候的可能性可能会更高一些。


InfoQ:Alexey所说的两者结合的可能性是服务于什么场景,是现在ClickHouse应用性更好了,还是本身在功能层面会出现一些创新?

Alexey:有一些显而易见的方面,但不是用于核心数据库的,这些部件主要是用于用户界面,可以协助用户编写和纠正查询语句,可能自动执行数据探索。比如你有一个数据库,你只是想以某种方式把其中的数据呈现出来让数据结构更易于理解,也许可能对于内部的数据结构和算法应用AI会更难一些,特别是机器学习的数据结构。但这可能无关乎ChatGPT而是更加传统的机器学习。也许未来我们会找到更多的可能性。


InfoQ:咱们现在内部有尝试用ChatGPT辅助我们写代码吗?

Alexey:没有,因为现在这么做没有意义,而且太昂贵了,我们只是做一些小范围的实验性工作。


展望OLAP数据库的未来趋势

InfoQ:接下来,我想问一个关于趋势性问题,也想请两位聊一聊,在接下来十年间,行业内会需要什么样的OLAP的数据库?

林亮:我觉得OLAP数据库会朝着三个方向发展。

一个趋势是:数据库和云的结合。我们此前也提到过,原来是讲数据上云,现在是讲“数据 + 云”,就是怎么能让OLAP产品利用好云的技术,包括怎样做到更好的弹性、怎样更好地利用好云的资源、如何帮助客户更好地应对降本增效的要求,我觉得这会是一个方向。

另外一个趋势是湖仓一体。我们每天所产生的数据量是相当大的,但我们现在能够管理和应用的数据还是很少的一部分,所以怎么能够做更深度的探索,把湖和仓更好地统一和管理起来,进一步挖掘数据价值,同时也基于平台更好地分享数据,是所有从业者当下要着重思考的问题。现在国家有数据局来做管理,我也认为后面整个数据会更规范化、标准化,会有更多的共享,所以数据的隐私保护,也是未来 OLAP系统需要具备的能力。


最后一个趋势是数据库与AI的结合。这要分方面看:一个是AI本身能够帮助数据库做到更好更优的调优和调整;另外一方面是AI到后边也会变成数据库的“一等公民”,就像SQL函数一样,可能会成为数据库的标准能力,怎么更好地把AI这些能力集成在一起使用也值得关注。


InfoQ:林老师聊的还是挺全面的,Alexey怎么看待数据库未来发展趋势的问题?

Alexey:我觉得还有一些没有解决的问题有待解决。数据清理、数据准备、弄清楚数据结构等问题可能看起来很简单,对于非结构化数据或者半结构化数据,其实很难获得跟结构化数据相同的性能。所以首先需要定义数据的结构,有时候你必须编写脚本来清理数据。比如客户给你一个数据表,你要把它整合到数据库当中,这些问题上也许AI可以提供帮助。


嘉宾简介:

Alexey Milovidov,ClickHouse创始人及CTO

林亮,阿里云数据库事业部OLAP产品部负责人。曾就职Google十多年,在超大规模SQL Engine和规模存储引擎上经验丰富。目前负责阿里云OLAP产品部。


云数据库ClickHouse是分布式实时分析型列式数据库服务。具有高性能、开箱即用、企业特性支持。广泛应用于流量分析、广告营销分析、行为分析、人群划分、客户画像、敏捷BI、数据集市、网络监控、分布式服务和链路监控等业务场景。

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
3天前
|
人工智能 运维 关系型数据库
云栖大会|数据库与AI全面融合,迈入数据智能新纪元
2024年云栖大会「数据库与AI融合」专场,来自NVIDIA、宇视科技、合思信息、杭州光云科技、MiniMax等企业的代表与阿里云瑶池数据库团队,共同分享了Data+AI全面融合的最新技术进展。阿里云发布了DMS的跨云统一开放元数据OneMeta和智能开发OneOps,推出《云数据库运维》技术图书,并介绍了PolarDB、AnalyticDB、Lindorm和Tair等产品的最新能力,展示了AI在数据库领域的广泛应用和创新。
|
2天前
|
缓存 监控 关系型数据库
如何根据监控结果调整 MySQL 数据库的参数以提高性能?
【10月更文挑战第28天】根据MySQL数据库的监控结果来调整参数以提高性能,需要综合考虑多个方面的因素
27 1
|
2天前
|
监控 关系型数据库 MySQL
如何监控和诊断 MySQL 数据库的性能问题?
【10月更文挑战第28天】监控和诊断MySQL数据库的性能问题是确保数据库高效稳定运行的关键
7 1
|
2天前
|
缓存 关系型数据库 MySQL
如何优化 MySQL 数据库的性能?
【10月更文挑战第28天】
12 1
|
7天前
|
Java 数据库连接 数据库
优化之路:Java连接池技术助力数据库性能飞跃
在Java应用开发中,数据库操作常成为性能瓶颈。频繁的数据库连接建立和断开增加了系统开销,导致性能下降。本文通过问题解答形式,深入探讨Java连接池技术如何通过复用数据库连接,显著减少连接开销,提升系统性能。文章详细介绍了连接池的优势、选择标准、使用方法及优化策略,帮助开发者实现数据库性能的飞跃。
16 4
|
5天前
|
Java 数据库连接 数据库
深入探讨Java连接池技术如何通过复用数据库连接、减少连接建立和断开的开销,从而显著提升系统性能
在Java应用开发中,数据库操作常成为性能瓶颈。本文通过问题解答形式,深入探讨Java连接池技术如何通过复用数据库连接、减少连接建立和断开的开销,从而显著提升系统性能。文章介绍了连接池的优势、选择和使用方法,以及优化配置的技巧。
10 1
|
6天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
40 2
|
9天前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
40 4
|
4天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
19 0
|
5天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第26天】数据库作为现代应用系统的核心组件,其性能优化至关重要。本文主要探讨MySQL的索引策略与查询性能调优。通过合理创建索引(如B-Tree、复合索引)和优化查询语句(如使用EXPLAIN、优化分页查询),可以显著提升数据库的响应速度和稳定性。实践中还需定期审查慢查询日志,持续优化性能。
25 0

热门文章

最新文章