Tag: rdbms

InnoDB 與 MyRocks 之間的取捨

MyRocks 的主要作者 Mark Callaghan 整理了一篇關於大台機器下，資料可以放到記憶體內的效能比較：「In-memory sysbench, a larger server and contention - part 1」。

這其實才是一般會遇到的情況：當事業夠大時，直接花錢買 1TB RAM + 數片 PCI-E SSD 的機器用錢換效能... (主要應該會在記憶體花不少錢，剛剛查了一下，現在白牌的 server 一台大約七十萬就可以擺平？兩台做 HA 也才一百四十萬，對有這個規模的單位來說通常不是大問題...)

而三種不同的 case 裡面，最後這個應該是最接近真實情況的：

可以看到 InnoDB 在幾乎所有項目都還是超越 MyRocks (只有 random-points 與 insert-only 輸)。

不知道後續的開發能量還會有多少... (因為 Facebook 的用法跟一般情況不一樣)

Amazon Aurora 支援快速複製

Amazon Aurora 宣佈支援快速複製：「Amazon Aurora Fast Database Cloning」。

對於 2TB 的資料大約五分鐘就完成了：

This means my 2TB snapshot restore job that used to take an hour is now ready in about 5 minutes – and most of that time is spent provisioning a new RDS instance.

主要是得力於後端 storage 的部份可以實做 copy-on-write 架構：

By taking advantage of Aurora’s underlying distributed storage engine you’re able to quickly and cheaply create a copy-on-write clone of your database.

可以快速複製就可以很快的驗證一些事情，像是可以直接測試 ALTER TABLE 需要的時間，或是事前演練...

小台機器上的 innodb_purge_threads 對效能的影響

雖然「MyISAM, small servers and sysbench at low concurrency」這篇標題是在講 MySQL 上的 MyISAM，但還是有提到一些 InnoDB 的東西...

其中提到了 innodb_purge_threads 對效能的影響：

the default value for innodb_purge_threads, which is 4, can cause too much mutex contention and a loss in QPS on small servers. For sysbench update-only I lose 25% of updates/second with 5.7.17 and 15% with 8.0.1 when going from innodb_purge_threads=1 to =4.

當機器不大的時候，innodb_purge_threads 對於效能帶來的影響其實頗大的？

另外從作者最近的一系列測試看起來，5.7 在小機器的效能比 5.6 差不少... 這點在考慮 RDS 的時候也許要注意 (因為 t2.* 應該不算大 XD)。

MySQL 上 Replication 的方案

Percona 的人整理了一篇關於 Replication 的方案 (以及 NDB，不過這邊就先偷偷跳過去...)，雖然標題寫的是 High Availability：「The MySQL High Availability Landscape in 2017 (The Elders)」。

先講他給的另外兩個方案，一個是 Shared Storage，另外一個是 NDB。

其中 Shared Storage 其實在儲存空間端還是有單點失效的問題，而 NDB 的特性跟 InnoDB 不同，有很多概念要重新學... 如果就這三個比較，常見的還是第一個提到的 Replication。

其實把 Replication 用熟的話已經可以解決不少問題了 (不論是早期的 MMM，或是 MHA)。而且因為技術已經發展很久了，大家幾乎都很熟特性 (以及 bug XD)，網路上可以找到不少資料，甚至 Percona 也都能夠支援 (當你願意付錢的時候 XDDD)。

在 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

Amazon Aurora 可以 clone 了...

Amazon Aurora 可以 clone 複製資料庫了：「Amazon Aurora Introduces Database Cloning Capabilities」。

而且是 COW 架構 (Copy on write)，所以複製出來的部份不需要額外付儲存費用，只有修改的部份才要付費，這點相當殺啊：

A cloning operation does not incur any storage charges. You will only be charged for additional storage space if you make data changes.

這對於「測試」這件事情變出不少變化可以用...

用 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

MySQL 5.6/5.7/5.8 在 single thread 時的效能比較

作者 Mark Callaghan 在討論 MySQL 在量小的時候，新版可能反而比舊版慢：「The history of low-concurrency performance regressions in MySQL 5.6, 5.7 and 5.8」。

One example of the regression occurs for in-memory sysbench where MySQL 5.7 and MySQL 8 get 60% to 70% of the QPS compared to 5.6, which is the same as writing that 5.6 gets 1.43X to 1.67X more QPS than MySQL 5.7 and MySQL 8.

其實不算太意外，因為功能愈來愈多，而且最佳化的重心都放在用量大的各種情境下。並沒有針對 single thread 時的情境最佳化...

performance_schema 的簡易用法

Mark Callaghan 寫了篇關於 performance_schema 的用法 (很短)，讓大家先把這個參數開習慣，雖是入門推廣班：「Short guide on using performance_schema for user & table stats」。

他推薦的兩個資訊是：

select * from table_io_waits_summary_by_table
select * from events_statements_summary_by_account_by_event_name

當使用 5.7+ 時，可以考慮這兩個：

SELECT * FROM sys.schema_table_statistics
SELECT * FROM sys.user_summary

簡單到不行，但卻可以幫不少忙... 很棒的入門推廣班 XDDD

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫：「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明：

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale，很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法，將 cache 放到 client 的效能比較好：

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了：「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話，透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。