北京APP开发公司

《北京APP开发公司》由会员分享，可在线阅读，更多相关《北京APP开发公司（5页珍藏版）》请在金锄头文库上搜索。

1、北京 APP 开发公司之 PostgreSQL 是什 么PostgreSQL是以加州大学伯克利分校计算机系开发的POSTGRES ,现在已经更名 为PostgreSQL，版本4.2为基础的对象关系型数据库管理系统（ORDBMS）。PostgreSQL 支持大部分 SQL 标准并且提供了许多其他现代特性：复杂查询、外键 触发器、视图、事务完整性、MVCC。同样，PostgreSQL可以用许多方法扩展，比 如， 通过增加新的数据类型、函数、操作符、聚集函数、索引。免 费使用、修改 和分发PostgreSQL，不管是私用、商用、还是学术研究使用。早期版本被称为PostgreSQL（发音为Post-g

2、ress-cue-ell）的对象-关系型数据库管理系统（有 一段时间被称为Postgres95 ）是从伯克利写的POSTGRES软件包发展而来的。经 过十几年的发展， PostgreSQL 是世界上可以获得的最先进的开放源码的数据库系 统，它提供了多版本并发控制，支持几乎所有SQL构件（包括子查询，事务和用 户定 义类型和函数）， 并且可以获得非常广阔范围的（开发） 语言绑定 （包括 C C+， Java， perl， tcl，和python ）。PostgreSQL 的数组PostgreSQL 有很多丰富的开箱即用的数据类型，从标准的数字数据类型、到几何 类型，甚至网络数据类型等等。 虽然很

3、多人会忽略这些数据类 型，但却是我最喜 欢的特性之一。而数组数据类型正如你所期望的，可以在PostgreSQL存储数组数 据，有了这个特性，你可以在单个表中实现以往需要多个表才能实现的存储要求。 为什么要使用数组来存储数据，如果你是应用开发人员，那么在数据库中使用同样 的模型来存储程序中的数据，何乐而不为呢。况且这样的做法还能提升性能。下面 我们将介绍如何使用PostgreSQL的数组类型。假设你在一个网站上购买物品，那么你所购买的信息就可以用下面这个表来表示：CREATE TABLE purchases ( id integer NOT NULL, user id integer, item

4、s decimal(10,2) 1001, occurred_at timestamp); 在这个表中，拥有一个数组字段来保持多个商品记录，包括：购买商品的编号数量 价格要往这个表里插入数据的SQL如下：INSERT INTO purchases VALUES (1, 37,15.0, 1.0, 25.0,15.0,1.0,25.0, now();INSERT INTO purchases VALUES (2,2,11.0, 1.0, 4.99, now();一个更有实际意义的例子是标签的使用，你可以用标签来标识购买的物品：CREATE TABLE products ( id integer

5、NOT NULL, title character varying(255), description text,tags text, price numeric(10,2);你可使用基本的查询语句来获取数据：SELECT title, unnest(tags) items FROM products你还可以使用Postgres的GinandGist索引来根据指定的标签快速搜索产品：一一 Search where product contains tag ids 1 AND2SELECT *FROMproductsWHEREtags ARRAY1, 2一一 Search where produ

6、ct contains tag ids 1 OR2SELECT *FROMproductsWHEREtags & ARRAY1, 2PostgreSQL 的缺点 内核必须为广泛的工作负载而工作；它并不总是执行得象一些用户社区所希望的那 么好，这可以说不足为奇。PostgreSQL关系数据库管理系统项目是一个有时感到 有些冷落的社区。在响应2014年“Linux存储，文件系统，和内存管理”峰会组织 者的邀请时，PostgreSQL 开发商RobertHaas， AndresFreund 和JoshBerkus 到场 来讨论了他们最痛苦的问题和可能的解决方案。PostgreSQL 是一个很老的系统

7、，可以追溯到 1996；它被很多用户在多种操作系统 上运行。因此，PostgreSQL开发商被他们可以添加的Linux指定代码的数量所限 制。它是基于合作进程的，没使用线程。系统V共享内存用于进程间通信。重要 的是， PostgreSQL 维护它自己的内部缓冲区，但也使用 I/O 缓冲来读写磁盘数据 这种缓冲的组合导致了PostgreSQL用户所经历的一些问题。同步缓慢 第一个被描述的问题是关于数据如何从缓冲区高速缓存保存到磁盘上。PostgreSQL 使用了一种形式的日志记录，他们称之为“预写式日志”。 变化之处首先写入到日志 中；一旦日志安全的保存在磁盘上，主要的数据库块就能被回写。 这个

8、工作中很多 都通过一个“检查点”进程来完成；它写入日志条目，之后将一批数据写回到磁盘上 的各种文件中。 这 种 带 有日志能力的写操作相 对 而言小而 连续 ；他 们 的工作效果不 错，并且，据Andres所说，PostgreSQL的开发者对系统这部分在Linux上的运行 情况足够满意。数据的写入则是另一回事。检查点进程调节这些写操作，从而避免I/O系统压倒其 它一切。但是，当它开始考虑调用fsync()来确保数据被安全的写入，并且所有这 些被调节后的写操作被立即推送到请求队列时，就导致了I/O风暴。据他们说，问 题不是因为fsync()太慢，而是它太快了。它导出如此多的数据到I/O系统，以至

9、 于其它仸何事情，包括应用程序的读请求等，都被阻塞住。 这为用户带来了痛苦， 同样也为PostgreSQL的开发者带来了痛苦。TedTso提问，将检查点进程限定到I/O可用带宽的特定百分比，是否能有帮助。 但Robert回应说，I/O优先级应该更好一些；检查点进程，在其它进程不需要带 宽时，应该更够100%的使用它。使用I/O友好的机制(它会在CFQ调度器中控 制I/O优先级)被提出，但这也有问题：它对fsync()调用发起的I/O操作不起作 用。即使来自检查点进程的数据被写入(并非总是如此)，当fsync()开始真正进 行I/O操作时，优先级没有实施上。RicWheeler 建议， Post

10、greSQL 开发者需要更好的控制他们写入数据的速度； Chris Mason 补充说，当产生 I/O 请求时， O_DATASYNC 选项可以用来给以更好的控制 这里的问题是，这种方式的实现要求PostgreSQL知道存储设备的速度。让我们把讨论的话题放回到I/O优先。由于请求队列的维护是通过I/O调度器实 现的，大部分被PostgreSQL用户所青睐的调度器都倾向于避免使用CFQ调度器 (CompletelyFairQueueing 绝对公平调度器)，或者说根本就没有实现 I/O 优先 机制。 这还不是最糟的，甚至，那些提供了 I/O 优先的地方还限制了请求队列的 长度。一个大数据flus

11、h操作将会快速填满队列，这个时候I/O优先就会失去大部 分的效应。如果没有空间去容纳这些请求队列，一个高优先级的请求将会失活，无 法达到预期的高优先。看来， I/O 优先并不能解决问题。 正确的解决之道看起来仍然是那样的模糊和不着边际。 Ted 说如果 PostgreSQL 的 开发者能提供那种通过运行着的数据库来构建这种I/O模式的小程序，给出一种 方法简单地去复现这些问题，那么，内核开发者就能尝试多种不同的方式去寻求解 决之道。 这样的程序可能类似于 PostgreSQL 的初始化配置脚本，但是一个单独的 小程序是内核开发者社区更想要看到的。双缓冲技术PostgreSQL 需要去做属于它自

12、己的缓冲技术，因为其有很多情况下由于各种原因 会使用 I/O 缓冲。这就会导致一个问题：数据库的数据往往会在内存中被存储两 次，一次是在PostgreSQL的缓冲区，另一次是在页高速缓冲存储器(page cache)。PostgreSQL在一定程度上极大地增加了内存的使用次数，对于一个完整 的系 统 是有害的。大量的内存浪费行为应该被有效地消除。考虑这样一个例子，在PostgreSQL的 cache上有一个脏数据(dirtybuffer )，它比内核所拥有的在页高速缓冲存储器上 的数据要新。当 PostgreSQL 刷新这个脏数据时， 页高速缓冲存储器被重写的这一 重要过程将不会发生，因此，数

13、据也就不同步了。在这种情况下， PostgreSQL 要 是能告诉内核去移除在页高速缓冲存储器上相应的页就能好了，可是， 现实就是， 现在没有好的API能做这件事。据安德鲁(Andres)说调用fadvise()函数的 FADV_DONTNEED 参数是可以的， 实际上， 这将引发指定的页被读出，几乎没人 能很好地理解这种行为，但他们都赞成它不应该用这种方式去工作。他们也不可以 在没有映射到文件处理前就使用madvise()函数，这样做的话，可能大量正在工作 着的进程就会变得非常慢。这种做法看起来不错，但同时也可能在反方向上移动了一些页， PostgreSQL 可能 想要从它自己的缓冲器中移除

14、一个干净的页，但是却在页高速缓冲器里留下了一份 拷贝。可能的情况，或许是一个实际上没有引发I/O的特殊的写操作，或许是一 个将物理页面转换成页高速缓冲器的系统调用。 这些在表面上的讨论是挺多的，但 是却没有那一部分的讨论是能给出确切的结论的。复归对于 PostgreSQL 的用户来说另外一个问题是经常遇到的，在最近的一些内核特性 可能造成了的执行性能上的问题。举个例子，透明大型分页(transparentHuge page)特性对于PostgreSQL的工作负载来说没有任何好处，而且它还明显地变慢 了。 显然，大量时间都被用在那些努力运行着的严密代码上了，但是它们却没有真 正产生空闲大型分页(

15、Hugepage )。于是，在许多的系统中，当透明大型分页(transparentHugepage )功能被关掉，可怕的性能问题就简单地消失了。MelGorman 回答：如果压缩正在损害性能， 这将是一个缺陷。 话虽如此，他在相 当长的一段时间内没有发现任何透明大型分页的缺陷。 还有就是，他说，已经发布 了一个限制进程数量的补丁， 该补丁能在任何给定的时间内执行压缩。不过， 这个 补丁的代码并没有被合并，因为没有人的工作负载曾经遇到因太多进程运行压缩而 引发问题。他认为，也许是时候重新审视那个特定的补丁。另一个痛点来源于区域回收功能，即使整个系统并不缺乏内存，该功能也将在内核 中从一些区域回收

16、页。区域回收减慢了 PostgreSQL 的工作负载。通常最好是在 PostgreSQL服务器上简单的禁用此功能。Andres指出他已经作为顾问多次处理和 区域回收有关的性能问题。 这对他来说是一个很好的赚钱方式。不过如果能修复这 些问题，这将是一件好事。Mel说，区域回收模式是在假设系统中所有进程都纳入到一个单一的NUMA节点 下而写的。 这个假设已经不再有意义了；它很过时了，他说， 这个选项的默认值改 为“of。看起来房间里没人反对这个想法，所以可能会在不久的将来发生一点变化。 最后， PostgreSQL 的开发者指出，在一般情况下，内核升级往往是可怕的。 Linux 内核的性能特点在一个发布版到下一个版本之间往往有很大的不同；这使升级成了 一个不确定的事情。有些关于寻找运行 PostgreSQL 基准的新内核的讨