RDBMS - 常犯錯誤之解決方式

在系統開發上,常常會有以下的需求:

  1. 該資料需要頻繁的存取,例如:聊天室的情境,聊天訊息雙方必須頻繁的收到。
  2. 寫 log 的需求,例如:Web Server 的 access log、紀錄 user 的登入登出時間
  3. 沒有商業價值的大量數據的存放,例如:老舊且沒有商業價值的資料是不需要存放的,應該從主資料庫刪除

來一一講解以上說的三種需求的資料特徵及解決思路

Database-as-IPC

定義:將資料庫當作消息柱列的機制進行 interprocess communication,也就是類似 socket 的機制。

資料特徵:

  1. 資料的生命週期短
  2. 可以得知資料的產生者及使用者
  3. 資料一旦使用了之後就不再存有價值
  4. 可能會有頻繁的查詢資料庫的 Request,看資料是否有更新

例子:將聊天軟體的訊息放在 RDBMS,接收訊息的那一方需要每數秒就要去發 Request 去檢查 RDBMS 是否有新的聊天訊息

缺點:

  1. 如果把資料庫當作 IPC 的機制,可以說根本是殺雞焉用牛刀,而且這樣的傳遞效率極低,效能也不好。想想資料庫是存放重要的數據,對於這種很頻繁的 Hot Data,且這種資料一旦使用就不再存有價值,會導致效能低落。
  2. 會帶來嚴重的長期維護問題,因為當聊天軟體有多位使用者,每個使用者之間都可以開聊天室,也就是說這種聊天訊息是爆炸性的增長,其表格的設計會有維護問題。

解決思路:

使用類似 RabbitMQ 這種專門的消息柱列的軟體來傳遞訊息,並且透過 RabbitMQ 切分出多種柱列,讓多個伺服器去訂閱各自的柱列,例如一個伺服器專門找出要發送到哪個使用者、一個伺服器專門發送訊息、一個伺服器專門 request 資料庫將需要的資料存放進去。

之後會分享這種方式的實作方式!

Database 存放 log

log 定義:

  1. 一旦 log 建立成功就不更動 log 裡面內容
  2. log 裡面內容通常會結合報表操作

例子:

  1. Web server 的 access log,例如:Request API 的紀錄,由哪個使用者發出,發出的時間如何,紀錄 API 的 Status 等資訊
  2. 紀錄 user 的登入和登出時間

缺點:

因為這種 log 通常也會需要頻繁的存進資料庫,會造成效能的影響

解決思路:

根據系統的大小決定處理方式,小型系統應該就採用純文字檔的方式紀錄即可,畢竟純文字檔的紀錄相對來說一定會比存資料庫高效許多,如果系統過於龐大應使用專門作 logging 的軟體,不過我還沒有這種經驗 XD,如果有機會用到在分享!

沒有商業價值的資料

雖然現在硬碟都很便宜沒錯,存放多餘資料是沒有差,但是可能需要多花一些人力去管理這些多餘的資料,如果沒有商業價值的資料應該要果斷刪掉,因為當如果有做報表的需求的話,會影響其效率。

不過這還是要看老闆的決定… 個人覺得 XD

解決思路:

採用 data partitioning,每個資料庫有其 data partitioning 的方法,可以有效地將資料分割在特定區域,也就是將老舊資料分割掉,以提高存取新資料的速度等功能。目前這個我也還沒研究過,如果有機會碰到,在分享~

總結

以上內容參考這位大神的提點:[https://github.com/TritonHo/slides/tree/master/Taipei 2019-04 course](https://github.com/TritonHo/slides/tree/master/Taipei 2019-04 course)

因為有他的提點,才能好好整理自己以前寫系統的思路,有些需求不應一股腦地去做,而是謹慎下決定並且根據不同情境採用不同解決方式,值得我們好好去思考。

最後最後!請聽我一言!

如果你還沒有註冊 Like Coin,你可以在文章最下方看到 Like 的按鈕,點下去後即可申請帳號,透過申請帳號後可以幫我的文章按下 Like,而 Like 最多可以點五次,而你不用付出任何一塊錢,就能給我寫這篇文章的最大的回饋!