Home » Computer » Software » Database » Archive by category "PostgreSQL" (Page 3)

PostgreSQL 上,直接將 SSD 的內容送到 GPU 上,加速讀取速度

PostgreSQL 上針對讀取檔案到 GPU 上的成果:「GpuScan + SSD-to-GPU Direct DMA」(日文版)、「(EN) GpuScan + SSD-to-GPU Direct DMA」(英文版)。

主要的原因在於雖然已經有 PGStorm 讓 PostgreSQL 把運算丟到 GPU 上加速,但從 disk 讀到 GPU 這段還是有改善的空間:

PG-Strom that is an extension of PostgreSQL to off-load multiple SQL workloads on GPU devices, transparently. It has been developed for four years, and now supports simple scan, tables join, aggregation and projection.
Its prime focus is CPU intensive workloads, on the other hands, it didn't touch storage subsystem of PostgreSQL because the earlier version of PG-Strom assumes all the data set shall be pre-loaded onto physical memory. No need to say, we had a problem when we want to process a data-set larger than physical RAM.

這是成果,可以看到速度快了一倍以上:

這對資料量超過 RAM 大小時的處理會非常有幫助 (因為會有大量的 disk i/o 發生)。

Yandex.Mail 從 Oracle 搬移到 PostgreSQL 上的故事

Hacker News Daily 上看到 Yandex.MailOracle 搬到 PostgreSQL 的故事:「Yandex.Mail success story」。

首先是在 Oracle-based 的系統上遇到的問題:

除了技術類的問題外,這個「Not very responsive support」可以看到對 Oracle 的服務很不滿意。

另外下一張投影片只講 shop.oracle.com 是主要原因... 我猜是 Oracle 在開始提供 cloud service 後把售價都拉高。在最後的 Summary 看起來也有點像:

雖然沒有講明換 PostgreSQL 的理由,但注意到「3x more hardware」這點,這表示是原來的四倍。在這樣的情況下還是要換,可以猜測 Oracle 的授權費用在 web-scale 服務上的問題。

另外如果仔細品投影片,可以發現其實 migration 成功的原因是 DBA team 的能力夠強大,以及充足的時間修正問題 (可以看到作者在 mailing list 上一直提問也一直修正問題)。如果當初評估後決定要換到 MySQL,我相信也是會順利完成...

最近討論 Uber 的 MySQL 換 PostgreSQL 後又換回 MySQL 的文章...

先把兩份連結丟出來,一份是 PyPgDay 2013 時由 Uber 的 Evan Klitzke 給的「Migrating Uber from MySQL to PostgreSQL」,原 PDF 連結已經失效 (看起來已經被刪除),但這個網路年代什麼都可以找到備份... 可以在「Migrating Uber from MySQL to PostgreSQL」取得,但這個網站怪怪的,我另外丟了一份到 Google Docs 上

另外一份則是同一個人 Evan Klitzke 在 2016 年發表於公司的官方網站上:「Why Uber Engineering Switched from Postgres to MySQL」。

2013 年描述了從 MySQL 換到 PostgreSQL,2016 年同一個人出來則描述了從 PostgreSQL 換到 MySQL 的理由,有種臉腫腫的感覺。

先抓 2013 年的重點,當時分享的目標是要用 PostGIS

在 2016 年的文章絕口不提 PostGIS,而是提到各種效能問題:花了很長的篇幅講 Non-clustered Index 與 Clustered Index 的設計,以及 Replication 時的頻寬效能差異。

先不管 PostGIS,如果真的是 UPDATE 造成效能問題,那麼不是要朝 sharding 解決嗎,怎麼是換成 MySQL?換到 MySQL 後還是會遇到效能問題啊,你還是要在 application 層上面找出方案啊。

這篇文章看起來更像是內部技術與政治問題掛勾在一起談,因為政治原因而換 MySQL,然後找出技術原因說明換的理由 XDDD

A Billion Taxi Rides 資料分析系列

Mark Litwintschik 最近在連載 A Billion Taxi Rides 的資料分析系列作品:

同樣的資料 (而且這個資料量夠大,拿來 benchmark 比較有參考價值),用不同的工具分析,對於要挑工具的人可以看一看,另外也因為裡面給了很多 command sample,要自己動手測試也是個很棒的資料...

PostgreSQL 的 Parallel Aggreation

PostgreSQL 9.6 將會支援 Parallel Aggreation,在多 CPU core 下 aggreation operation 單一 query 的平行化效能改善 (改善非常多):「pgsql: Support parallel aggregation.」:

Parallel workers can now partially aggregate the data and pass the transition values back to the leader, which can combine the partial results to produce the final answer.

在「Parallel Aggregate – Getting the most out of your CPUs」這邊有測試 worker 數量與執行的速度差異:

We performed some tests on a 4 CPU 64 core server with 256GB of RAM using TPC-H @ 100 GB scale on query 1. This query performs some complex aggregation on just over 600 million records and produces 4 output rows.

由於是 64 cores,所以作者測 1 到 64 workers 的效能,這是測試出來的結果:

要注意 Y 軸是對數比例,紅色是理論值,藍色是實際值,可以看出來平行化的效能頗不錯,雖然開到 64 workers 時效率已經不到一半了。

這對離鋒時間的報表運算超好用啊...

PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善,尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性:

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象:

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份:

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是,agreesive vacuum 相較於 vacuum 會多吃很多資源,但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較):

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現,不知道會不會變 default...

AWS Database Migration Service

AWS 正式向所有使用者開放「AWS Database Migration Service」了:「AWS Database Migration Service」。

AWS 把前置作業 (setup & initial backup) 與 replication 的部份都包好,讓使用者可以很輕鬆的轉移。

支援的來源資料庫種類包括了這五種:

Supported database sources include: (1) Oracle, (2) SQL Server, (3) MySQL, (4) Amazon Aurora and (5) PostgreSQL. All sources are supported on-premises, in EC2, and RDS except Amazon Aurora which is available only in RDS.

支援的目的資料庫種類也包括了這五種:

Supported database targets include: (1) Amazon Aurora, (2) Oracle, (3) SQL Server, (4) MySQL, and (5) PostgreSQL. All Oracle, SQL Server, MySQL and Postgres targets are supported on-premises, in EC2 and RDS.

所以不只可以搬進 AWS,也透過在 EC2 instance 上架 Proxy 的方式搬出 AWS。比較特別的是可以不同 database 互轉?這好像可以玩玩看...

轉移的機器包括 t2.* 與 c4.* 兩種,一般來說 t2 系列的機器應該夠用,但如果要拼轉移速度的話可以拿 c4 出來撐場面。

PostgreSQL 9.5 釋出,UPSERT!

PostgreSQL 9.5 正式發行,這次新增了大家期待已久的 UPSERT 功能:「PostgreSQL 9.5: UPSERT, Row Level Security, and Big Data」。

SQL:2003 正式定義出 UPSERT,被稱為 Merge,不過看網路上一般還是比較習慣 UPSERT 這個用法:

A relational database management system uses SQL MERGE (also called upsert) statements to INSERT new records or UPDATE existing records depending on whether condition matches.

也就是當沒資料的時候就 INSERT,有資料的時候就 UPDATE 的語法。常見的使用情境是拿來當 counter 用 (雖然這很傷資料庫的效能)。

沒有 UPSERT 的時候只能用 transaction 或是 store procedure 搭出來,效能上會比在 database engine 裡實作來的差,所以 UPSERT 還是被實作出來了。

PostgreSQL 9.5 將會有 Parallel Sequential Scan

在「Parallel Sequential Scan is Committed!」這邊看到 PostgreSQL 9.5 (還沒出) 將會有 Parallel Sequential Scan 的功能。

文章的作者直接拿了一個大家超常用的惡搞來示範,也就是經典的 LIKE '%word%'

rhaas=# \timing
Timing is on.
rhaas=# select * from pgbench_accounts where filler like '%a%';
 aid | bid | abalance | filler
-----+-----+----------+--------
(0 rows)

Time: 743.061 ms
rhaas=# set max_parallel_degree = 4;
SET
Time: 0.270 ms
rhaas=# select * from pgbench_accounts where filler like '%a%';
 aid | bid | abalance | filler
-----+-----+----------+--------
(0 rows)

Time: 213.412 ms

這功能真不錯 XD

Archives