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

Heimdall Data:自動 Cache RDBMS 資料增加效能

看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。

從官網的介紹也可以看出來是另外疊一層 proxy,但自動幫你處理 cache invalidation 的問題:

But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

看起來支援了四個蠻常見的 RDBMS:

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).

看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做,在 FAQ 沒看到 cluster 情況下會怎麼解決。

在 Production 上惡搞 PostgreSQL,建立一千萬筆 Index...

在「Running 10 Million PostgreSQL Indexes In Production (And Counting)」這邊看到 Heap 他們在 PostgreSQL 上惡搞的方式。

為了效能,所以在上面建立了大量的 Partial index。像是這樣的條件 (所以其實每個都不算太大):

CREATE INDEX ON events (time) WHERE type = ‘click’ AND text = ‘login’

要注意的是 MySQL 的 Partial index 其實是 prefix index,用以減少 index 的空間要求,這在 VARCHAR(255) 以及 MD5 後的欄位還蠻有幫助的。而 PostgreSQL 的 Partial index 則是指條件式,兩者不太一樣。

不過他們還是有遇到「建立 index」這件事情的效能問題 (以及 workaround 的方式)。

不太常看到這樣惡搞,看到這篇的時候在電腦前笑的頗開心的 XDDD

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息:「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究,除了預設值以外,另外跟四種不同的參數做比較,分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人,常用的 open source 工具)、DBA 手動調整,以及 RDS

MySQL

PostgreSQL

比較明顯的結論是:

  • Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台,以及包括 99% 的 Latency 與 QPS,這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
  • OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果,本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情,我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

Amazon Aurora 的論文

AWS 老大介紹自家產品 Amazon Aurora 的論文:「Weekend Reading: Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases.」,論文在「Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases」這邊可以取得。

Amazon Aurora 算是用很特別的架構達到高可靠架構的需求,主要用了一堆已經很強大的底層,像是用 Amazon S3 來交換一堆資料。

不過 AWS 在論文裡的比較的事情其實並不合現實,因為現在的 MySQL 在做分散式架構時的方式其實並不一樣 (i.e. Galera Cluster),論文裡提的很多比較的項目,其實都不是其他方式會遇到的問題,所以就看看就好,畢竟是在推銷自家產品...

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

Archives