f1是google開發的分布式關係型資料庫，主要服務於google的廣告系統。google的廣告系統以前使用mysql，廣告系統的使用者經常需要使用複雜的query和join操作，這就需要設計shard規則時格外注意，盡量將相關資料shard到同一臺mysql上。擴容時對資料reshard時也需要盡量保證這一點，廣告系統擴容比較艱難。在可用性方面老的廣告系統做的也不夠，尤其是整個資料中心掛掉的情況，部分服務將不可用或者丟資料。對於廣告系統來說，短暫的宕機服務不可用將帶來重大的損失。為了解決擴容/高可用的問題，google研發了f1，乙個基於spanner 的跨資料中心的分布式關係型資料庫，支援acid，支援全域性索引。2023年初已上線。
f1的幾個特性
高可用可以說，幾乎都是spanner搞定的，spanner通過原子鐘和gps接收器實現的truetime api搞定了跨資料中心時鐘誤差問題，進而搞定了分布式事務的時序問題，從而搞定了對外部的一致性。多個副本的一致通過paxos搞定。
全域性索引
基於spanner提供的分布式讀寫事務(嚴格的兩階段鎖+兩階段提交)，f1實現了全域性索引。索引表和資料表實際上是兩張表，這兩張表一般來說存在不同的spanner機器上，兩張表的一致性通過spanner的分布式讀寫事務解決。在這裡，同乙個事務中涉及的全域性索引不宜過多，因為每多乙個全域性索引，相當於多乙個兩階段提交中的participant，對於分布式事務來說，participant越多，效能越差，並且事務成功的概率越小。
級聯schema
思想和megastore類似，表和表之間有層次關係。將相關表中的相關資料儲存在一台機器上。比如對於廣告系統來說，就是將乙個廣告客戶以及他的compaign等儲存在一起，廣告客戶作為一張表，compaign作為另外一張表，廣告客戶表中每行代表乙個廣告客戶，廣告客戶表叫做root表，compaign表叫做子表，廣告客戶表中的每行叫做root記錄，compaign表中行叫做子記錄，那麼同乙個廣告客戶下所有的compaign和這個廣告客戶都儲存在同一臺spanner機器上。這樣做的好處就是乙個操作就可以取到所有的相關資料，join很快，不用跨機。
三種事務
快照讀。 直接利用spanner提供的快照讀事務
悲觀事務。 直接利用spanner提供的讀寫事務，加兩階段鎖
樂觀事務。 基於spanner的悲觀事務實現的。這樣的事務分為兩個階段，第乙個階段是讀階段，持續時間不限，不加任何鎖，第二個階段是寫階段，即commit事務階段。基本思想是在讀階段將訪問的所有行的最後一次修改時間儲存在f1客戶端，寫階段將所有的時間發到f1，f1開啟乙個spanner的讀寫事務，這個讀寫事務會重新讀取這些行的最後一次修改時間進行check，如果已經變了，說明檢測到了寫寫衝突，事務abort。
f1預設使用樂觀事務，主要考慮了如下幾個方面：
由於讀階段不加鎖，能容忍一些客戶端的誤用導致的錯誤
同樣，讀階段不加鎖，適合f1中一些需要和終端互動的場景。
對於一些出錯場景，可以直接在f1 server進行重試，不需要f1 client參與。
由於所有的狀態都在f1 client端維護的，故某個f1 server掛掉後，這個請求可以發給其他的f1 server繼續處理。
當然，這會帶來兩個問題：
對於不存在的行，沒有最後一次修改時間，那麼在其他讀事務執行期間，同一條語句執行多次返回的行數可能不一樣，這種情況在repeatable read這種隔離級別下是不允許的，這個問題典型的解決方案是gap鎖，即範圍鎖，在f1中，這個鎖可以是root表中root記錄的一列，這個列代表一把gap鎖，只有拿到這把鎖，才能往child表中某個範圍插入行。
對同一行高併發修改效能低。顯然，樂觀協議不適合這種場景。
部署google將廣告系統使用的f1和spanner集群部署在美國的5個資料中心，東海岸兩個，西海岸兩個，中間乙個。相當於每份資料5個副本，其中東海岸乙個資料中心被作為leader資料中心。在spanner的paxos實現中，5個副本中有乙個leader副本，所有的對這個副本的讀寫事務都經過它，這個leader副本一般就存在leader資料中心中。由於paxos協議的執行只需要majority響應即可，那麼一次paxos操作的延時基本取決於東海岸的leader資料中心和東海岸另外乙個資料中心，和中間那個資料中心之間的延時。從這裡也可以看出，對於寫比較多的f1 client來說，f1 client和f1 server都部署在leader資料中心效能最好。在這個配置下，f1使用者的commit延時大概在50ms到150ms之間。讀延時大約5～10ms。
DRDS分布式關係型資料庫
1建立單庫單錶 create table single tbl id int,name varchar 30 primary key id 2單庫單錶 同乙個資料庫，同一張表，比如我自的資料庫裡面有一張表student,若想要再建立一張一樣的表，所有欄位都一樣的，則可以用下面的方式編寫 3分庫不分表...
TiDB 開源分布式關係型資料庫
tidb server 負責接收 sql 請求，處理 sql 相關的邏輯，並通過 pd 找到儲存計算所需資料的 tikv 位址，與 tikv 互動獲取資料，最終返回結果。tidb server 是無狀態的，其本身並不儲存資料，只負責計算，可以無限水平擴充套件，可以通過負載均衡元件 如lvs hapr...
分布式資料庫
網路選課系統中分布式資料庫設計 何翠雙王巧雲張麗麗 摘要 關鍵字 選課 分布式 資料庫 distributed system of on line course choosing abstract key words course choosing distributed database 隨著學校...