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

MariaDB 讀寫分離的工具:MaxScale

MariaDBMaxScale 軟體提供 MySQL 相容的 proxy interface,可以將後端一群 MySQL server 架構隱藏起來,讓應用程式不需要處理這部份。

Percona 的人則介紹 MaxScale 作為讀寫分離的工具:「High availability with asynchronous replication… and transparent R/W split」。

如果你是用有支援讀寫分離的 ORM (像是 Laravel 中的 Illuminate::Database),由於 ORM library 幫你處理好了,你可以省掉這個工作。

但在其他的情況,像是應用程式沒有原始程式碼,或是只能設一組 server,你就必須透過像 MaxScale 這種軟體來幫你打散負荷量。

Percona 給的範例提供了很多設定檔,應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了),對於有興趣的人應該可以丟人研究?

Amazon RDS 提更完整的監控機制

這次 Amazon RDS 發表了更細的監控機制,包括了 MySQL 5.6、MariaDBAurora 這幾個產品線:「New – Enhanced Monitoring for Amazon RDS (MySQL 5.6, MariaDB, and Aurora)」。

rds_full_metrics_list_2

差不多是 SmokePing 可以提供的範圍,算是補的更齊全,讓找問題時的資料更多。不過顆粒細度可以到一秒鐘:

rds_enable_enhanced_monitoring_2

不過要注意的是,t1.micro 與 m1.small 不支援:

It works for MySQL 5.6, MariaDB, and Amazon Aurora, on all instance types except t1.micro and m1.small.

繼續學 Isolation...

在「測試 MariaDB 上 Galera Cluster 的 Isolation」這邊與「從頭學一次 Isolation level 的 REPEATABLE-READ 與 SERIALIZABLE」對應了 Stripe 的「Call me Maybe: MariaDB Galera Cluster」以及 Percona 的「Clarification on “Call me Maybe: MariaDB Galera Cluster”」這兩篇文章,兩邊在空中交火...

而「Call me Maybe: Percona XtraDB Cluster」這篇是目前最新的一篇 (文章日期有點怪怪的,不應該是 2015/09/04)。

畢竟 Galera Cluster 是目前現在在用的產品,雖然跑起來也沒什麼大問題,但預先多了解一點總是比較保險。而要參與這場 Isolation 戰爭,又花了不少時間看幾份資料。(包括重頭讀的)

第一個當然是 1992 年發表的 SQL-92:「ISO/IEC 9075:1992, Database Language SQL」,在 SQL-92 定義了四個 Isolation 的層級,分別是 SERIALIZABLEREPEATABLE READREAD COMMITTEDREAD UNCOMMITTED

另外一篇常被拿出來討論的是 1995 年由微軟帶頭發表的「A Critique of ANSI SQL Isolation Levels」,主要是提出 Snapshot Isolation 的定義。

後來讀到覺得真的很怪的時候到 Stack Exchange 上的 Database Administrators 問:「Does SQL92's REPEATABLE-READ preclude Write Skew (A5B)?」,確認了我的想法。

這篇算是讀書心得吧,留給自己用的 :p

首先是 REPEATABLE READ 的定義是透過「現象」定義,只要符合這些條件就可以被稱作 REPEATABLE READ,這包括了保證不會出現 P1 ("Dirty read"):

1) P1 ("Dirty read"): SQL-transaction T1 modifies a row. SQL-transaction T2 then reads that row before T1 performs a COMMIT. If T1 then performs a ROLLBACK, T2 will have read a row that was never committed and that may thus be considered to have never existed.

以及保證不會出現 P2 ("Non-repeatable read"):

2) P2 ("Non-repeatable read"): SQL-transaction T1 reads a row. SQL-transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted.

並且保證 Atomicity 以及 no updates will be lost:

The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost.

只要做到這些條件,就可以說符合 SQL-92 的 REPEATABLE READ 要求。


另外一方面,在「A Critique of ANSI SQL Isolation Levels」定義的 SQL-92 認為 REPEATABLE READ 是透過 locking 機制實作的 (整篇的寫法的確是朝這個方向走),並且基於 locking mechanism 來推論後續的行為,所以這篇 paper 裡面很多說明是帶著這個大前提的。

而當時已經有資料庫是使用 MVCC 架構在實作,可以透過 read snapshot 的方式找出另外一條路。

舉例來說,InnoDB 對 REPEATABLE READ 實作的方式是透過 snapshot 實作:(出自「MySQL :: MySQL 5.6 Reference Manual :: 13.3.6 SET TRANSACTION Syntax」)

For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other.

這樣避開了 P1、P2 (甚至多做避開到了 P3,不過這邊不重要),並且 Atomicity。而 Update Lost 問題則再透過 lock 機制避免。所以 InnoDB 的 REPEATABLE READ 其實比 SQL-92 的要求多做到了很多事情...


到這邊再回頭看原來的討論文章,才會發現 Isolation 裡有滿滿的地雷可以採 XD

測試 MariaDB 上 Galera Cluster 的 Isolation

雖然人還在大阪員旅,不過看到這篇很精彩的測試還是先寫下來:「Call me Maybe: MariaDB Galera Cluster」,作者在 Stripe 花了很多時間在測試各種資料庫的資料正確性。

由於 PerconaPercona XtraDB Cluster (PXC) 是基於 Galera Cluster 改出來的,再加上敝公司裡面大量使用 PXC,決定還是趕緊花時間看完整篇文章確認到底講了什麼。

先講目前看到的結論:

  • 作者認為 Galera Cluster 官方宣稱的 SNAPSHOT-ISOLATION (SI) > REPEATABLE-READ (RR) 是有問題的講法,在學理上 SI 與 RR 都低於 SERIALIZABLE (1SR),也都高於 READ-COMMITTED (RC),但兩者之前沒有直接包含。
  • Galera Cluster 的測試結果看起來沒有做到 SI 的要求,不過測試中看起來有達到 READ-UNCOMMITTED (RU),在 RC 的測試中也沒找到問題,不過作者還是懷疑系統有達到 RC 的要求。

另外從其他討論串看起來,當所有人寫入都到同一台就沒有這些狀況,可以達到 1SR 的要求,這也是目前還蠻常見的系統設計,所以這次的問題看起來沒有這麼大。

後面也提到裝 MySQL Cluster 裝了好幾個禮拜還是裝不起來的事情:

Galera is easy to install–I spent weeks trying to set up MySQL Cluster to no avail, and got Galera Cluster running in a matter of hours.

有種,不是很意外的感覺...

Anyway,原文下面的 comment 可以看到 Baron Schwartz 也跑出來討論,另外在 GitHub 上有開始有討論了:「Snapshot Isolation may not be as isolated as one would like」,看起來直接戳破 Galera Cluster 支援 SI 的宣傳詞了,接下來拉板凳繼續看戲吧... XD

關於要不要使用 MySQL 這件事情...

前陣子 ant 將在 5xRuby 演講的投影片放出來:「技術演講:淺入淺出 MySQL & PostgreSQL」,另外在 kaif.io 上也有討論:「淺入淺出 MySQL & PostgreSQL // Speaker Deck」。

而國外剛好也有好幾篇文章都在討論 MySQL (InnoDB),其中「how innodb lost its advantage」這篇講到對 InnoDB 的壓縮感到悲觀...

另外 Pinterest 的「Learn to stop using shiny new things and love MySQL」這篇的時間點感覺上就是在回應上面某些想法。

下面是我的整理 (以及想法)。

MySQLPostgreSQL 都是很成熟的 RDBMS。

如果你對其中一種有經驗,那麼就用你熟悉的 RDBMS。如果你對兩者都有經驗,那麼你就憑自己的判斷選擇。

如果都沒有經驗呢?看你身邊的人用什麼就選什麼。

我在 5xRuby 時回答的比較輕鬆,但這是很實際的回答:你既然都不會用這些進階功能,那麼兩套其實對你都差不多。選一個可以問的到答案的就好。

反正真的夠大的時候,拿錢出來總是有方案可以解決問題。初期把力氣花在怎麼搞定產品吧,如果你不熟悉,這通常都不是你在這個時間應該花時間去研究的問題。

Percona 講 TokuDB

Percona 的「Getting to know TokuDB for MySQL」這篇文章雖然標題是想要宣傳 TokuDB,但其實把 MySQL 的歷史也講了一遍...

前面講到 InnoDB 的崛起時,就有提到就算你不使用 InnoDB 提供的 transaction,他的 crash-safe 性質也仍然是許多人選用 InnoDB 的重要因素之一:

Even those that don’t really need transactions rejoice in the crash resistance strength of InnoDB.

後面提到 TokuDB 時當然都會提到 Fractal Tree Indexes 這個資料結構對於現代硬體設備的優點。而英文版維基百科在今年三月時總算建立了 Fractal tree index 這個條目,整理的還算完整,之前是去看投影片了解這個資料結構的特性...

Percona 目前對 TokuDB 的等級是放在 beta 版,等 GA 後再來完整的測過一次,另外也想要測能不能在同一個 transaction 內使用 InnoDB table & TokuDB table,這對 zero-downtime migration 還蠻重要的,如果不可行的話工程就比較大了...

MySQL 上的 Thread Pool...

Percona 的人寫了一篇「Percona Server: Improve Scalability with Percona Thread Pool」,提到關於 MySQL 在連線數很多時的效能。

傳統的作法是一個連線使用一個 thread,這種方法實做起來很簡單,但當連線數超過一定程度時就會因為共用資源的限制而變慢。

其中一種解決方法是引入 Thread Pool 架構,也就是 M 個 thread 處理 N 個連線。

Oracle 有提供商用版本叫做 Thread Pool Plugin,就如同名字,是以 plugin 形式存在。這個功能在 5.55.6 都有。

MariaDB 也有 open source 實做的 Thread pool

而 Percona 則是使用 MariaDB 的版本。(原文是說有改善,不過 benchmark 並沒有列出來,我「猜」其實沒什麼改善...)

可以看到在多連線數時的效果相當好。在 MariaDB 的文件裡有提到會有改善的時機:

Threadpools are most efficient in situations where queries are relatively short and the load is CPU bound (OLTP workloads). If the workload is not CPU bound, you might still want to limit the number of threads to save memory for the database memory buffers.

query 相對短,而且是 CPU bound。

回頭看的時候發現 Percona Server 5.5 就有支援 Thread Pool 了,應該來測試看看效果如何...

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch,讓 InnoDB 在 table scan 的速度大幅提昇:「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了:

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小,而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍?如果是平常就很操的 database 會更明顯?

如果這幾個 patch 如果沒有什麼問題,可以預期會被 merge 到 PerconaMariaDB,至於 Oracle 官方的 source tree... 有的話當然很好,沒有的話也很正常?

Archives