前言

目前公司的專案大量使用 Github Action 跑自動化 CI/CD 的 pipelines 去部署服務到 AWS 環境，近期將原本 CI/CD pipelines 上與 AWS service 驗證的 workflows 做調整，驗證方式從原本藉由 IAM User 進行 assume role 的方式改成透過 AWS ODIC 的方式完成。

相較於使用 IAM user 的 secrets 驗證，OIDC 的作法能幫助我們省去管理金鑰的麻煩。

本文會 AWS 作為 cloud provider，設定方法也是以 AWS 為範例，以下內容建議有 GitHub Action 及 AWS IAM 這兩項先備知識比較能理解。

前言

上一篇記錄了資料庫儲存資料的概念與其儲存結構，本文將初步探討資料庫裡的 索引(Index) ，了解 Index 的作用、行為以及實際操作方式。

前言

本文主要探討資料庫裡的儲存概念，了解資料庫是如何將資料存在硬碟(Disk)裡，儲存原理在各家主流資料庫會有差異，但大方向是相同的，內容會以 Postgres 為主，少部分提及其他資料庫的做法。

前言

過去在使用 Redis 指令時，都是一條一條指令發送給 Redis ，每條指令都會經過 發送指令 -> Redis server 接收指令 -> 處理資料 -> 回傳結果 的流程，這樣一來一回花費的時間稱作 **round-trip time (簡稱RTT)**，在傳送過程中還需考量網路每次建立連線耗時與延遲問題。

若同時有多條指令要處理時，RTT 就會拉長，為縮短多個指令在同時間排隊分別執行造成的效能問題，Redis 提供 Pipeline 的機制，讓多個指令在同時間執行且不需相互等待，一次回傳所執行完的結果。

既然這項機制對於效能提升有幫助，來了解一下 Redis Pipeline 的概念及使用上要注意的項目吧！

前言

為確保資料的正確性， Redis 也提供了類似於關聯式資料庫的 Transaction 機制，但 Redis 提供的 Transaction 有一些相異之處 e.g. 不支援 rollback，本篇文章紀錄 Redis Transaction 的概念與使用方式。

前言

上篇談到 Redis 的 SET 資料結構，本篇會探討擁有與 SET 相似特性的 Sorted Sets！相比較兩者之間的差異及用途。

前言

昨日的文章討論到 Redis 儲存物件用的資料結構 - Hash，本篇接著探討 Redis 的另一個資料結構 - SET

前言

上一篇探討了 Redis Lists 資料結構，本篇將紀錄 Redis 儲存物件用的資料結構 - Hash

前言

延續 上篇 討論到 Redis 基礎的資料結構 - String，本篇要討論另一個資料結構 - Lists

前言

Redis 是熱門且開源的資料庫，以記憶體為主(in-memory)進行資料存取，並以鍵值 (key-value) 的形式存放資料庫內。

由於資料是基於記憶體進行讀寫，記憶體讀取的速度較一般硬碟來得快！Redis 這項優勢被廣泛地運用在大型系統裡做資料快取，加快整體系統效能，不僅有助於提高系統回應的速度，同時能減少關聯式資料庫的工作量(前面 Redis 可以應付使用者送來的請求，就不需要再到後方主資料庫讀取資料)。