RDBMS - 常犯錯誤之解決方式
在系統開發上，常常會有以下的需求：
- 該資料需要頻繁的存取，例如：聊天室的情境，聊天訊息雙方必須頻繁的收到。
- 寫 log 的需求，例如：Web Server 的 access log、紀錄 user 的登入登出時間
- 沒有商業價值的大量數據的存放，例如：老舊且沒有商業價值的資料是不需要存放的，應該從主資料庫刪除
來一一講解以上說的三種需求的資料特徵及解決思路
Database-as-IPC
定義：將資料庫當作消息柱列的機制進行 interprocess communication，也就是類似 socket 的機制。
資料特徵：
- 資料的生命週期短
- 可以得知資料的產生者及使用者
- 資料一旦使用了之後就不再存有價值
- 可能會有頻繁的查詢資料庫的 Request，看資料是否有更新
例子：將聊天軟體的訊息放在 RDBMS，接收訊息的那一方需要每數秒就要去發 Request 去檢查 RDBMS 是否有新的聊天訊息
缺點：
- 如果把資料庫當作 IPC 的機制，可以說根本是殺雞焉用牛刀，而且這樣的傳遞效率極低，效能也不好。想想資料庫是存放重要的數據，對於這種很頻繁的 Hot Data，且這種資料一旦使用就不再存有價值，會導致效能低落。
- 會帶來嚴重的長期維護問題，因為當聊天軟體有多位使用者，每個使用者之間都可以開聊天室，也就是說這種聊天訊息是爆炸性的增長，其表格的設計會有維護問題。
解決思路：
使用類似 RabbitMQ 這種專門的消息柱列的軟體來傳遞訊息，並且透過 RabbitMQ 切分出多種柱列，讓多個伺服器去訂閱各自的柱列，例如一個伺服器專門找出要發送到哪個使用者、一個伺服器專門發送訊息、一個伺服器專門 request 資料庫將需要的資料存放進去。
之後會分享這種方式的實作方式！
Database 存放 log
log 定義：
- 一旦 log 建立成功就不更動 log 裡面內容
- log 裡面內容通常會結合報表操作
例子：
- Web server 的 access log，例如：Request API 的紀錄，由哪個使用者發出，發出的時間如何，紀錄 API 的 Status 等資訊
- 紀錄 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)
因為有他的提點，才能好好整理自己以前寫系統的思路，有些需求不應一股腦地去做，而是謹慎下決定並且根據不同情境採用不同解決方式，值得我們好好去思考。