選擇關聯式資料庫的時機

剛開始摸 Data Mining 這門學問的時候,正好也是資料庫技術從關聯式資料庫獨大進入 NoSQL/NewSQL 爭輝的群雄時代,因為這個巧合,很多人問我論文有沒有用到 NoSQL 技術,即使回到業界,也有很多人問我,參與管理或開發的專案,為什麼不用 NoSQL 技術。

我的答案,一概是沒機會。原因很簡單,第一,我對 NoSQL 的理解,只在紙上談兵階段,如果沒有適當的機會,不能拿別人的前途練兵;第二,並不是任何案子都合適用 NoSQL 技術,殺雞用牛刀,還可用「蒼鷹搏兔當用全力」來辯解,窗花浮雕用青龍偃月刀,樂子就大了。

前兩年,參與了幾個產學合作的案子,合作的「學術方」,都「鄭重」提出他們要把現有工具(or 平臺)用 NoSQL 技術重寫的建議,做為爭取「產業方」點頭首肯的籌碼之一。說實話,雖然做為列席人不會也不好當面吐槽太過,但是打從心底浮起大大的問號自是當然。

今天正好看到 SourceLair 聯合創辦人 Paris Kasidiaris文章,從實務的角度說明為什麼不要把 NoSQL 當萬靈丹,關聯式資料庫才是絕大多數場合最合適的選擇,理由很簡單

  • 關聯式資料庫經過四十年的發展,不論是平臺、工具、人才,生態鏈的上下游結合緊密,各式方案與專家供應無虞
  • 再來,關聯式資料庫有符合 ACID 原則的交易(transaction)概念,只要適當配置硬體架構,資料的完整與安全能得到最佳的保障

有些為 NoSQL 聲援的專家們,會說 NoSQL 系統的可縮放性(scalability)比關聯式資料庫好多了,巴黎先生講了句大實話,不要擔心, 你的網站負載比你想期望的要低的多,若你開張第一天就每秒要執行數千個資料庫指令,管理幾個 terabytes 的資料,那麼恭喜你,馬上就要發達了(如果發達了,找個 CTO 幫你傷腦筋吧)!

First, scaling is not and most probably won’t be your problem. Unless you start having a few thousand of queries per second and terrabytes of data in your database, this won’t be a problem at all.

如果你的網站要處理一筆筆的交易(不是只有處理金錢才是資料庫的 transaction ),關聯式資料庫還是首選。巴黎先生 還提供了一個彩蛋,如果你確實需要處理非結構式資料,別擔心,各主流資料庫都提供了 JSON 的支援。

在第一線打仗的人說的話,還是值得聽聽的,不是嗎!?

🆓 BONUS: If you really need to store unstructured data into your database, this does not mean you have to go with a NoSQL data store. Take a look at MySQL’s JSON data type, Postgres’ JSON types and SQLite’s JSON extension.

Instapaper Outage 之後

Instapaper 在2月9日因為資料庫檔案過大,超過 ext3 檔案系統的單一文件2TB限制,系統掛掉 (Instapaper 的公告是 Extended Outage),直到2月14日才完全恢復。

前段日子,都在平板上看 Homo Deus 和整理書摘,沒有使用過 Instapaper,所以完全沒意識到這次大當機,直到看到灣區日報和 Instapaper 員工 Brian DonohueMaking Instapaper 發的 Instapaper Outage Cause & Recovery

Brian Donohue 在文章裡面簡明扼要的解釋事情發生的原委(root cause)和解決問題的過程。2.5 TB 的資料庫讓系統停擺,更可怕的是,雖然 Instapaper 每天都備份資料庫內容,但是同樣因為檔案大小限制的關係,每天備份的內容都不超過 2TB,所以每日備份不是真正完整的備份(daily backup)。

The reason this limitation exists is because MySQL RDS instances created before April 2014 used an ext3 filesystem which has a 2TB file size limit. Instances created after April 2014 are backed by an ext4 filesystem and subject to a 6TB file size limit.

還有一點很重要, AWS RDS 沒有提供監督和警示的機制,對於把身家都壓在 RDS 的網站管理者,要是沒有針對這點事先規劃好每日工作的內容(housekeeping details) 以及應變計畫(Disaster Recovery),即使檔案大小尺寸提高到 6TB, 後果仍然堪虞啊!

As far as we can tell, there’s no information in the RDS console in the form of monitoring, alerts or logging that would have let us know we were approaching the 2TB file size limit, or that we were subject to it in the first place. Even now, there’s nothing to indicate that our hosted database has a critical issue.

Brian Donohue 坦誠他們原先並沒有良好的應變計畫,當然更不可能在平日執行重大事故的應變演練。經過這次教訓,我想 Instapaper 一定知道該怎麼做啦。

至於做看客的我們,要知道所謂「他山之石」,不是頑石啊!