1. 程式人生 > >app後端設計(8)-- 資料庫分表

app後端設計(8)-- 資料庫分表

    當專案上線後,隨著使用者的增長,有些資料表的規模會以幾何級增長,當資料達到一定規模的時候(例如100萬條),查詢,讀取效能就下降得很厲害,這時,我們就要考慮分表。

   更新表資料時會導致索引更新,當單表資料量很大時這個過程比較耗時,這就是為什麼對大表進行新增操作會比較慢的原因,並且更新表資料會進行表級鎖或者行鎖,這樣就導致其他操作等待。

    所以我們將大表拆分為多個子表,那麼在更新或者查詢資料的時候,壓力會分散到不同的表上。由於分表之後每個表的資料較小,不管是查詢還是更新都極大的提高了速度,即使出現最壞的“鎖表”的情況,那其他表還是可以並行使用。

1.分表的策略

分表有多種策略:

(1)按使用者id分表,例如id為1-10000在表1,id為10001-20000在表2

(2)插入的時間分表

(3)按每個表固定記錄行數拆分

    在專案,由於這個表是儲存使用者的通訊錄,為了保證一個使用者的所有通訊錄資料都儲存在同一個表,選擇的分表方式就是(1),按使用者id分表。

2. 分表策略確定下來了,還有一個非常嚴重的問題,因為現在使用者的資料都分散在不同的表中,之前的業務功能如何保證呢?比如說我要插入一條記錄、更新一條記錄、刪除一條記錄、查詢統計資料,現在要怎麼處理呢?

    如果分表的儲存引擎是MyISAM,這裡有一種很簡單的處理方法。利用merge儲存引擎將拆分的表合併成一張表。當然了,如果使用InnoDB,也能通過alter table命令把InnoDB變為MyISAM。

     MERGE儲存引擎可以將N個子表聯合在一起,看成是一個整表,實際上還是N個真實的子表。

    當分表的時候,還要一個問題,因為我們是在線上專案中分表的,需要考慮怎麼樣使分表的操作對使用者的影響最少。

3. 一個例子

    假設有表contact,儲存了9000個使用者的通訊錄資料,平均一個使用者有聯絡人100個,那麼這個表的規模就達到了90萬條資料,我們需要對這個表分表。

    下面的指令碼演示了怎麼在不關閉mysql服務的情況下對contact 分表

-- ----------------------------
-- 建立根據原來的表格式建立一個臨時表,並把儲存引擎改為MYISAM
-- ---------------------------
CREATE TABLE contact_temp LIKE contact;
ALTER TABLE contact_temp ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci ; 

-- ----------------------------
-- 建立分表contact_temp1,contact_temp2
-- ---------------------------
CREATE TABLE contact_temp1 LIKE contact_temp;
CREATE TABLE contact_temp2 LIKE contact_temp;

-- ----------------------------
-- 按使用者id分表,把id<5000 儲存在表1,id>=5000 and id<10000 儲存在表2,
-- ----------------------------
INSERT INTO contact_temp1 SELECT * FROM contact where uid<5000;
INSERT INTO contact_temp2 SELECT * FROM contact where uid>=5000 and uid<10000;


-- ----------------------------
-- 把原來的表改名,因為在mysql中不能有重複的表明,這樣子最終建立的MERGE引擎的表就能使用原來的表名
-- ----------------------------
RENAME TABLE contact TO contact_bak;
CREATE TABLE contact LIKE contact_temp;

-- ----------------------------
-- 先把原來刪除表上的主鍵的自增屬性去掉,再刪除主鍵
-- ----------------------------
ALTER TABLE contact CHANGE `id` `id`  int(11);
ALTER TABLE contact DROP PRIMARY KEY;

-- ----------------------------
-- 把表的儲存引擎改為MERGE
-- ----------------------------
ALTER TABLE contact  ENGINE=MERGE UNION=(contact_temp1,contact_temp2) INSERT_METHOD=LAST;


-- ----------------------------
-- 刪除所有的臨時表
-- ----------------------------
drop TABLE contact_bak;
drop TABLE contact_temp;


如果您覺得這系列的文章對你有所幫助,歡迎打賞。
支付寶賬號:[email protected] 收款人:曾健生

[文章作者]曾健生

[作者郵箱][email protected]

[作者QQ]190678908

[新浪微博] @newjueqi

[部落格]http://blog.csdn.net/newjueqi

          http://blog.sina.com.cn/h6k65


相關推薦

app設計(8)-- 資料庫

    當專案上線後,隨著使用者的增長,有些資料表的規模會以幾何級增長,當資料達到一定規模的時候(例如100萬條),查詢,讀取效能就下降得很厲害,這時,我們就要考慮分表。    更新表資料時會導致索引更新,當單表資料量很大時這個過程比較耗時,這就是為什麼對大表進行新增操作

app設計(7)-- 專案管理

移動網際網路行業是個快速發展的行業,需求不斷變化,產品更新快。基於移動網際網路的以上特點,在開發產品的過程中,我們放棄了傳統的瀑布流開發模型,引入了精益的理念和scrum這個敏捷開發框架,下面談談實施過程中的一些經驗。    scrum簡介:Scrum是一個敏捷開發框架

app設計-資料增量更新

    使用資料的app本地儲存,能減少網路的流量,同時極大提高了使用者的體驗(想想,很多資料都能在app本地獲取,顯示的速度當然快)。使用了本地儲存後,需要考慮的是資料的增量更新方案。     什麼是資料的增量更新?假設,使用者A的首頁在資料表中是有40條資料,id1-40,app每次獲取10條資料。第一

appapi設計【轉】

不用 ray 版本更新 array nvl 動態生成 出錯 命名 test 博客:https://blog.csdn.net/newjueqi/article/details/44037011 app和後端的交互,一般都是通過後端提供的api實現。api的設計,估計很多

8.app和web的區別

  很多從web後端轉到app後端的小夥伴經常很茫然,不知道這兩者之間有啥區別。本文通過例子,分析web後端和app後端的區別,使各位更好地把握app後端的架構。   (1) app後端要慎重考慮網路傳輸的流量,主要是api設計,圖片處理上     現階段,手機上網的資費還

1.APP開發系列:登陸系統設計中的注意問題

想寫這個系列很久了,因為之前做這個東西花費了大量的精力,有必要分享出來與大家共享。以前也寫了一些關於 APP後端開發的系列文章 由於當初功力不夠,很多問題描述不清楚或者解決方案過於複雜、不嚴謹等。 這一次查了很多資料,問了很多相關人士。準備再結合自己實際工

C設計開發 - 第6章-武技-常見組件上三路

錯誤 design 謝大 pos cde strong com wan .com 正文   第6章-武技-常見組件上三路 後記   如果有錯誤, 歡迎指正. 有好的補充, 和疑問歡迎交流, 一塊提高. 在此謝謝大家了. C後端設計開發 - 第6章-武技-常

C設計開發 - 第7章-真氣-遺失的網絡IO

com itl ron alt book blank nbsp 如果 tree 正文   第7章-真氣-遺失的網絡IO 後記   如果有錯誤, 歡迎指正. 有好的補充, 和疑問歡迎交流, 一塊提高. 在此謝謝大家了. ボクらの冒

模仿J2EE的session機制的App會話信息管理

序列化 相關 || redis 字節 param div 模仿 remove 此文章只將思想,不提供具體完整實現(博主太懶,懶得整理),有疑問或想了解的可以私信或評論 背景   在傳統的java web 中小型項目中,一般使用session暫存會話信息,比如登錄者的身份信息

數據設計,分庫

倉庫 聚集 AD 記錄 事務處理 功能 出了 cti 規模 當今的數據處理大致可以分成兩大類:聯機事務處理OLTP(On-Line Transaction Processing)、聯機分析處理OLAP(On-Line Analytical Processing)。OLTP是

Odoo作為App時如何調試App

技術分享 Edito 管理系 cno onf span edi 後臺系統 pre 轉載請註明原文地址:https://www.cnblogs.com/cnodoo/p/9307340.html 一:Odoo可以作為app後臺+後臺管理系統使用 Odoo作為一個可供

APP搭建整理

常見的APP後端搭建 語言有 Java,PHP,Python,下面可以簡單瞭解一下 Java: https://blog.csdn.net/a_running_wolf/article/category/6188707 http://keeganlee.me/post/pract

記一次資料庫的初體驗!

業務前景 由於小編所在的公司是傳統型公司,而業務對接的確實像螞蟻貨運險這樣的大業務,從2017年中旬對接到公司的業務資料量大約一天150W左右資料,而去年的雙十一最高峰值則達到2000W一天的資料量!公司所入的資料量全部存在10多張不同業務的表中,而中途資料庫已經告警過幾次,顯然這樣

mysql資料庫時,使用mybatis動態設定

mybatis中傳遞引數一般使用#{},但是當引數是表名時#{}就會報錯。這是為啥呢? 這是因為#{ } 解析為一個 JDBC 預編譯語句(prepared statement)的引數標記符。 簡單來講:select * from user_#{tableVersion} 會被解析為

設計harden的理解隨筆

       隨著消費類電子的迅猛發展,晶片的功能越來越複雜,規模也越來越大。晶片中整合的模組也越來越大、越來越複雜,如處理器、儲存模組等。為了方便全晶片的綜合實現,這些大的模組通常採用單獨固化(harden)的方式合入全晶片網表(netlist)中。 &

Java架構/一致性Hash演算法在資料庫中的實踐

最近有一個專案,其中某個功能單表資料在可預估的未來達到了億級,初步估算在90億左右。與同事詳細討論後,決定採用一致性Hash演算法來完成資料庫的自動擴容和資料遷移。整個程式細節由我同事完成,我只是將其理解併成文,供有相同問題的同行參考。 參看此文的兄弟,預設各位已經熟悉一致性hash

一致性Hash演算法在資料庫中的實踐

最近有一個專案,其中某個功能單表資料在可預估的未來達到了億級,初步估算在90億左右。與同事詳細討論後,決定採用一致性Hash演算法來完成資料庫的自動擴容和資料遷移。整個程式細節由我同事完成,我只是將其理解併成文,供有相同問題的同行參考。 參看此文的兄弟,預設各位已經熟悉一致性hash演算法了。此文僅僅闡述程式

Python 大資料庫備份阿里雲RDS資料庫匯出壓縮

思路:因為有的資料庫比較大,整體壓縮之後還是會有幾個G內容,既不方便下載也不方便恢復,然後就想到了對獨立的表分開進行備份。 1.連線阿里雲rds 2.建立資料夾,層級關係(資料庫名->日期->表名壓縮包) 3.迴圈需要備份的資料庫 4.從相應的資料庫查詢全

shell 備份資料庫備份

對資料庫分表備份。 #!/bin/sh # 定義資料庫連線引數 db_host=127.0.0.1 db_port=3306 db_username=root db_password=123456 #定義當前伺服器要備份的資料庫 db_name=(bajie beida

資料庫分庫

一、MySQL擴充套件具體的實現方式 隨著業務規模的不斷擴大,需要選擇合適的方案去應對資料規模的增長,以應對逐漸增長的訪問壓力和資料量。 關於資料庫的擴充套件主要包括:業務拆分、主從複製,資料庫分庫與分表。這篇文章主要講述資料庫分庫與分表 (1)業務拆分 在 大型網站應用之海量資料和