前言

不知道大家會不會覺得在使用電腦時，常常會有鍵盤滑鼠切換的動作，導致工作效率低下？例如在需要開啟一個檔案的時候，可能就會需要先打開 Finder，再用滑鼠點擊開啟檔案；又或是臨時需要翻譯時，就需要先切換到瀏覽器打開 Google Translate 再進行翻譯；想確認接下來的會議連結時，又需要點擊到日曆的 APP 再開啟會議連結。這些切換在無形之中就浪費了不少時間，而 Raycast 就是一個可以幫助你解決這些問題的工具。

今天要來跟大家分享 PostgreSQL 是如何預估 function 的 return rows 的？以及 function 的 return rows 會對 query 的效能有什麼影響？

透過真實案例可以看到當 function 的 return rows 與實際不同時，會造成的效能影響，再透過簡單的分析和 PostgreSQL 原始碼分析做找出原因，最後再用簡單的幾個方式讓 PostgreSQL 可以更準確的預測 function 的 return rows。

環境：PostgreSQL 11.17

題目

題目連結：https://leetcode.com/problems/k-inverse-pairs-array/

給定 $N$ 以及 $K$，求出包含 $1\sim N$ 的序列中，有多少種恰好有 $K$ 個逆序數對。

答案要對 $10^9 + 7$ 取餘。

範例說明

Example 1:

1
2
3

Input: n = 3, k = 0
Output: 1
Explanation: Only the array [1,2,3] which consists of numbers from 1 to 3 has exactly 0 inverse pairs.

Example 2:

1
2
3

Input: n = 3, k = 1
Output: 2
Explanation: The array [1,3,2] and [2,1,3] have exactly 1 inverse pair.

資料副本（Replication）的意思是透過網路，將資料複製到多個節點（機器）上面儲存。Replication 有以下三個好處：

1. 讓資料在地理位置上靠近使用者以降低 network latency。
2. 當部分節點不可用時系統依然可以保持運作，提高可用性（Availability）。
3. 分散 read queries，提高 read throughput。

Replication 的難處在於資料是會更新的，因此如何透過網路同步這些資料的更新是最大的難點。本章節主要探討三種常見的 replication model，分別是 single-leader replication、multi-leader replication 以及 leaderless replication。

嗨大家好，我是 Justin，目前就讀清華大學資訊工程學系四年級，在 Dcard 做 backend intern 也半年了，想跟大家分享在 Dcard 實習這半年來的心得～

在進入 Dcard 之前，因為已經有些後端開發經驗，但是並沒有機會接觸到高流量的系統是如何設計與開發的。因此找實習時，主要就是希望能接觸到大型系統開發以及能使用到最新技術。Dcard 在這方面算是非常符合，流量的部分相信不用多做說明，使用的技術部分也是相當的新，包含 Golang、Kubernetes、Microservices、gRPC 以及 OpenTelemetry 這些雲原生生態系最熱門技術 Dcard 都有在使用！

在 Thirft 與 Protocol Buffers 中，都使用了一種整數壓縮的演算法叫做 ZigZag。

算法本身很簡單，卻也很實用，因此分享給大家 ZigZag 的實作與想法。

應用程式是不會永恆不變的，隨著新的 features 加入資料的儲存格式可能改變。因此本章節主要探討第一章節中所提到的 maintainability 中的 evolvability。

在 relational database 中，通常需要更新 schema；而在 schemaless database 中，新舊版本的資料格式可以同時存在。

Application code 也會因為資料格式的改變而有所變化，但是在大型應用程式中，做到瞬間的版本更新是不可能的：

• Server side applications：通常會執行 rolling upgrade，因此新舊版本的程式會通時運作。

  Rolling Upgrade

  透過逐漸部署新版本到 server，確認新版本正常運作後，才逐漸移除舊版本的部署，以達到 zero-downtime 的版本升級。

• Client side applications：是否更新取決於使用者，因此會同時擁有多種版本在運作。

以上兩點就說明了在軟體開發中，相容性的重要性。相容性包含兩個方向：

• Backward compatibility（向下相容）：新的程式碼可以讀舊的資料。
• Forward compatibility（向上相容）：舊的程式碼可以讀新的資料。

本章節會討論在 JSON、XML、Protocol Buffers、Thrift、Arvo 這些資料格式下的相容性問題，以及在 REST、RPC、Message Queue 下如何使用這些資料格式傳輸資料。

本章節首先介紹資料庫的 storage engine 是如何儲存資料，使得查詢可以變得更快速。並介紹兩種常被資料庫使用的資料結構 LSM-Tree 以及 B-Tree。

再來淺談一般用於網路服務的資料庫與資料分析用的資料庫的設計理念有什麼不同。

最後介紹較不常見的 column-oriented database 的優缺點、設計以及使用情境。

那身為資料庫的使用者，為什麼需要知道資料庫的 storage engine 是如何設計的呢？除了要選出最適合的資料庫之外，為了要對資料庫性能進行調校，也必須了解資料庫底層是如何儲存資料的，才能根據使用情況做出最好的選擇。

本章節主要在介紹目前主流的三個 Data Model，Relational Model、Document Model 以及 Graph Model 的優缺點、演進史以及使用時機。

Data Model 是一層疊一層的：

• 在應用層，資料可能是購物車資訊、金流、商品等在現實世界中的資訊。
• 在後端，我們必須把資料轉換成易於儲存的資料結構，可能是 XML 或 JSON，又或是關聯式資料庫中的 Tables。
• 在資料庫中，XML、JSON 或是 Tables 都必須轉變成 bytes 的形式，使他們能夠被儲存在 memory 或是 disk 上。
• 在硬體層，bytes 必須轉換成電流、磁場等等。

層與層透過定義好的 API 來溝通，可以將背後的複雜實作藏在 API 之後。

各種不同的 data model 背後都會一些使用情境的假設，因此每一種 data model 都有不同的功能、操作，對於支援的操作，效能也有好與壞之差別。

也因為要精通一種 data model 是十分困難的（光是 relational data modeling 就有這麼多書籍），因此在使用之前先綜觀的了解每一種 model 的優缺點以及使用時機是非常重要的。

Introduction

現在的軟體基本上都不是 CPU Bound，而是 Data-Intensive 的，也就是大多數的瓶頸都在資料的量而不是計算的量。因此大多數的應用程式會依靠多種工具來滿足不同情境下的資料使用。

例如一個後端可能會用到 MySQL、PostgreSQL 來儲存資料，用 Redis 來做快取，用 ElasticSearch 來做搜尋引擎，用 RabbitMQ、NATS 來做異步的消息傳輸。有各種工具可以滿足不同需求的資料使用方式，因此我們需要知道在設計不同需求的系統時，要如何挑選、使用這些技術與工具。下圖即是一種可能的系統架構：

本章節重點先放在三項設計系統時的要點：可靠性（Reliability）、可擴展性（Scalability）以及可維護性（Maintainability）。