tags: 鐵人賽

前言

為了幫助閱讀，我把skip的簡要概念放到後面去。
那就開始今天的部分吧~

也順便提一下，未來實作對比觀念講解的比重會相對少一些，因此為了讓大家能夠聚焦，說明的結構會盡可能放在這些知識是為了解決什麼問題，也有什麼新的缺點需要考慮。

日程安排

DB

• Day 14: db大觀園(上)-關聯式資料庫overview
• Day 15: db大觀園(下)-非關聯式資料庫overview
• (skip) ORMs及ODMs
• Day 16: 交易的安全保證-ACID & Transactions
• Day 17: 效能危機-N+1 problems
• (skip)資料庫正規化(normalization)
• (skip)索引indexs

API

• Day 18 API架構比較
  • RESTful API
  • SOAP
  • gRPC
  • graphQL
    • Apollo
    • Relay Modern
• Day 19 先生你誰?-身分驗證Authentication (Oauth, Basic, JWT, token)

Cache

• Day 20 就是快取啦-Cache
  • CDN
  • ServerSide
  • ClientSide

Web Security Knowledge

• Day 21 我叫雜湊不叫加密-hashing (MD5, SHA family, scrpty, bcrypt)
• Day 22 說只有對方聽得懂的話-https & ssl & tls
• Day 23 我不允許的你不能做-網頁內容安全政策content security policy
• Day 24 十個好弱點，不保護嗎?-OWASP security risk

Testing

• Day 25 給工程師吃個定心陲-測試Testing
  • 單元測試
  • 整合測試
  • Functional Testing

Design And Development Principle

• Day 26 跟著設計模式走，好維護阿自然有(單押)-設計模式software design pattern
  • SOLID
  • KISS
  • YAGNI
  • DRY

Architectural patterns

• Day 27 程式架構設計Architectural patterns
  • monolith
  • microservices
  • SOA
  • CQRS
  • serverless

container

• Day 28 ㄟ黑我又開新server囉-容器container tech
  • docker
  • podman

web protocal

• Day 29 雙向溝通之術-websocket

web server

• Day 30 常見的功能網路伺服器common web server
  • nginx
  • Apache
  • Caddy
  • MS IIS
  • MQ(message broker)

Product scaling

• Day extra 伺服器擴展問題server scaling problem
  • migration strategy
  • scaling type
  • Observability

快速說明

ORMs及ODMs

全名是Object-Relational Mapping，他原本是指稱一種技術，指的是讓開發者可以使用程式語言來操作資料庫，但目前指稱ORM通常指的是實現這個技術的library，且ORM指的是操作SQL的庫，操作no SQL的庫，則會被稱為ODM。

使用ORM的好處是

1. 通用性: 可以相同的語法操作不同的資料庫。
2. 基礎安全: 內建一些機制防止類似SQL injection的狀況。
3. 學習曲線低: 這點有點見仁見智，我也有看過一些文章提到，因為還是需要學習操作資料庫的概念，其實這點並不完全對。

缺點則是

1. 效能: 因為多一層將程式轉譯成SQL或no SQL的工作，一定會犧牲部分效能。
2. 複雜查詢的支援低: 當使用複雜語法時，可能還是會需要寫原生語法。且實務上為了排錯，多少還是需要了解資料庫操作語法，完成仰賴ORM或ODM的狀況我覺得是不太可能的。

在JS，常見的ORM及ODM包括有

1. Sequelize: 可操作Postgres, MySQL, MariaDB, SQLite and SQL Server
2. Prisma: 可操作PostgreSQL，MySQL，SQLite
3. Mongoose: 可操作mongodb

資料庫正規化(normalization)

簡單來說，就是一套經過統整，讓資料可以減少重複，並在更新時可以避免異常的原則。
比如說，今天我有個SQL table叫做children跟parent，然後其中一個數據在children叫做就醫時間，但又有另一個數據在parent叫做孩子看診時間，那如果有一天children生病了，是不是就得顧及兩邊的數據都需要同時更新呢?

正規化的規範從低到高有相當多原則，一般而言正規化滿足越多，對數據有越好的約束，但也會增加db的壓力。
根據維基百科的資料，正規化目前最多滿足到第三正規化(3NF)應該就足夠了。

所以為了效能，有時候在考慮資料的情境，有時候會出現反正規化的狀況。
比如該資料變動極少，讀取極多，資料僅需要最終一致，就可能會選擇反正規化。

小結論我會說: 正規化在資料寫入上有利，反正規化則在讀取上有利。

索引indexs

索引真的是令人又愛又恨，基本上只要確定db query效能出現問題，都會優先思考是不是可以靠新增index來解決，那到底索引是什麼呢?

今天不會說索引的原理，不同的資料庫有不同的實現方式，但是概念差不多相同，所以我們會從索引解決了什麼問題，又產生了哪些新的成本開始說起。

假如我們想搜尋「鐵人賽」這個字，我們先從最一般、沒有建立任何索引時會怎麼搜尋資料來思考，在這個情況下，就好像我們要一行行字才能找到想看的字一樣，叫做 Full Scan，有可能這個字被放在那些資料的最後面；

相對之下，有索引的資料的好處就比較好理解了，就像是把資料做過整理一樣。我可能建立了一個索引叫做注音，對，就是字典XD。你可以知道「鐵人賽」這個字可以從鐵的ㄊ的位置開始找起。又或是另一個索引叫做類型，像是百科全書，你可會從台灣或是比賽這種類型開始找起，但總歸是會讓你的速度提升，避免了可能從最前面翻到最後面的狀況發生。

上面的內容聽起來蠻不錯的，那這樣產生什麼成本了?

做一本字典跟百科全書是需要時間的，索引也是如此，大部分我所知的索引也都是會建立新的資料去儲存索引的資料，這個過程就會產生新的空間消耗以及建立索引對db server產生的壓力，這也是建立索引需要考慮的部分。

各式的db都有一些讓你調查query效能的功能或是介面，提供你額外的資訊去思考是否要為一些常用到的query增加索引以增加效率。

於是這邊我們可以跟正規化得出一樣的結論: 在現代儲存空間很便宜所以不考慮的狀況下XD建立索引讓讀取變得有利，但增加了寫入時的成本。