Tag: oltp

GCP 推出 AlloyDB，一套相容 PostgreSQL 協定的資料庫服務

也是在清 RSS reader 的時候翻到的，看起來是在今年的 Google I/O 上發表的服務，AlloyDB：「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」，值得提的是這篇有中文版可以看：「適用於 PostgreSQL 的 AlloyDB 隆重登場：從此擺脫成本高昂的老舊資料庫」。

另外還有一篇比較偏 PR 的文章也可以看看：「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」，這篇就比較針對的提到了與 AWS 的服務相比，但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰)，但我猜測是與 Aurora 對比：

AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.

宣稱在 OLTP 上快了兩倍 (原來的三倍？)，但應該都是以 PostgreSQL 下去改，猜測可能是底層的 storage 與 replication 比較好？

AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用，所以同時可以提供 OLAP 與 OLTP 的應用：

[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).

直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。

目前在 AWS 對應的方案應該是透過 Redshift 來解決，另外一個方案是透過 Athena 來跑。

最後來看價錢，如果效能變成兩倍但價錢也是兩倍的話，就代表在價格上沒優勢。

先看機器的部份，如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr，而如果換算到 AlloyDB 的話是 US$14.94528/hr，相除是 0.9314，大約 7% 的差距，可以算是同一個級距。

如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr，換算到 AlloyDB 的話是 US$9.96352/hr，相除是 0.8336，這邊就差超過 16% 了...

(這邊剛好回顧一下 "Amazon’s comparable service" 這段，不確定他是跟 Intel-based 比還是跟 ARM-based 比，畢竟 ARM 除了比較便宜外，還有效能的提昇)

但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的，以 us-east-1 來說，storage 是 US$0.10/GB/mo，而 I/O 是 US$0.20/million-requests，在 AlloyDB 這邊來說，Regional cluster storage 是 US$0.0004109/GB/hr (us-east4)，變成是 US$0.295848/GB/mo，兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。

這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)

光就檯面上的資料來看，看起來是個不錯的東西，等後續有人跳進去用看看感想...

PostgreSQL 的 scale 建議

在 Hacker News Daily 上看到「Postgres scaling advice for 2021」這篇，講 PostgreSQL 要怎麼 scale，在 Hacker News 上也有對應的討論可以看：「Postgres scaling advice (cybertec-postgresql.com)」。

文章前面先提到分散式系統的複雜度會導致 RDBMS 上的一些假設失效，所以如果可以用單台機器暴力解，就儘量用單台機器來解 (scale up 的情境)，裡面就提到了一些「暴力可以解決很多問題」的說明，差不多就是前幾天提到的「Let's Encrypt 升級資料庫伺服器 (AMD YES？)」。

後面提到如果真的要放進分散式的 RDBMS (scale out 的情境)，怎麼設計資料結構會比較好。

這邊剛好也可以提一下，量夠大的時候要把 OLTP 與 OLAP 的應用分開，現在有很多 OLAP 資料庫可以選擇，同步的工具也很成熟了，通常效能會比在 OLTP 上面硬跑來的好。

最後提一下，文章裡面對於 transaction per second 可以拉很高，有些假設沒有明寫出來。這需要盡可能把 transaction 拆小，避免常常有 giant transaction 卡住整個資料庫，這點對於一般的系統會需要做不少改寫...

不過最後比較疑惑的是，這種文章怎麼會上 Hacker News 的啊...

MySQL 裡 performance_schema 對效能的影響

最近在弄 MySQL 的 perforemance_schema，開起來後發現效能影響沒有很大，跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過：「Performance Schema Benchmarks: OLTP RW」。重點在這張圖：

圖上可以看到 Default 其實對效能的影響有限，另外文章也整理出來，有哪些設定對效能影響不會太大，可以考慮平常就開著：

Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.

細看 MySQL 的 Performance Schema 對效能的影響

Percona 的人對 MySQL 5.7 的 OLTP RW 測試中，Performance Schema 的各種不同的功能對效能帶來的影響：「Performance Schema Benchmarks: OLTP RW」。

原文章裡有定義這些分別是打開哪些功能，這邊就跳過去... 重點是 default 值對效能的影響其實不算高，所以除非是想要壓榨每一分效能，不然其實可以考慮打開 (針對 OLTP RW 類似的應用)：

影響比較大的是 Stages 與 Waits 的部份。而 Mark Callaghan 在 comment 提到在 Performance Schema Event Timing 這邊有相關的資料... 看起來應該可以降低對 Stages 與 Waits 的效能衝擊。

用 sysbench 測試 MySQL 效能

很久前是用 tpcc-mysql 測試 MySQL 效能：「用 tpcc-mysql 測試 LSI 的 Nytro MegaRAID NMR 8100-4i」，最近剛好又有測試需求，想說拿來學個新玩具測試，就想到 sysbench 的 oltp 測試。

先用 Google 找了找測試的方式，appleboy 之前寫的「Sysbench 測試 Percona XtraDB Server 效能」算是還不錯的文件，就拿來當起點了。

我是拿 AWS 測試，主要是因為幾乎所有的效能都是固定的，這樣測出來才有意義。

Amazon EC2 用 c4.8xlarge，用 10Gbps 網路測試會比較準確一點。硬碟的部份是掛上 100GB 的 SSD 硬碟，如果是測 I/O bound 的人就選擇有固定 IOPS 的 Provisioned 版本，但我這次測的都是 CPU bound，就只選用 General 版本了。

跑起 Ubuntu 14.04 後直接用 apt-get install sysbench 就可以裝起來了。

Percona 的 apt repository 設定可以參考官方的「Installing Percona Server on Debian and Ubuntu」這篇文章。設好後要裝什麼版本測試就是自己的選擇了。

都裝好後，測試的方式是先用 prepare 塞資料，再用 run 測試。

這是 prepare 部份的指令：(粗體字的 x 需要帶入自己對應的參數)

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 prepare

這是 run 部份的指令，我這邊用了 --oltp-read-only=on 只測 read transaction 的速度：

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 --oltp-read-only=on --num-threads=256 --report-interval=5 --max-time=60 --max-requests=0 run

大致上就是這樣測，然後用 gnuplot 畫圖。