话题中间件与数据库 › PostgreSQL

中间件与数据库:PostgreSQL

PostgreSQL逻辑复制解密

在数字化时代的今天,我们都认同数据会创造价值。为了最大化数据的价值,我们不停的建立着数据迁移的管道,从同构到异构,从关系型到非关系型,从云下到云上,从数仓到数据湖,试图在各种场景挖掘数据的价值。而在这纵横交错的数据网络中,逻辑复制扮演着极其重要的角色。

让我们将视角从复杂的网络拉回其中的一个端点,从PostgreSQL出发,对其逻辑复制的原理进行解密。

京东云PostgreSQL在GIS场景的应用分享

在地图或地理信息有关的场景里,地址关键词的检索尤其重要。比如打开百度地图,想要查询某个位置的信息“北京市海淀区清华东路17号中国农业大学”,往往我们输入的是关键词“中国农业大学”而不是精确到街道的详细地址信息。在地址关键词检索的背后,需要的是一款可以支持全文检索和模糊查询的数据库与之匹配,以此快速提高地址检索的效率。

PostgreSQL中使用FDW+MV玩转数据同步

经常有这样的 case ,业务线开发同学需要 DBA 帮助其在不同的 PostgreSQL 数据库或集群之间同步数据。

数据量较小时,使用 pg_dump 工具或 copy 命令即可完成同步需求。但当数据量较大时,直接同步数据容易引发源 DB 或目标 DB 出现 slow query 或主从同步延迟等问题,容易对数据库的性能及稳定性造成不良影响。

而且无论数据量大小与否,有时候手工或写定时任务同步数据都很容易出错,且目标DB的数据如果恰好有人在使用极易与同步数据的任务相互阻塞。

是否存在其他数据同步方案避免上述问题呢?通过调研加实践,PostgreSQL中运用FDW与Materialized View可以较好的优化上述问题。

TDSQL-C PostgreSQL(CynosDB) 内核解密-披荆斩棘,勇往直前的腾讯云数据库

从数据库内核的角度揭秘TDSQL-C PostgreSQL的核心架构与关键技术。

Oracle PostgreSQL MySQL中 Sequence 的使用

一道 Sequence 的“开水白菜”,敬请“享用”。

纯干货!一文学会 PostgreSQL 实现表分区的方法

一个表的数据量达到一定程度后,稳定性和性能就会出现瓶颈,"化整为零"对DBA 来说无疑是一个很好的选择,此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案,本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

PostgreSQL数据目录深度揭秘

PostgreSQL是一个功能非常强大的、源代码开放的客户/服务器关系型数据库管理系统(RDBMS),PostgreSQL被业界誉为“先进的开源数据库”,支持NoSQL数据类型(JSON/XML/hstore),主要面向企业复杂查询SQL的OLTP业务场景,提供PostGIS地理信息引擎、阿里云自研多维多模时空信息引擎等。

本文着重介绍PostgreSQL的数据目录,其中保存着配置文件、数据文件、事务日志和WAL日志等重要文件,所有客户创建的数据文件和初始配置文件都可以在数据目录中找到,因此数据目录是重要的客户价值所在。

PostgreSQL at Scale: Saving Space (Basically) for Free

Re-ordering table columns to avoid wasting space for data type alignment.

PostgreSQL at Scale: Database Schema Changes Without Downtime

Braintree Payments uses PostgreSQL as its primary datastore. We rely heavily on the data safety and consistency guarantees a traditional relational database offers us, but these guarantees come with certain operational difficulties. To make things even more interesting, we allow zero scheduled functional downtime for our main payments processing services.

PostgreSQL如何查找某一事务中的完整SQL

DBA 经常需要排查某一个事务中有哪些 SQL 的场景。典型的 case 就是 DB 有一个 lock 报警,从系统表中查看发现是1个 update 等待的 SQL 是1个 select。熟悉 PostgreSQL 的同学都知道:在 PostgreSQL 中,由于特有的 MVCC 机制,读不阻塞写,写不堵塞读。

那么为什么会产生这种 lock?

实际就是因为这个 select 处于一个事务中,事务中有其他 update/delete 等写入操作持有后面的其他事务中的 update 操作所需要的 lock。此时就需要到 DB log 去排查这个 select 所处的事务的完整的全部 SQL,反馈给业务线的开发同学,以便于进一步优化。

PostgreSQL 中如何控制行级安全和列级安全

最近有业务线的同学向 DBA 提出这样的需求:“我的表里有很多敏感数据,怎么给使用者(从 DBA 角度来看就是 DB User)指定查看某些特定行或某些列的权限?”

这是我们经常用到的业务场景,比如最典型全公司的短信数据和用户管理平台场景,如何限制各部门仅可查看属于本部门的某些非敏感数据?

PostgreSQL 为了符合各种场景的安全需求,它的权限控制非常完善,它在各个级别上都具有广泛的安全功能。接下来我们来看一下在 PostgreSQL 中利用行级安全和列级安全来解决上述问题。

PostgreSQL 锁等待监控 珍藏级SQL - 谁堵塞了谁

Everything about database,business.(Most for PostgreSQL). - blog/20170521_01.md at master · digoal/blog

Practical Query Optimization for MySQL and PostgreSQL

  • «
  • 1
  • »

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.124.0. UTC+08:00, 2024-04-20 20:05
浙ICP备14020137号-1 $访客地图$