在介紹神奇設計之前還是先將資料庫的種類介紹一下，自有了前後端分離的出現，Back-End 便可以更專注的處理資料流，但也因為如此，對於各項技能的要求也會隨著提高，從資料庫種類的選擇、資料的關聯方式、SQL 的下法、索引的選擇都是與效能息息相關的條件。

資料庫的選擇
目前常見的資料庫種類有兩種：SQL、NoSQL。NoSQL 的概念是以 Key - Value 對應的方式來進行搜尋，例如將我的身份證設定為 Key，將其他個人資料如姓名、性別、住址以 Hash 的方式存為 Value 做對應，好處是 Value 的格式不需要事先定義好，不論是 String、List、Set、ZSet、Hash 等格式皆可以使用，缺點是沒辦法使用 Value 來反查其他資訊。還有一種 NoSQL 為 Cache NoSQL ， 因為其資料儲存是儲存在 RAM 上，讀取及寫入的速讀可快於硬碟百倍以上，常用於讀取遠大於寫入的資料緩衝使用，避免 SQL 流量過大而造成服務中斷。還有一種變形的 NoSQL 資料庫稱為 Elastic Search ，該資料庫對於語句的搜尋非常厲害，例如我將一個LINE聊天室群組的對話通通存進該資料庫，而我只要找出指定語句相關的聊天訊息，例如「今天要吃什麼」，一般的NoSQL因為沒有特別設定這樣的 Key ，所以沒辦法找到相關的資料，如果是 SQL 則是要用 Like 來搜尋，但效率會非常的差，Elastic Search 則在這種搜尋上有非常良好的表現。SQL 則是最常見的資料儲存方式，需要先定義各個 Table 及其 Column 的資料格式但搜尋的方法可以有多樣性。

Redis 是我在工作中唯一會用到的 NoSQL ，由於資料儲存在 RAM 的特性所以速度非常快，但也有一些特性要注意，例如：服務中斷後資料不保持，所以重要的資料還是必須存入在有中斷記憶的資料庫裡。再來是因其常用於大流量的服務中，如果 Cache 服務中斷後流量就會導向資料庫去，此時容易引起「快取擊穿」。再來 Cache 通常會搭配時效性，避免資料庫的資料已經更新了而 Cache 的資料過久沒有更新，但也要注意 Cache 刷新的時間，如果同時大量的資料同時失效也會引起「快取雪崩」，由於這兩個情境都包含大量的資訊，幾乎可以獨立提出來寫一篇鐵人賽了，所以在此只能留下關鍵字。

希望在後續的篇章中能有機會分享更多的實戰經驗，明天就要開始解說 SQL 的操作了。