我们知道postgresql数据库通过数据多版本实现mvcc,pg又没有undo段,老版本的数据元组直接存放在数据页面中,这样带来的问题就是旧元组需要不断地进行清理以释放空间,这也是数据库膨胀的根本原因。本文简单介绍一下postgresql数据库的元组、页面的结构以及索引查找流程。
版本号--V2.17 更新日期:2019-11-13
TBase是一个提供写可靠性,多主节点数据同步的关系数据库集群平台。你可以将TBase配置一台或者 多台主机上,TBase数据存储在多台物理主机上面。数据表的存储有两种方式, 分别是distributed或者replicated ,当向TBase发送查询 SQL时,TBase会自动向数据节点发出查询语句并获取最终结果。
我们知道mysql没有hash join,也没有merge join,所以在连接的时候只有一种算法nest loop join,nl join使用驱动表的结果集作为外表到内表中查找每一条记录,如果有索引,就会走索引扫描,没有索引就会全表扫。
PostgreSQL 12,“世界上最先进的开源关系型数据库”的最新版本,如果没有其他问题,将在接下来的几周时间内正式发布。该项目每年新增大量新数据库功能,坦白地说,这一点非常令人惊讶。同时也是我参与PostgreSQL社区的主要原因之一。
PostgreSQL 的分区表个人认为是 PostgreSQL 比较薄弱的环节,老版本的分区表通过继承表和触发器实现,甚至需要逐个对子表进行索引创建,使用上不方便。 10 版本和 11 版本在分区表的功能上进行了大幅完善,但是当分区表分区数量较大时,分区表的DML性能并不好。 PostgreSQL 12 版本的分区表的性能得到了大辐提升,尤其当分区表的分区数量非常多时,DML 性能提升更加明显。
像微软的SQL Server,IBM的DB2,包括从11发行版本开始的PostgreSQL数据库,在创建索引的语句中都支持include子句。介绍PostgreSQL中的这个特性是我写这篇长文介绍include子句的主要目的。 在详细介绍之前,让我们先简单回顾下(非聚集)B树索引的工作原理以及强大的仅索引扫描(index-only scan)。
接前一篇文章,这里继续介绍在工作中遇到的一个死锁案例。经过对业务模型的抽取分析(后面会介绍表结构和数据,业务模型来源于开源组件的实际业务),模拟得到的死锁日志信息如下:
对于IP地址段查询的场景,PostgreSQL的ip4r插件是一个性能和通用性都比较不错的一个方案,但用户不一定方便使用ip4r,比如在未安装ip4r的公有云RDS上或者使用PostgreSQL以外的数据库
PostgreSQL 的 CTE( common table expressions ) 支持较复杂的查询,比如递归查询等场景, 12 版本之前 CTE 的 WITH 语句都是直接物化的,也就是说 WITH 语句执行一次并保持到一个类似的临时表中,供 WITH 语句外层的SQL引用,当 INSERT/UPDATE/DELETE 做CTE的 WITH 语句时是非常恰当的。
随着传感技术的发展,关系数据库的重要性不断增加。大型天气测量望远镜(LSST)每晚产生20TB,大型强子对撞机(LHC)每年产生30PB的数据。 Google和Facebook等社交网络公司每天都会收集大量人为生成的数据。
随着传感技术的发展,关系数据库的重要性不断增加。大型天气测量望远镜(LSST)每晚产生20TB,大型强子对撞机(LHC)每年产生30PB的数据。 Google和Facebook等社交网络公司每天都会收集大量人为生成的数据。
在最近的生产环境巡检中,发现一个死锁错误。从日志中看,触发死锁的是对表的相同行操作,最终分析和业务操作有关,不过其中涉及到Postgres数据库的外键更新加锁处理逻辑,下面对这个问题展开详细分析。
在学习完第一篇《Docker与PostgreSQL 11.5系列文章(一)Docker的安装》和第二篇《Docker与PostgreSQL 11.5系列文章(二)postgreSQL 11.5安装》之后,继续讨论容器的持久化。“持久化” 简单理解,就是容器被关闭后PostgreSQL数据库的数据是否还存在?
上篇介绍容器相关的基本概念,介绍如何安装docker。如果不熟悉docker的安装,可回到系列文章的第一部分《Docker与PostgreSQL 11.5系列文章(一)Docker的安装》。第二部分主要介绍PostgreSQL11在容器中的安装和使用。
Docker前几年席卷了整个互联网,Docker在互联网很多业务场景都有使用。最近一两年,一些传统行业也在尝试使用,并且看到不少案例。另外,我们一直担心,容器影响数据库的性能,根据近些年的亲身实践,容器对数据库性能的影响很小,也不会影响数据库的并行性。因此,想写一系列文章,简单介绍PostgreSQL在容器中的实践。
GPUDirect RDMA允许直接从PCIe设备到GPU RAM的对等数据加载。对于Linux内核和PostgreSQL的扩展模块,我们通过将NVMe-SSD上的数据库块加载到GPU RAM以及在GPU设备上执行SQL来协同利用此基础架构进行非常快速的表扫描。一旦数据块加载到GPU RAM上,内核函数就会根据提供的SQL(WHERE clause,JOIN和GROUP BY)减少数据大小。在结果中,CPU / RAM将获得比实际表大小小得多的数据大小,并且看起来存储在理解SQL的情况下智能地执行。根据基于SQL星型模式的基准测试,我们的功能可以在80秒内扫描351GB平台;这是大约4.5GB / s的查询处理吞吐量,比通常的文件系统基本I / O实现快2.5倍。此结果表明GPU对I / O密集型工作负载也很有价值,而不仅仅是计算密集型工作负载。
PostgreSQL 之前版本已支持 Json 和 Jsonb 数据类型,支持非关系数据的存储和检索,如果 Json 数据较复杂(层级多、嵌套json、包含数组等 ),之前版本不能方便的检索 Json 数据元素值。 PostgreSQL 12 版本的一个重量级特性是新增 SQL/JSON path 特性,支持基于 Json 元素的复杂查询,文档上关于 SQL/JSON path 内容很丰富,本文仅演示简单的用例。
Postgresql 11.2版本物理复制,startup 进程命令行有时会出现waiting 标识。本文分析了出现waiting 标识的原因。
在OpenShift 3.9 GPU博客中,我们利用OpenShift上的机器学习框架进行图像识别。在OpenShift 3.10博客中的如何使用带有DevicePlugin的GPU中,我们安装并配置了支持GPU的OpenShift集群。在本部分中,我们将在集群上创建更复杂的工作负载-使用GPU加速数据库查询。