本文主要介紹子庫子表方案(美團子庫子表)，下面一起看看子庫子表方案(美團子庫子表)相關(guān)資訊。
用于數(shù)據(jù)庫和表共享的常見中間件包括cobar、tddl、sharding-jdbc、atlas和mycat。
cobar:由阿里巴巴b2b團隊開發(fā)并開源，屬于代理層方案。不支持讀寫分離、存儲過程、跨庫連接和分頁等操作。
tddl:由淘寶團隊開發(fā)，屬于客戶端層方案。不支持join、多表查詢等語法，就是基本的crud語法還可以，但是支持讀寫分離。沒多大用，需要靠淘寶 鉆石配置管理系統(tǒng)。
atals:360是開源的，屬于代理層方案。之前有一些公司在用，但是有一個很大的問題就是社區(qū)沒有維護好。
sharding-jdbc:當當是開源的，屬于客戶端層方案。支持子數(shù)據(jù)庫和子表、讀寫分離、分布式id生成、靈活事務(wù)(盡力交付事務(wù)、tcc事務(wù))。社區(qū)很活躍。
mycat:基于cobar改造，屬于代理層方案，配套功能完善，社區(qū)活躍。
優(yōu)缺點分析:分片——jdbc和mycat
sharding-jdbc這種客戶端層的方案，優(yōu)點是無需部署，運維成本低，但是如果需要升級，每個系統(tǒng)都需要升級再發(fā)布。
mycat，代理層方案，對各個項目透明，屬于中間件，但是運維成本高。
庫和表的哈希算法:我可以把id分成3個庫，然后把id分成4個表。
11%3 = 2
11%4 = 3
第二個數(shù)據(jù)庫，第三個表。
按照時間（計算、查找等）
2022年一個數(shù)據(jù)庫，2023年一個數(shù)據(jù)庫。
優(yōu)缺點:哈希法:可以平均分擔(dān)請求壓力。擴張困難。
按時間擴展容量很方便，但缺點是大部分請求訪問的是最新的數(shù)據(jù)庫。
落地實現(xiàn):可以從一開始就考慮擴容，建四個數(shù)據(jù)庫，每個數(shù)據(jù)庫有四個表。事實上，只有一個包含四個數(shù)據(jù)庫的數(shù)據(jù)庫服務(wù)器。
對于dba來說，擴容的時候直接打開一個新的數(shù)據(jù)庫服務(wù)器，然后把數(shù)據(jù)庫導(dǎo)入過去就可以了。我們只需要修改數(shù)據(jù)庫連接配置，原來的數(shù)據(jù)庫哈希規(guī)則不需要修改。
遷移方案:方案一:雙寫方案系統(tǒng)修改數(shù)據(jù)與子庫、子表中間件作原表，增加一個將原表數(shù)據(jù)遷移到子庫、子表的服務(wù)。通常，在表規(guī)范中有一個updatetime。在遷移期間比較此更新時間，以避免舊數(shù)據(jù)覆蓋新數(shù)據(jù)。遷移完成后，比較原庫和新子庫的數(shù)據(jù)是否相同，程序運行幾天。
方案二:可以借鑒redis主從復(fù)制。方案我們知道redis從主復(fù)制到從時，后臺會生成一個rdb快照。然后，該時刻之后的所有操作都將在數(shù)據(jù)副本上執(zhí)行。rdb完成后，復(fù)制數(shù)據(jù)會覆蓋原始數(shù)據(jù)。
我們也可以這樣做，但是代碼實現(xiàn)起來有點復(fù)雜。
創(chuàng)建一個零時間表，查詢時操作原表的臨時表進行查詢。零時間表中將有一個isdelete字段。如果它被邏輯刪除，它不會 沒關(guān)系。
插入數(shù)據(jù)時插入臨時表。
修改數(shù)據(jù)時，找出原始數(shù)據(jù)，然后修改要修改的字段，再插入臨時表。
刪除數(shù)據(jù)時，如果是邏輯刪除，其實和修改是一樣的。如果是真的刪除，找出數(shù)據(jù)，在isdelete上貼一個標簽，表示數(shù)據(jù)已經(jīng)被刪除。
查詢時，從原表中查詢出來后，需要判斷是否已經(jīng)在臨時表中刪除。而且零時間表的數(shù)據(jù)要一起處理，id相同的數(shù)據(jù)使用臨時表的數(shù)據(jù)，如果進行分頁查詢可能會產(chǎn)生一些問題。
將所有原始表數(shù)據(jù)復(fù)制到子數(shù)據(jù)庫表數(shù)據(jù)后，停機，將零時表數(shù)據(jù)更新到子數(shù)據(jù)庫表。
方案三:如果將數(shù)據(jù)插入舊庫和新庫，則直接插入新庫。
如果修改數(shù)據(jù)，請從舊數(shù)據(jù)中刪除數(shù)據(jù)，并將其插入到新數(shù)據(jù)庫中。
如果數(shù)據(jù)被刪除，新庫和舊庫將被一起刪除。
查詢數(shù)據(jù)，從舊庫查詢，從新庫查詢。如果舊庫存在，請插入新庫并返回。
分頁查詢:我想檢查第5頁的數(shù)據(jù)，舊數(shù)據(jù)庫的前5頁和新數(shù)據(jù)庫中每個表的前5頁。數(shù)據(jù)存入內(nèi)存后，我會一起找到第5頁。
方案2和方案3都不可取，因為增刪查的原始代碼很多，修改邏輯的工作量極其繁重。
子數(shù)據(jù)庫和子表的id生成策略:1。數(shù)據(jù)庫主鍵是自增長的。
得到一個表，主鍵是自增的，負責(zé)生成主鍵。麻煩，性能低。
2.印時戳
以時間為主鍵，可能會重復(fù)。當數(shù)據(jù)庫a和數(shù)據(jù)庫b具有相同的時間時，它們生成相同的id。
3.uuid
雖然id是唯一的，但是沒有順序。
4 .雪花雪花算法
64位二進制，第一位為0，41表示時間，5位機房id，5位機器id，12位表示當前毫秒內(nèi)生成了哪個id。
將64位二進制轉(zhuǎn)換為十進制就是雪花算法id。只有32個機房，32臺機器。否則，您將報告一個錯誤?；蛘吣憧梢詫C器碼取模，這樣就會有重復(fù)的id。
標簽:
數(shù)據(jù)數(shù)據(jù)庫
了解更多子庫子表方案(美團子庫子表)相關(guān)內(nèi)容請關(guān)注本站點。