選擇關聯式資料庫的時機

剛開始摸 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s