MySQL垂直拆分和水平拆分的優缺點和共同點總結

數據的拆分（Sharding）根據其拆分分規則的類型，可以分為兩種拆分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之為數據的垂直（縱向）拆分； 另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之為數據的水平（橫向）拆分。垂直拆分的優點： 拆分后業務清晰，拆分規則明確 系統之間進行整合或擴展很容易 按照成本、應用的等級、應用的類型等將表放到不同的機器上便于管理 方便實現動靜分離，冷熱分離的數據庫表的設計模式 數據維護相對簡單垂直拆分的缺點： 部分業務表無法Join,只能通過接口方式解決，提高了系統的復雜度 受每種業務的不同限制，存在單庫性能瓶頸，不易進行數據擴展和提升性能 事務處理復雜水平拆分的優點： 單庫單表的數據能保持在一定的量級，有助于性能的提高。 切分的表結構相同，應用層改造較少，只需要增加路由規則即可。 提高了系統的穩定性和負載能力。 水平拆分的缺點： 切分后，數據是分散的，跨庫join操作難和性能差 拆分規則難以抽象 分片事務的一致性難以解決 數據擴容的難度和維護量極大綜上所述，垂直拆分和水平拆分的共同點為： 存在分布式事務的問題 存在跨節點Join問題 存在跨節點合并排序和分頁問題 存在多數據源管理的問題

?MySQL垂直切分和水平切分概念和優缺點介紹

數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關系，將同一個表中的 數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。垂直切分 一個數據庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面， 如下圖：垂直切分的優缺點介紹： 優點： 拆分后業務清晰，拆分規則明確。 系統之間整合或擴展容易。 數據維護簡單。 缺點： 部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。 事務處理復雜。 由于垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過于龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平 拆分來做解決。水平切分 相對于垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切 分到其他的數據庫中，如下圖:水平切分的優缺點介紹： 優點： 拆分規則抽象好，join操作基本可以數據庫做。 不存在單庫大數據，高并發的性能瓶頸。 應用端改造較少。 提高了系統的穩定性跟負載能力。 缺點： 拆分規則難以抽象。 分片事務一致性難以解決。 數據多次擴展難度跟維護量極大。 跨庫join性能較差。垂直切分和水平切分共同的特點和缺點有： 引入分布式事務的問題。 跨節點Join的問題。 跨節點合并排序分頁問題。 多數據源管理問題。

深入理解關系型數據庫的數據水平切分和垂直切分

雖然在云計算時代，傳統數據庫存在著先天性的弊端，但是NoSQL數據庫又無法將其替代，NoSQL只能作為傳統數據的補充而不能將其替代，所以規避傳統數據庫的缺點是目前大數據時代必須要解決的問題。如果傳統數據易于擴展，可切分，就可以避免單機（單庫）的性能缺陷，但是由于目前開源或者商用的傳統數據庫基本不支持大規模自動擴展，所以就需要借助第三方來做處理，下面就來分析一下如何進行數據切分。何為數據切分？簡單來說，就是指通過某種特定的條件，將我們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單臺設備負載的效果。數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。水平切分于垂直切分相比，相對來說稍微復雜一些。因為要將同一個表中的不同數據拆分到不同的數據庫中，對于應用程序來說，拆分規則本身就較根據表名來拆分更為復雜，后期的數據維護也會更為復雜一些。垂直切分一個數據庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：blob.png系統被切分成了，用戶，訂單交易，支付幾個模塊。一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數據對應到數據庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。但是往往系統之有些表難以做到完全的獨立，存在這擴庫join的情況，對于這類的表，就需要去做平衡，是數據庫讓步業務，共用一個數據源，還是分成多個庫，業務之間通過接口來做調用。在系統初期，數據量比較少，或者資源有限的情況下，會選擇共用數據源，但是當數據發展到了一定的規模，負載很大的情況，就需要必須去做分割。一般來講業務存在著復雜join的場景是難以切分的，往往業務獨立的易于切分。如何切分，切分到何種程度是考驗技術架構的一個難題。下面來分析下垂直切分的優缺點：優點：拆分后業務清晰，拆分規則明確。系統之間整合或擴展容易。數據維護簡單。缺點：部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。事務處理復雜。由于垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過于龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決。水平切分相對于垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中，如圖：blob.png拆分數據就需要定義分片規則。關系型數據庫是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會員的角度來分析，商戶訂單交易類系統中查詢會員某天某月某個訂單，那么就需要按照會員結合日期來拆分，不同的數據按照會員ID做分組，這樣所有的數據查詢join都會在單庫內解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數，就需要按照商戶ID做拆分；但是如果系統既想按會員拆分，又想按商家數據，則會有一定的困難。如何找到合適的分片規則需要綜合考慮衡量。幾種典型的分片規則包括：按照用戶ID求模，將數據分散到不同的數據庫，具有相同數據用戶的數據都被分散到一個庫中。按照日期，將不同月甚至日的數據分散到不同的庫中。按照某個特定的字段求摸，或者根據特定范圍段分散到不同的庫中。如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用用戶ID求模舉例：blob.png既然數據做了拆分有優點也就優缺點。優點有：拆分規則抽象好，join操作基本可以數據庫做。不存在單庫大數據，高并發的性能瓶頸。應用端改造較少。提高了系統的穩定性跟負載能力。缺點有：拆分規則難以抽象。分片事務一致性難以解決。數據多次擴展難度跟維護量極大。跨庫join性能較差。前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有：引入分布式事務的問題。跨節點Join的問題。跨節點合并排序分頁問題。多數據源管理問題。針對數據源管理，目前主要有兩種思路：A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；B. 通過中間代理層來統一管理所有的數據源，后端數據庫集群對前端應用程序透明；可能90%以上的人在面對上面這兩種解決思路的時候都會傾向于選擇第二種，尤其是系統不斷變得龐大復雜的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常有幫助的。由于數據切分后數據Join的難度在此也分享一下數據切分的經驗：第一原則：能不切分盡量不要切分。第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好。第三原則：數據切分盡量通過數據冗余或表分組（Table Group）來降低跨庫Join的可能。第四原則：由于數據庫中間件對數據Join實現的優劣難以把握，而且實現高性能難度極大，業務讀取盡量少使用多表Join。

高并發熱點/單點數據_性能問題解決方案

數據的熱點單點問題由于其獨有的高訪問特性，在性能上一直都一大難題，IT界的大牛們也一直在尋求一種更為優化的解決方案！其中也不乏很多優秀的解決方案，但隨著業務的不斷攀升和互聯網的高速發展，也就顯得捉襟見肘，可見對此探索的重要性！最近項目中也遇到了此瓶頸，請容我將前因后果以及我自己設想的粗陋方案娓娓道來，歡迎大神們拍磚，在下感激不盡！前段時間接了一個雙11的活動，業務邏輯：用戶購買某一類商品后，活動期間的4個整點在活動頁點擊按鈕領取支付寶紅包，每個時段獎品數量有限，先到先得。聽著很簡單，可是活動開始時，異常火熱，流量超過了我們的預估，本來是分時段領取獎品，結果演變為了秒殺。當時每個整點的QPS瞬間飆高，響應時間RT短時間內居高不下，但是整個Check下來應用全部機器的負載都非常正常，后來全面查找原因，才找到問題的根源，是由于每個時段更新數據庫同一條獎品導致超時！整點開搶后瞬時巨量的請求同時涌入，即使我們Apache端做過初步限流，應用也做了信號量的控制，而且加上分布式緩存的使用，減緩了相當大的壓力，整個業務邏輯校驗階段運作良好，但是系統的瓶頸就轉移到其他環節：減獎品庫存!因為我們每個時段只有一個獎品A，每次減庫存都是update獎品A中的獎品余額字段！大量符合發獎要求的用戶請求瞬時涌入數據庫去更新此條記錄，update鎖行，導致后面的請求全部排隊等待，等前面一個update完成釋放行鎖后才能處理下一個請求，大量請求等待，占用了數據庫的連接！一旦數據庫同一時間片內的連接數被打滿，就會導致這個時間片內其他后來的全部請求因拿不到連接而超時，導致訪問此數據庫的其他環節也出現問題！所以RT就會異常飆高！根據木桶理論，我們后續肯定必須得優化這個最短板，將這個瓶頸解決!針對這樣的情況，我們這邊出了兩套方案：1、強依賴分布式緩存達到減庫存的目的；2、熱點/單點數據拆分，弱依賴分布式緩存，采用分散熱點的方式減庫存.下面請允許我詳細分解下這兩套方案，也希望大家提各種建設性意見！一、強依賴分布式緩存應用中使用分布式緩存來存儲當前時間段的獎品余額，有用戶中獎則將此緩存中的余額減一，不需要查詢和實時更新數據庫，而是每隔自定義的一段時間將緩存中的余額異步更新至數據庫中。優點：這種方式完全依賴于緩存，讀寫速度快，不需要實時更新數據庫，降低了數據庫相當大的壓力；缺點：緩存不是100%穩定，很容易丟，即使采用持久化的緩存，在高并發下有時也會出問題；一旦丟失數據，這樣就導致數據庫記錄的獎品余額比實際真實存在的獎品余額要多，這個時候讀數據庫，就會導致獎品多發，也就是所謂的超賣！二、熱點/單點數據拆分，弱依賴分布式緩存某時段的一個獎品拆分為多條后，如何能保證先到先得的業務需求將獎品準確發完，這里就引入分布式緩存作為輔助，緩存不完全穩定沒關系，只是借助其在多條獎品中進行準確分發，當數據庫所有獎品都有余額的情況時，能減少查詢操作！只有當某一條獎品余額為0時緩存中的數據才會失效，這時才需要查詢一次數據庫！步驟：1、 同個時段的獎品拆為多份(比如10份），加行號N區分（1~10），獎1~10的數值存入數組M中；2、 根據行號1~10 ，查詢分布式緩存中是否存在各行獎品對應的記錄（緩存中存放沒余額的獎品行）；是： 將存在的行號存入數組P；否： 數組P值為NULL；3、 數組M-數組P=數組R；4、 判斷數組R是否為空 ;是： 沒有獎品余額，返回未中獎！否： 在數組R中隨機一個行號L；5、 更新數據庫表，將L行獎品余額減一；更新成功： 減獎品庫存成功，直接返回發獎成功！更新失敗： 極大可能原因是由于沒有獎品導致5.1、 查詢數據庫中這10個獎品List（全量list）；5.2、 將List中沒有獎品余額的行同步至對應的緩存（第2 步），并判斷List中是否所有獎品行余額全為0；是： 無獎品，返回未中獎；否： List中選擇一個有余額的獎品，最好是余額最多的，將行號存入L，執行第5 步；流程圖:優點：此方案不會發生獎品多發的情況，將單行數據分拆為多行，分散了熱點，同樣可以減輕數據庫更新時超負荷長鏈等待導致的連接被等待用戶占用而后續請求超時，可以通過拆分為適量的行來解決單點熱點數據帶來的性能問題！缺點：此方案需要做業務拆解，增加了業務的復雜性！獎品拆分為多條，數據量太大時，不是很便捷，可能會帶來數據庫性能問題，但這個可以通過分庫分表，舊數據遷移備份的方式解決！在獎品快被抽完的那么幾微秒的用戶可能存在誤殺！這就是目前針對數據庫的單點熱點問題，我個人的一些見解，也只是初步構想，還沒有進入完全的實踐中，還希望各位大神多指點一二！

大型網站應用之海量數據和高并發解決方案總結

一、網站應用背景 開發一個網站的應用程序，當用戶規模比較小的時候，使用簡單的：一臺應用服務器+一臺數據庫服務器+一臺文件服務器，這樣的話完全可以解決一部分問題，也可以通過堆硬件的方式來提高網站應用的訪問性能，當然，也要考慮成本的問題。當問題的規模在經濟條件下通過堆硬件的方式解決不了的時候，我們應該通過其他的思路去解決問題，互聯網發展至今，已經提供了很多成熟的解決方案，但并不是都具有適用性，你把淘寶的技術全部都搬過來也不一定達到現在淘寶的水平，道理很簡單。當然，很多文章都在強調，一個網站的發展水平，是逐漸的演變過來的，并不是一朝一夕的事情。雖然目前的情況互聯網的泡沫越來越大，但是整個互聯網技術的發展確實為我們提供了方便快捷的上網體驗。下邊是一張早期的淘寶官網的界面：目前，博主正在跟隨導師做一個創業項目，使用的技術是SSM+MySQL+Linux這些，但是由于資金的限制和考慮到用戶群體的特殊性，系統的架構無奈的選擇的就是最簡單的方式：一臺應用服務器、一臺數據庫服務器、一臺文件系統服務器，沒有用到高級的技術，也沒有用到分布式部署的方案。下邊整理的是一些針對海量數據和高并發情況下的解決方案，技術水平有限，歡迎留言指導。二、針對海量數據和高并發的主要解決方案 海量數據的解決方案：使用緩存； 頁面靜態化技術； 數據庫優化； 分離數據庫中活躍的數據； 批量讀取和延遲修改； 讀寫分離； 使用NoSQL和Hadoop等技術； 分布式部署數據庫； 應用服務和數據服務分離； 使用搜索引擎搜索數據庫中的數據； 進行業務的拆分； 高并發情況下的解決方案：應用程序和靜態資源文件進行分離； 頁面緩存； 集群與分布式； 反向代理； CDN； 三、海量數據的解決方案 （1）使用緩存網站訪問數據的特點大多數呈現為“二八定律”：80%的業務訪問集中在20%的數據上。例如：在某一段時間內百度的搜索熱詞可能集中在少部分的熱門詞匯上；新浪微博某一時期也可能大家廣泛關注的主題也是少部分事件。總的來說就是用戶只用到了總數據條目的一小部分，當網站發展到一定規模，數據庫IO操作成為性能瓶頸的時候，使用緩存將這一小部分的熱門數據緩存在內存中是一個很不錯的選擇，不但可以減輕數據庫的壓力，還可以提高整體網站的數據訪問速度。使用緩存的方式可以通過程序代碼將數據直接保存到內存中，例如通過使用Map或者ConcurrentHashMap；另一種，就是使用緩存框架：Redis、Ehcache、Memcache等。 使用緩存框架的時候，我們需要關心的就是什么時候創建緩存和緩存失效策略。緩存的創建可以通過很多的方式進行創建，具體也需要根據自己的業務進行選擇。例如，新聞首頁的新聞應該在第一次讀取數據的時候就進行緩存；對于點擊率比較高的文章，可以將其文章內容進行緩存等。內存資源有限，選擇如何創建緩存是一個值得思考的問題。另外，對于緩存的失效機制也是需要好好研究的，可以通過設置失效時間的方式進行設置；也可以通過對熱門數據設置優先級，根據不同的優先級設置不同的失效時間等；需要注意的是，當我們刪除一條數據的時候，我們要考慮到刪除該條緩存，還要考慮在刪除該條緩存之前該條數據是否已經到達緩存失效時間等各種情況！使用緩存的時候還要考慮到緩存服務器發生故障時候如何進行容錯處理，是使用N多臺服務器緩存相同的數據，通過分布式部署的方式對緩存數據進行控制，當一臺發生故障的時候自動切換到其他的機器上去；還是通過Hash一致性的方式，等待緩存服務器恢復正常使用的時候重新指定到該緩存服務器。Hash一致性的另一個作用就是在分布式緩存服務器下對數據進行定位，將數據分布在不用緩存服務器上。關于數據緩存的Hash一致性也是一個比較打的問題，這里只能大致描述一下，關于Hash一致性的了解，推薦一篇文章：http://blog.csdn.net/liu765023051/article/details/49408099（2）頁面靜態化技術使用傳統的JSP界面，前端界面的顯示是通過后臺服務器進行渲染后返回給前端游覽器進行解析執行，如下圖： 當然，現在提倡前后端分離，前端界面基本都是HTML網頁代碼，通過Angular JS或者NodeJS提供的路由向后端服務器發出請求獲取數據，然后在游覽器對數據進行渲染，這樣在很大程度上降低了后端服務器的壓力。還可以將這些靜態的HTML、CSS、JS、圖片資源等放置在緩存服務器上或者CDN服務器上，一般使用最多的應該是CDN服務器或者Nginx服務器提供的靜態資源功能。另外，在《高性能網站建設進階指南-Web開發者性能優化最佳實踐（口碑網前端團隊 翻譯）》這本書中，對網站性能的前端界面提供了一些很寶貴的經驗，如下：因此，在這些靜態資源的處理上，選擇正確的處理方式還是對整體網站性能還是有很大幫助的！（3）數據庫優化數據庫優化是整個網站性能優化的最基礎的一個環節，因為，大多數網站性能的瓶頸都是開在數據庫IO操作上，雖然提供了緩存技術，但是對數據庫的優化還是一個需要認真的對待。一般公司都有自己的DBA團隊，負責數據庫的創建，數據模型的確立等問題，不像我們現在幾個不懂數據庫優化的人只能在網上找一篇篇數據庫優化的文章，自己去摸索，并沒有形成一個系統的數據庫優化思路。對于數據庫的優化來說，是一種用技術換金錢的方式。數據庫優化的方式很多，常見的可以分為：數據庫表結構優化、SQL語句優化、分區、分表、索引優化、使用存儲過程代替直接操作等 。1、表結構優化對于數據庫的 開發規范與使用技巧以及設計和優化，前邊的時候總結了一些文章，這里偷個懶直接放地址，有需要的可以移步看一下： a) MySQL開發規范與使用技巧總結：http://blog.csdn.net/xlgen157387/article/details/48086607 b) 在一個千萬級的數據庫查尋中，如何提高查詢效率？：http://blog.csdn.net/xlgen157387/article/details/44156679另外，再設計數據庫表的時候需不需要創建外鍵，使用外鍵的好處之一可以方便的進行級聯刪除操作，但是現在在進行數據業務操作的時候，我們都通過事物的方式來保證數據讀取操作的一致性，我感覺相比于使用外鍵關聯MySQL自動幫我們完成級聯刪除的操作來說，還是自己使用事物進行刪除操作來的更放心一些。當然可能也是有適用的場景，大家如有很好的建議，歡迎留言！2、SQL優化對于SQL的優化，主要是針對SQL語句處理邏輯的優化，而且還要根據索引進行配合使用。另外，對于SQL語句的優化我們可以針對具體的業務方法進行優化，我們可以將執行業務邏輯操作的數據庫執行時間記錄下來，來進行有針對性的優化，這樣的話效果還是很不錯的！例如下圖，展示了一條數據庫操作執行調用的時間：關于SQL優化的一些建議，以前整理了一些，還請移步查看：a) 19個MySQL性能優化要點解析：http://blog.csdn.net/xlgen157387/article/details/50735269b) MySQL批量SQL插入各種性能優化：http://blog.csdn.net/xlgen157387/article/details/50949930分表分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。數據庫讀寫操作的時候根據事先定義好的規則得到對應的子表名，然后去操作它。例如：用戶表 用戶的角色有很多種，可以通過枚舉類型的方式將用戶分為不同類別category：學生、教師、企業等 ，這樣的話，我們就可以根據類別category來對數據庫進行分表，這樣的話每次查詢的時候現根據用戶的類型鎖定一個較小的范圍。不過分表之后，如果需要查詢完整的順序就需要使用多表操作了。分區數據庫分區是一種物理數據庫設計技術，DBA和數據庫建模人員對其相當熟悉。雖然分區技術可以實現很多效果，但其主要目的是為了在特定的SQL操作中減少數據讀寫的總量以縮減響應時間。分區和分表相似，都是按照規則分解表。不同在于分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區后，表面上還是一張表，但數據散列到多個位置了。數據庫讀寫操作的時候操作的還是大表名字，DMS自動去組織分區的數據。當一張表中的數據變得很大的時候，讀取數據，查詢數據的效率非常低下，很容易的就是講數據分到不同的數據表中進行保存，但是這樣分表之后會使得操作起來比較麻煩，因為，將同類的數據分別放在不同的表中的話，在搜索數據的時候需要便利查詢這些表中的數據。想進行CRUD操作還需要先找到對應的所有表，如果涉及到不同的表的話還要進行跨表操作，這樣操作起來還是很麻煩的。使用分區的方式可以解決這個問題，分區是將一張表中的數據按照一定的規則分到不同的區中進行保存，這樣進行數據查詢的時候如果數據的范圍在同一個區域內那么就可以支隊一個區中的數據進行操作，這樣的話操作起來數據量更少，操作速度更快，而且該方法是對程序透明的，程序不需要進行任何的修改。索引優化索引的大致原理是在數據發生變化的時候就預先按指定字段的順序排列后保存到一個類似表的結構中，這樣在查找索引字段為條件記錄時就可以很快地從索引中找到對應記錄的指針并從表中獲取到相應的數據，這樣速度是很快地。不過，雖然查詢的效率大大提高了，但是在進行增刪改的時候，因為數據的變化都需要更新相應的索引，也是一種資源的浪費。關于使用索引的問題，對待不同的問題，還是需要進行不同的討論，根據具體的業務需求選擇合適的索引對性能的提高效果是很明顯的一個舉措！推薦文章閱讀：a) 數據庫索引的作用和優點缺點以及索引的11中用法：http://blog.csdn.net/xlgen157387/article/details/45030829b) 數據庫索引原理：http://blog.csdn.net/kennyrose/article/details/7532032使用存儲過程代替直接操作存儲過程（Stored Procedure）是在大型數據庫系統中，一組為了完成特定功能的SQL 語句集，存儲在數據庫中，經過第一次編譯后再次調用不需要再次編譯，用戶通過指定存儲過程的名字并給出參數（如果該存儲過程帶有參數）來執行它。存儲過程是數據庫中的一個重要對象，任何一個設計良好的數據庫應用程序都應該用到存儲過程。在操作過程比較復雜并且調用頻率比較高的業務中，可以將編寫好的sql語句用存儲過程的方式來代替，使用存儲過程只需要進行一次變異，而且可以在一個存儲過程里做一些復雜的操作。（4）分離數據庫中活躍的數據正如前邊提到的“二八定律”一樣，網站的數據雖然很多，但是經常被訪問的數據還是有限的，因此可以講這些相對活躍的數據進行分離出來單獨進行保存來提高處理效率。其實前邊使用緩存的思想就是一個很明顯的分離數據庫中活躍的數據的使用案例，將熱門數據緩存在內存中。還有一種場景就是，例如一個網站的所用注冊用戶量很大千萬級別，但是經常登錄的用戶只有百萬級別，剩下的基本都是很長時間都沒有進行登錄操作，如果不把這些“僵尸用戶”單獨分離出去，那么我們每次查詢其他登錄用戶的時候，就白白浪費了這些僵尸用戶的查詢操作。（5）批量讀取和延遲修改批量讀取和延遲修改的原理是通過減少操作數據庫的操作來提高效率。批量讀取是將多次查詢合并到一次中進行讀取，因為每一個數據庫的請求操作都需要鏈接的建立和鏈接的釋放，還是占用一部分資源的，批量讀取可以通過異步的方式進行讀取。延遲修改是對于一些高并發的并且修改頻繁修改的數據，在每次修改的時候首先將數據保存到緩存中，然后定時將緩存中的數據保存到數據庫中，程序可以在讀取數據時可以同時讀取數據庫中和緩存中的數據。例如：我現在在編寫這份博客，我一開始寫了一寫內容然后點擊發布了，在次回到Markdown進行修改操作，我有一個習慣，沒寫一些東西總是按一下上邊的 “保存”按鈕，然后我在另一個頁面打開這篇博客查看，我的修改已經被更新，但是我還在 編輯！不知道CSDN的技術是不是在我沒有點擊發布之前，這些數據都是先放到緩存里邊的。（6） 讀寫分離讀寫分離的實質是將應用程序對數據庫的讀寫操作分配到多個數據庫服務器上，從而降低單臺數據庫的訪問壓力。讀寫分離一般通過配置主從數據庫的方式，數據的讀取來自從庫，對數據庫增加修改刪除操作主庫。相關文章請移步觀看： a) MySQL5.6 數據庫主從（Master/Slave）同步安裝與配置詳解：http://blog.csdn.net/xlgen157387/article/details/51331244 b) MySQL主從復制的常見拓撲、原理分析以及如何提高主從復制的效率總結:http://blog.csdn.net/xlgen157387/article/details/52451613（7）使用NoSQL和Hadoop等技術NoSQL是一種非結構化的非關系型數據庫，由于其靈活性，突破了關系型數據庫的條條框框，可以靈活的進行操作，另外，因為NoSQL通過多個塊存儲數據的特點，其操作大數據的速度也是相當快的。（8）分布式部署數據庫任何強大的單一服務器都滿足不了大型網站持續增長的業務需求。數據庫通過讀寫分離之后將一臺數據庫服務器拆分為兩臺或者多臺數據庫服務器，但是仍然滿足不了持續增長的業務需求。分布式部署數據庫是將網站數據庫拆分的最后手段，只有在單表數據規模非常龐大的時候才使用。分布式部署數據庫是一種很理想的情況，分布式數據庫是將表存放在不同的數據庫中然后再放到不同的數據庫中，這樣在處理請求的時候，如果需要調用多個表，則可以讓多臺服務器同時處理，從而提高處理效率。分布式數據庫簡單的架構圖如下：（9）應用服務和數據服務分離應用服務器和數據庫服務器進行分離的目的是為了根據應用服務器的特點和數據庫服務器的特點進行底層的優化，這樣的話能夠更好的發揮每一臺服務器的特性，數據庫服務器當然是有一定的磁盤空間，而應用服務器相對不需要太大的磁盤空間，這樣的話進行分離是有好處的，也能防止一臺服務器出現問題連帶的其他服務也不可以使用。（10）使用搜索引擎搜索數據庫中的數據使用搜索引擎這種非數據庫查詢技術對網站應用的可伸縮分布式特性具有更好的支持。常見的搜索引擎如Solr通過一種反向索引的方式，維護關鍵字到文檔的映射關系，類似于我們使用《新華字典》進行搜索一個關鍵字，首先應該是看字典的目錄進行查找然后定位到具體的位置。搜索引擎通過維護一定的關鍵字到文檔的映射關系，能夠快速的定位到需要查找的數據，相比于傳統的數據庫搜索的方式，效率還是很高的。目前一種比較火的ELK stack技術，還是值得學習的。一篇關于Solr與MySQL查詢性能對比文章： Solr與MySQL查詢性能對比：http://www.cnblogs.com/luxiaoxun/p/4696477.html?utm_source=tuicool&utm_medium=referral（11） 進行業務的拆分為什么進行業務的拆分，歸根結底上還是使用的還是講不通的業務數據表部署到不用的服務器上，分別查找對應的數據以滿足網站的需求。各個應用之間用過指定的URL連接獲取不同的服務，例如一個大型的購物網站就會將首頁、商鋪、訂單、買家、賣家等拆分為不通的子業務，一方面將業務模塊分歸為不同的團隊進行開發，另外一方面不同的業務使用的數據庫表部署到不通的服務器上，體現到拆分的思想，當一個業務模塊使用的數據庫服務器發生故障也不會影響其他業務模塊的數據庫正常使用。另外，當其中一個模塊的訪問量激增的時候還可以動態的擴展這個模塊使用到的數據庫的數量從而滿足業務的需求。高并發情況下的解決方案 （1）應用程序和靜態資源文件進行分離所謂的靜態資源就是我們網站中用到的Html、Css、Js、Image、Video、Gif等靜態資源。應用程序和靜態資源文件進行分離也是常見的前后端分離的解決方案，應用服務只提供相應的數據服務，靜態資源部署在指定的服務器上（Nginx服務器或者是CDN服務器上），前端界面通過Angular JS或者Node JS提供的路由技術訪問應用服務器的具體服務獲取相應的數據在前端游覽器上進行渲染。這樣可以在很大程度上減輕后端服務器的壓力。例如，百度主頁使用的圖片就是單獨的一個域名服務器上進行部署的（2）頁面緩存頁面緩存是將應用生成的很少發生數據變化的頁面緩存起來，這樣就不需要每次都重新生成頁面了，從而節省大量CPU資源，如果將緩存的頁面放到內存中速度就更快。可以使用Nginx提供的緩存功能，或者可以使用專門的頁面緩存服務器Squid。（3）集群與分布式（4）反向代理參考文章請移步至： http://blog.csdn.net/xlgen157387/article/details/49781487（5）CDNCDN服務器其實是一種集群頁面緩存服務器，其目的就是盡早的返回用戶所需要的數據，一方面加速用戶訪問速度，另一方面也減輕后端服務器的負載壓力。CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。CDN通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。也就是說CDN服務器是部署在網絡運行商的機房，提供的離用戶最近的一層數據訪問服務，用戶在請求網站服務的時候，可以從距離用戶最近的網絡提供商機房獲取數據。電信的用戶會分配電信的節點，聯通的會分配聯通的節點。CDN分配請求的方式是特殊的，不是普通的負載均衡服務器來分配的那種，而是用專門的CDN域名解析服務器在解析與名的時候就分配好的。CDN結構圖如下所示：總結 文章提到的幾點并沒有詳細的介紹，如需要對其中的一種方式進行研究，可以自行去找資源學習研究，這里只起到拋磚引玉的作用。當然對于大型網站應用之海量數據和高并發解決方案不局限于這些技巧或技術，還有很多成熟的解決方案，有需要的可以自行了解。特此說明：本文的配圖來自《網站架構及其演變過程–韓路彪》，多謝原作者提供的精美配圖，并且文章的結構大致也參考了作者的思路，只不過內容是自己的一些經驗和學習到的東西進行整理的。參考書籍或文章：1、《網站架構及其演變過程–韓路彪》 2、《大型網站技術架構之核心原理與參考案例–李智慧》 3、部分專業名詞簡介來自百度百科 4、http://cio.chinabyte.com/428/13106928.shtml 5、http://blog.codinglabs.org/articles/consistent-hashing.html ---------------------

?

總結

以上是生活随笔為你收集整理的数据拆分缺点和解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。