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條資料。第一
app後端api設計【轉】
不用 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)業務拆分 在 大型網站應用之海量資料和