為什么要使用NoSQL？NOSQL的優勢

這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當地分析一些成功案例，希望有成功使用NoSQL經驗的朋友給我提供一些線索和信息。

成都創新互聯堅持“要么做到，要么別承諾”的工作理念，服務領域包括：做網站、網站設計、企業官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的花垣網站設計、移動媒體設計的需求，幫助企業找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！

NoSQL概念隨著web2.0的快速發展，非關系型、分布式數據存儲得到了快速的發展，它們不保證關系數據的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關系數據庫的名字。）

NoSQL被我們用得最多的當數key-value存儲，當然還有其他的文檔型的、列存儲、圖型數據庫、xml數據庫等。在NoSQL概念提出之前，這些數據庫就被用于各種系統當中，但是卻很少用于web互聯網應用。比如cdb、qdbm、bdb數據庫。

傳統關系數據庫的瓶頸

傳統的關系數據庫具有不錯的性能，高穩定型，久經歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯網領域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯網的發展做出了卓越的貢獻。

在90年代，一個網站的訪問量一般都不大，用單個數據庫完全可以輕松應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。

到了最近10年，網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，如果你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然后又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時，如果你去面試，你說你有Memcached經驗，肯定會加分的。

Mysql主從讀寫分離

由于數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。

分表分庫隨著web2.0的繼續高速發展，在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由于MyISAM使用表鎖，在高并發下會出現嚴重的鎖問題，大量的高并發MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯網幾乎沒有成功案例，性能也不能滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。

MySQL的擴展性瓶頸

在互聯網，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設計得有性能問題，需要優化了。大數據量高并發環境下的MySQL應用開發越來越復雜，也越來越具有技術挑戰性。分表分庫的規則把握都是需要經驗的。雖然有像淘寶這樣技術實力強大的公司開發了透明的中間件層來屏蔽開發者的復雜性，但是避免不了整個架構的復雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。

MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。

關系數據庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

NOSQL的優勢易擴展NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

高可用NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現高可用。

總結NoSQL數據庫的出現，彌補了關系數據（比如MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。

MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結合將會給web2.0的數據庫發展帶來新的思路。

高性能 NoSQL

關系數據庫經過幾十年的發展，已經非常成熟，但同時也存在不足：

表結構是強約束的，業務變更時擴充很麻煩。

如果對大數據量的表進行統計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數據讀入內存。

全文搜索只能使用 Like 進行整表掃描，性能非常低。

針對這些不足，產生了不同的 NoSQL 解決方案，在某些場景下比關系數據庫更有優勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 SQL 的有利補充。

NoSQL != No SQL，而是：

NoSQL = Not Only SQL

典型的 NoSQL 方案分為4類：

Redis 是典型，其 value 是具體的數據結構，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數據結構服務器。

以 list 為例：

LPOP key 是移除并返回隊列左邊的第一個元素。

如果用關系數據庫就比較麻煩了，需要操作：

Redis 的缺點主要體現在不支持完成的ACID事務，只能保證隔離性和一致性，無法保證原子性和持久性。

最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。

特點：

以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數據庫中會有很大的麻煩，而使用文檔數據庫則非常方便。

文檔數據庫的主要缺點：

關系數據庫是按行來存儲的，列式數據庫是按照列來存儲數據。

按行存儲的優勢：

在某些場景下，這些優勢就成為劣勢了，例如，計算超重人員的數據，只需要讀取體重這一列進行統計即可，但行式存儲會將整行數據讀取到內存中，很浪費。

而列式存儲中，只需要讀取體重這列的數據即可，I/O 將大大減少。

除了節省I/O，列式存儲還有更高的壓縮比，可以節省存儲空間。普通行式數據庫的壓縮比在 3:1 到 5:1 左右，列式數據庫在 8:1 到 30:1，因為單個列的數據相似度更高。

列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續空間中，而列式存儲將不同列存儲在不連續的空間。

一般將列式存儲應用在離線大數據分析統計場景，因為這時主要針對部分列進行操作，而且數據寫入后無須更新。

關系數據庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：

假設有一個交友網站，信息表如下：

需要匹配性別、地點、語言列。

需要匹配性別、地點、愛好列。

實際搜索中，各種排列組合非常多，關系數據庫很難支持。

全文搜索引擎是使用 倒排索引 技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：

所以特別適合根據關鍵詞來查詢文檔內容。

上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據實際需求進行選擇。

NoSQL 數據庫：何時使用 NoSQL 與 SQL？

NoSQL 數據庫因其功能性、易于開發性和可擴展性而廣受認可，它們越來越多地用于大數據和實時 Web 應用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。

NoSQL是一種下一代數據庫管理系統 (DBMS)。NoSQL 數據庫具有靈活的模式，可用于構建具有大量數據和高負載的現代應用程序。

“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創造的，盡管自 1960 年代后期以來就已經存在類似的數據庫。然而，NoSQL 的發展始于 2009 年初，并且發展迅速。

在處理大量數據時，任何關系數據庫管理系統 (RDBMS) 的響應時間都會變慢。為了解決這個問題，我們可以通過升級現有硬件來“擴大”信息系統，這非常昂貴。但是，NoSQL 可以更好地橫向擴展并且更具成本效益。

NoSQL 對于非結構化或非常大的數據對象（例如聊天日志數據、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯網巨頭中特別受歡迎的原因。

一些流行的 NoSQL 數據庫包括：

隨著企業更快地積累更大的數據集，結構化數據和關系模式并不總是適合。有必要使用非結構化數據和大型對象來更好地捕獲這些信息。

傳統的 RDBMS 使用 SQL（結構化查詢語言）語法來存儲和檢索結構化數據，相反，NoSQL 數據庫包含廣泛的功能，可以存儲和檢索結構化、半結構化、非結構化和多態數據。

有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強調它可能支持類似 SQL 的語言或與 SQL 數據庫并列。SQL 和 NoSQL DBMS 之間的一個區別是 JOIN 功能。SQL 數據庫使用 JOIN 子句來組合來自兩個或多個表的行，因為 NoSQL 數據庫本質上不是表格的，所以這個功能并不總是可行或相關的。

但是，一些 NoSQL DBMS 可以執行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數據庫傾向于以不同的方式解決類似的問題。

一般來說，在以下情況下，NoSQL 比 SQL 更可取：

許多行業都在采用 NoSQL，取代關系數據庫，從而為某些業務應用程序提供更高的靈活性和可擴展性，下面給出了 NoSQL 數據庫的一些企業用例。

內容管理是一組用于收集、管理、傳遞、檢索和發布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數據庫可以通過其靈活和開放的數據模型為存儲多媒體內容提供更好的選擇。

例如，福布斯在短短幾個月內就構建了一個基于 MongoDB 的定制內容管理系統，以更低的成本為他們提供了更大的敏捷性。

大數據是指太大而無法通過傳統處理系統處理的數據集，實時存儲和檢索大數據的系統在分析 歷史 數據的同時使用流處理來攝取新數據，這是一系列非常適合 NoSQL 數據庫的功能。

Zoom使用 DynamoDB（按需模式）使其數據能夠在沒有性能問題的情況下進行擴展，即使該服務在 COVID-19 大流行的早期使用量激增。

物聯網設備具有連接到互聯網或通信網絡的嵌入式軟件和傳感器，能夠在無需人工干預的情況下收集和共享數據。隨著數十億臺設備生成數不清的數據，IoT NoSQL 數據庫為 IoT 服務提供商提供了可擴展性和更靈活的架構。

Freshub就是這樣的一項服務，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態、非統一的數據集。

擁有數十億智能手機用戶，可擴展性正成為在移動設備上提供服務的企業面臨的最大挑戰。具有更靈活數據模型的 NoSQL DBMS 通常是完美的解決方案。

例如，The Weather Channel使用 MongoDB 數據庫每分鐘處理數百萬個請求，同時還處理用戶數據并提供天氣更新。

MySQL性能調優 – 你必須了解的15個重要變量

前言:

MYSQL 應該是最流行了 WEB 后端數據庫。雖然 NOSQL 最近越來越多的被提到，但是相信大部分架構師還是會選擇 MYSQL 來做數據存儲。本文作者總結梳理MySQL性能調優的15個重要變量，又不足需要補充的還望大佬指出。

1.DEFAULT_STORAGE_ENGINE

如果你已經在用MySQL 5.6或者5.7，并且你的數據表都是InnoDB，那么表示你已經設置好了。如果沒有，確保把你的表轉換為InnoDB并且設置default_storage_engine為InnoDB。

為什么？簡而言之，因為InnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲引擎 – 它支持事務，高并發，有著非常好的性能表現(當配置正確時)。這里有詳細的版本介紹為什么

2.INNODB_BUFFER_POOL_SIZE

這個是InnoDB最重要變量。實際上，如果你的主要存儲引擎是InnoDB，那么對于你，這個變量對于MySQL是最重要的。

基本上，innodb_buffer_pool_size指定了MySQL應該分配給InnoDB緩沖池多少內存，InnoDB緩沖池用來存儲緩存的數據，二級索引，臟數據(已經被更改但沒有刷新到硬盤的數據)以及各種內部結構如自適應哈希索引。

根據經驗，在一個獨立的MySQL服務器應該分配給MySQL整個機器總內存的80%。如果你的MySQL運行在一個共享服務器，或者你想知道InnoDB緩沖池大小是否正確設置，詳細請看這里。

3.INNODB_LOG_FILE_SIZE

InnoDB重做日志文件的設置在MySQL社區也叫做事務日志。直到MySQL 5.6.8事務日志默認值innodb_log_file_size=5M是唯一最大的InnoDB性能殺手。從MySQL 5.6.8開始，默認值提升到48M,但對于許多稍繁忙的系統，還遠遠要低。

根據經驗，你應該設置的日志大小能在你服務器繁忙時能存儲1-2小時的寫入量。如果不想這么麻煩，那么設置1-2G的大小會讓你的性能有一個不錯的表現。這個變量也相當重要，更詳細的介紹請看這里。

當然，如果你有大量的大事務更改，那么，更改比默認innodb日志緩沖大小更大的值會對你的性能有一定的提高，但是你使用的是autocommit，或者你的事務更改小于幾k，那還是保持默認的值吧。

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

默認下，innodb_flush_log_at_trx_commit設置為1表示InnoDB在每次事務提交后立即刷新同步數據到硬盤。如果你使用autocommit，那么你的每一個INSERT, UPDATE或DELETE語句都是一個事務提交。

同步是一個昂貴的操作(特別是當你沒有寫回緩存時)，因為它涉及對硬盤的實際同步物理寫入。所以如果可能，并不建議使用默認值。

兩個可選的值是0和2:

* 0表示刷新到硬盤，但不同步(提交事務時沒有實際的IO操作)

* 2表示不刷新和不同步(也沒有實際的IO操作)

所以你如果設置它為0或2，則同步操作每秒執行一次。所以明顯的缺點是你可能會丟失上一秒的提交數據。具體來說，你的事務已經提交了，但服務器馬上斷電了，那么你的提交相當于沒有發生過。

顯示的，對于金融機構，如銀行，這是無法忍受的。不過對于大多數網站，可以設置為innodb_flush_log_at_trx_commit=0|2，即使服務器最終崩潰也沒有什么大問題。畢竟，僅僅在幾年前有許多網站還是用MyISAM，當崩潰時會丟失30s的數據(更不要提那令人抓狂的慢修復進程)。

那么，0和2之間的實際區別是什么？性能明顯的差異是可以忽略不計，因為刷新到操作系統緩存的操作是非常快的。所以很明顯應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數據，因為數據已經在OS緩存，最終還是會同步到硬盤的。

5.SYNC_BINLOG

已經有大量的文檔寫到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關系，下面我們來簡單的介紹下：

a) 如果你的服務器沒有設置從服務器，而且你不做備份，那么設置sync_binlog=0將對性能有好處。

b) 如果你有從服務器并且做備份，但你不介意當主服務器崩潰時在二進制日志丟失一些事件，那么為了更好的性能還是設置為sync_binlog=0.

c) 如果你有從服務器并且備份，你非常在意從服務器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進制日志將數據庫恢復到特定時間點的能力)，那么你應該設置innodb_flush_log_at_trx_commit=1，并且需要認真考慮使用sync_binlog=1。

問題是sync_binlog=1代價比較高 – 現在每個事務也要同步一次到硬盤。你可能會想為什么不把兩次同步合并成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經能合并提交，那么在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會對性能有很大影響。

6.INNODB_FLUSH_METHOD

將innodb_flush_method設置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應該使用O_DIRECT是當你操作系統不支持時。但如果你運行的是Linux，使用O_DIRECT來激活直接IO。

不用直接IO，雙重緩沖將會發生，因為所有的數據庫更改首先會寫入到OS緩存然后才同步到硬盤 – 所以InnoDB緩沖池和OS緩存會同時持有一份相同的數據。特別是如果你的緩沖池限制為總內存的50%，那意味著在寫密集的環境中你可能會浪費高達50%的內存。如果沒有限制為50%，服務器可能由于OS緩存的高壓力會使用到swap。

簡單地說，設置為innodb_flush_method=O_DIRECT。

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩沖實例作為減小內部鎖爭用來提高MySQL吞吐量的手段。

在5.5版本這個對提升吞吐量幫助很小，然后在MySQL 5.6版本這個提升就非常大了，所以在MySQL5.5中你可能會保守地設置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設置為8-16個緩沖池實例。

你設置后觀察會覺得性能提高不大，但在大多數高負載情況下，它應該會有不錯的表現。

對了，不要指望這個設置能減少你單個查詢的響應時間。這個是在高并發負載的服務器上才看得出區別。比如多個線程同時做許多事情。

8.INNODB_THREAD_CONCURRENCY

InnoDB有一種方法來控制并行執行的線程數 – 我們稱為并發控制機制。大部分是由innodb_thread_concurrency值來控制的。如果設置為0，并發控制就關閉了，因此InnoDB會立即處理所有進來的請求(盡可能多的)。

在你有32CPU核心且只有4個請求時會沒什么問題。不過想像下你只有4CPU核心和32個請求時 – 如果你讓32個請求同時處理，你這個自找麻煩。因為這些32個請求只有4 CPU核心，顯然地會比平常慢至少8倍(實際上是大于8倍)，而然這些請求每個都有自己的外部和內部鎖，這有很大可能堆積請求。

下面介紹如何更改這個變量，在mysql命令行提示符執行：

對于大多數工作負載和服務器，設置為8是一個好開端，然后你可以根據服務器達到了這個限制而資源使用率利用不足時逐漸增加?？梢酝ㄟ^show engine innodb status\G來查看目前查詢處理情況，查找類似如下行：

9.SKIP_NAME_RESOLVE

這一項不得不提及，因為仍然有很多人沒有添加這一項。你應該添加skip_name_resolve來避免連接時DNS解析。

大多數情況下你更改這個會沒有什么感覺，因為大多數情況下DNS服務器解析會非?？?。不過當DNS服務器失敗時，它會出現在你服務器上出現“unauthenticated connections” ，而就是為什么所有的請求都突然開始慢下來了。

所以不要等到這種事情發生才更改?，F在添加這個變量并且避免基于主機名的授權。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來當刷新臟數據時，控制MySQL每秒執行的寫IO量。

* innodb_io_capacity_max: 在壓力下，控制當刷新臟數據時MySQL每秒執行的寫IO量

首先，這與讀取無關 – SELECT查詢執行的操作。對于讀操作，MySQL會盡最大可能處理并返回結果。至于寫操作，MySQL在后臺會循環刷新，在每一個循環會檢查有多少數據需要刷新，并且不會用超過innodb_io_capacity指定的數來做刷新操作。這也包括更改緩沖區合并（在它們刷新到磁盤之前，更改緩沖區是輔助臟頁存儲的關鍵）。

第二，我需要解釋一下什么叫“在壓力下”，MySQL中稱為”緊急情況”，是當MySQL在后臺刷新時，它需要刷新一些數據為了讓新的寫操作進來。然后，MySQL會用到innodb_io_capacity_max。

那么，應該設置innodb_io_capacity和innodb_io_capacity_max為什么呢？

最好的方法是測量你的存儲設置的隨機寫吞吐量，然后給innodb_io_capacity_max設置為你的設備能達到的最大IOPS。innodb_io_capacity就設置為它的50-75%，特別是你的系統主要是寫操作時。

通常你可以預測你的系統的IOPS是多少。例如由8 15k硬盤組成的RAID10能做大約每秒1000隨機寫操作，所以你可以設置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價企業SSD可以做4,000-10,000 IOPS等。

這個值設置得不完美問題不大。但是，要注意默認的200和400會限制你的寫吞吐量，因此你可能偶爾會捕捉到刷新進程。如果出現這種情況，可能是已經達到你硬盤的寫IO吞吐量，或者這個值設置得太小限制了吞吐量。

11.INNODB_STATS_ON_METADATA

如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認值，因為它已經設置正確了。

不過在MySQL 5.5或5.1，強烈建議關閉這個變量 – 如果是開啟，像命令show table status會立即查詢INFORMATION_SCHEMA而不是等幾秒再執行，這會使用到額外的IO操作。

從5.1.32版本開始，這個是動態變量，意味著你不需要重啟MySQL服務器來關閉它。

12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN INNODB_BUFFER_POOL_LOAD_AT_STARTUP

innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup這兩個變量與性能無關，不過如果你偶爾重啟mysql服務器(如生效配置)，那么就有關。當兩個都激活時，MySQL緩沖池的內容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在后臺啟動一個線程來加載緩沖池的內容以提高預熱速度到3-5倍。

兩件事：

第一，它實際上沒有在關閉時復制緩沖池內容到文件，僅僅是復制表空間ID和頁面ID – 足夠的信息來定位硬盤上的頁面了。然后它就能以大量的順序讀非?？焖俚募虞d那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在后臺加載內容，因為MySQL不需要等到緩沖池內容加載完成再開始接受請求(所以看起來不會有什么影響)。

從MySQL 5.7.7開始，默認只有25%的緩沖池頁面在mysql關閉時存儲到文件，但是你可以控制這個值 – 使用innodb_buffer_pool_dump_pct，建議75-100。

這個特性從MySQL 5.6才開始支持。

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運行著一個大量SELECT查詢的MySQL服務器(并且已經盡可能優化)，那么自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內部維護的動態索引，可以提高最常用的查詢模式的性能。這個特性可以重啟服務器關閉，不過默認下在mysql的所有版本開啟。

這個技術非常復雜，在大多數情況下它會對大多數類型的查詢直到加速的作用。不過，當你有太多的查詢往數據庫，在某一個點上它會花過多的時間等待AHI鎖和閂鎖。

如果你的是MySQL 5.7，沒有這個問題 – innodb_adaptive_hash_index_parts默認設置為8，所以自適應哈希索引被切割為8個分區，因為不存在全局互斥。

不過在mysql 5.7前的版本，沒有AHI分區數量的控制。換句話說，有一個全局互斥鎖來保護AHI，可能導致你的select查詢經常撞墻。

所以如果你運行的是5.1或5.6，并且有大量的select查詢，最簡單的方案就是切換成同一版本的Percona Server來激活AHI分區。

14.QUERY_CACHE_TYPE

如果人認為查詢緩存效果很好，肯定應該使用它。好吧，有時候是有用的。不過這個只在你在低負載時有用，特別是在低負載下大多數是讀取，小量寫或者沒有。

如果是那樣的情況，設置query_cache_type=ON和query_cache_size=256M就好了。不過記住不能把256M設置更高的值了，否則會由于查詢緩存失效時，導致引起嚴重的服務器停頓。

如果你的MySQL服務器高負載動作，建議設置query_cache_size=0和query_cache_type=OFF，并重啟服務器生效。那樣Mysql就會停止在所有的查詢使用查詢緩存互斥鎖。

15.TABLE_OPEN_CACHE_INSTANCES

從MySQL 5.6.6開始，表緩存能分割到多個分區。

表緩存用來存放目前已打開表的列表，當每一個表打開或關閉互斥體就被鎖定 – 即使這是一個隱式臨時表。使用多個分區絕對減少了潛在的爭用。

從MySQL 5.7.8開始，table_open_cache_instances=16是默認的配置。

歡迎做Java的工程師朋友們私信我資料免費獲取免費的Java架構學習資料（里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

其中覆蓋了互聯網的方方面面，期間碰到各種產品各種場景下的各種問題，很值得大家借鑒和學習，擴展自己的技術廣度和知識面。

MySQL數據庫性能優化之分區分表分庫

分表是分散數據庫壓力的好方法。

分表，最直白的意思，就是將一個表結構分為多個表，然后，可以再同一個庫里，也可以放到不同的庫。

當然，首先要知道什么情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。

分表的分類

**1、縱向分表**

將本來可以在同一個表的內容，人為劃分為多個表。（所謂的本來，是指按照關系型數據庫的第三范式要求，是應該在同一個表的。）

分表理由：根據數據的活躍度進行分離，（因為不同活躍的數據，處理方式是不同的）

案例：

對于一個博客系統，文章標題，作者，分類，創建時間等，是變化頻率慢，查詢次數多，而且最好有很好的實時性的數據，我們把它叫做冷數據。而博客的瀏覽量，回復數等，類似的統計信息，或者別的變化頻率比較高的數據，我們把它叫做活躍數據。所以，在進行數據庫結構設計的時候，就應該考慮分表，首先是縱向分表的處理。

這樣縱向分表后：

首先存儲引擎的使用不同，冷數據使用MyIsam 可以有更好的查詢數據。活躍數據，可以使用Innodb ,可以有更好的更新速度。

其次，對冷數據進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數據，可以相對有更多的主庫的橫向分表處理。

其實，對于一些特殊的活躍數據，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新數據庫。或者mongodb 一類的nosql 數據庫，這里只是舉例，就先不說這個。

**2、橫向分表**

字面意思，就可以看出來，是把大的表結構，橫向切割為同樣結構的不同表，如，用戶信息表，user_1,user_2等。表結構是完全一樣，但是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。

分表理由：根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。

案例：同上面的例子，博客系統。當博客的量達到很大時候，就應該采取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數據表，假如分為100個表，當同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現在分表后，就可能是每個表進行1萬個數據的請求（因為，不可能絕對的平均，只是假設），這樣壓力就降低了很多很多。

延伸：為什么要分表和分區？

日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過于龐大，導致數據庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。分表和表分區的目的就是減少數據庫的負擔，提高數據庫的效率，通常點來講就是提高表的增刪改查效率。

什么是分表？

分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然后去操作它。

什么是分區？

分區和分表相似，都是按照規則分解表。不同在于分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區后，表面上還是一張表，但數據散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區的數據。

**MySQL分表和分區有什么聯系呢？**

1、都能提高mysql的性高，在高并發狀態下都有一個良好的表現。

2、分表和分區不矛盾，可以相互配合的，對于那些大訪問量，并且表數據比較多的表，我們可以采取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以采取分區的方式等。

3、分表技術是比較麻煩的，需要手動去創建子表，app服務端讀寫時候需要計算子表名。采用merge好一些，但也要創建子表和配置子表間的union關系。

4、表分區相對于分表，操作方便，不需要創建子表。

我們知道對于大型的互聯網應用，數據庫單表的數據量可能達到千萬甚至上億級別，同時面臨這高并發的壓力。Master-Slave結構只能對數據庫的讀能力進行擴展，寫操作還是集中在Master中，Master并不能無限制的掛接Slave庫，如果需要對數據庫的吞吐能力進行進一步的擴展，可以考慮采用分庫分表的策略。

**1、分表**

在分表之前，首先要選中合適的分表策略（以哪個字典為分表字段，需要將數據分為多少張表），使數據能夠均衡的分布在多張表中，并且不影響正常的查詢。在企業級應用中，往往使用org_id(組織主鍵)做為分表字段，在互聯網應用中往往是userid。在確定分表策略后，當數據進行存儲及查詢時，需要確定到哪張表里去查找數據，

數據存放的數據表 = 分表字段的內容 % 分表數量

**2、分庫**

分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是不能給數據庫的并發訪問帶來質的提升，面對高并發的寫訪問，當Master無法承擔高并發的寫入請求時，不管如何擴展Slave服務器，都沒有意義了。我們通過對數據庫進行拆分，來提高數據庫的寫入能力，即所謂的分庫。分庫采用對關鍵字取模的方式，對數據庫進行路由。

數據存放的數據庫=分庫字段的內容%數據庫的數量

**3、即分表又分庫**

數據庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單臺數據庫的并發訪問壓力問題。

當數據庫同時面臨海量數據存儲和高并發訪問的時候，需要同時采取分表和分庫策略。一般分表分庫策略如下：

中間變量 = 關鍵字%（數據庫數量*單庫數據表數量）

庫 = 取整（中間變量/單庫數據表數量）

表 = （中間變量%單庫數據表數量）

實例：

1、分庫分表

很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優化途徑，現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然后根據mid分發記錄到這些表中，牛逼的代碼大概是這樣子：

復制代碼 代碼如下:

?php

for($i=0;$i 100; $i++ ){

//echo "CREATE TABLE db2.members{$i} LIKE db1.members

";

echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}

";

}

?

2、不停機修改mysql表結構

同樣還是members表，前期設計的表結構不盡合理，隨著數據庫不斷運行，其冗余數據也是增長巨大，同事使用了下面的方法來處理：

先創建一個臨時表：

/*創建臨時表*/

CREATE TABLE members_tmp LIKE members

然后修改members_tmp的表結構為新結構，接著使用上面那個for循環來導出數據，因為1000萬的數據一次性導出是不對的，mid是主鍵，一個區間一個區間的導，基本是一次導出5萬條吧，這里略去了

接著重命名將新表替換上去：

/*這是個頗為經典的語句哈*/

RENAME TABLE members TO members_bak,members_tmp TO members;

就是這樣，基本可以做到無損失，無需停機更新表結構，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經過這個操作，使得原先8G多的表，一下子變成了2G多。

目前哪些NoSQL數據庫應用廣泛，各有什么特點

特點：

它們可以處理超大量的數據。

它們運行在便宜的PC服務器集群上。

PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。

它們擊碎了性能瓶頸。

NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數據轉換成SQL友好格式的時間，執行速度變得更快。

“SQL并非適用于所有的程序代碼，” 對于那些繁重的重復操作的數據，SQL值得花錢。但是當數據庫結構非常簡單時，SQL可能沒有太大用處。

沒有過多的操作。

雖然NoSQL的支持者也承認關系數據庫提供了無可比擬的功能集合，而且在數據完整性上也發揮絕對穩定，他們同時也表示，企業的具體需求可能沒有那么多。

Bootstrap支持

因為NoSQL項目都是開源的，因此它們缺乏供應商提供的正式支持。這一點它們與大多數開源項目一樣，不得不從社區中尋求支持。

優點：

易擴展

NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的 Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

高可用

NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現高可用。

主要應用：

Apache HBase

這個大數據管理平臺建立在谷歌強大的BigTable管理引擎基礎上。作為具有開源、Java編碼、分布式多個優勢的數據庫，Hbase最初被設計應用于Hadoop平臺，而這一強大的數據管理工具，也被Facebook采用，用于管理消息平臺的龐大數據。

Apache Storm

用于處理高速、大型數據流的分布式實時計算系統。Storm為Apache Hadoop添加了可靠的實時數據處理功能，同時還增加了低延遲的儀表板、安全警報，改進了原有的操作方式，幫助企業更有效率地捕獲商業機會、發展新業務。

Apache Spark

該技術采用內存計算，從多迭代批量處理出發，允許將數據載入內存做反復查詢，此外還融合數據倉庫、流處理和圖計算等多種計算范式，Spark用Scala語言實現，構建在HDFS上，能與Hadoop很好的結合，而且運行速度比MapReduce快100倍。

Apache Hadoop

該技術迅速成為了大數據管理標準之一。當它被用來管理大型數據集時，對于復雜的分布式應用，Hadoop體現出了非常好的性能，平臺的靈活性使它可以運行在商用硬件系統，它還可以輕松地集成結構化、半結構化和甚至非結構化數據集。

Apache Drill

你有多大的數據集？其實無論你有多大的數據集，Drill都能輕松應對。通過支持HBase、Cassandra和MongoDB，Drill建立了交互式分析平臺，允許大規模數據吞吐，而且能很快得出結果。

Apache Sqoop

也許你的數據現在還被鎖定于舊系統中，Sqoop可以幫你解決這個問題。這一平臺采用并發連接，可以將數據從關系數據庫系統方便地轉移到Hadoop中，可以自定義數據類型以及元數據傳播的映射。事實上，你還可以將數據（如新的數據）導入到HDFS、Hive和Hbase中。

Apache Giraph

這是功能強大的圖形處理平臺，具有很好可擴展性和可用性。該技術已經被Facebook采用，Giraph可以運行在Hadoop環境中，可以將它直接部署到現有的Hadoop系統中。通過這種方式，你可以得到強大的分布式作圖能力，同時還能利用上現有的大數據處理引擎。

Cloudera Impala

Impala模型也可以部署在你現有的Hadoop群集上，監視所有的查詢。該技術和MapReduce一樣，具有強大的批處理能力，而且Impala對于實時的SQL查詢也有很好的效果，通過高效的SQL查詢，你可以很快的了解到大數據平臺上的數據。

Gephi

它可以用來對信息進行關聯和量化處理，通過為數據創建功能強大的可視化效果，你可以從數據中得到不一樣的洞察力。Gephi已經支持多個圖表類型，而且可以在具有上百萬個節點的大型網絡上運行。Gephi具有活躍的用戶社區，Gephi還提供了大量的插件，可以和現有系統完美的集成到一起，它還可以對復雜的IT連接、分布式系統中各個節點、數據流等信息進行可視化分析。

MongoDB

這個堅實的平臺一直被很多組織推崇，它在大數據管理上有極好的性能。MongoDB最初是由DoubleClick公司的員工創建，現在該技術已經被廣泛的應用于大數據管理。MongoDB是一個應用開源技術開發的NoSQL數據庫，可以用于在JSON這樣的平臺上存儲和處理數據。目前，紐約時報、Craigslist以及眾多企業都采用了MongoDB，幫助他們管理大型數據集。（Couchbase服務器也作為一個參考）。

十大頂尖公司：

Amazon Web Services

Forrester將AWS稱為“云霸主”，談到云計算領域的大數據，那就不得不提到亞馬遜。該公司的Hadoop產品被稱為EMR（Elastic Map Reduce），AWS解釋這款產品采用了Hadoop技術來提供大數據管理服務，但它不是純開源Hadoop，經過修改后現在被專門用在AWS云上。

Forrester稱EMR有很好的市場前景。很多公司基于EMR為客戶提供服務，有一些公司將EMR應用于數據查詢、建模、集成和管理。而且AWS還在創新，Forrester稱未來EMR可以基于工作量的需要自動縮放調整大小。亞馬遜計劃為其產品和服務提供更強大的EMR支持，包括它的RedShift數據倉庫、新公布的Kenesis實時處理引擎以及計劃中的NoSQL數據庫和商業智能工具。不過AWS還沒有自己的Hadoop發行版。

Cloudera

Cloudera有開源Hadoop的發行版，這個發行版采用了Apache Hadoop開源項目的很多技術，不過基于這些技術的發行版也有很大的進步。Cloudera為它的Hadoop發行版開發了很多功能，包括Cloudera管理器，用于管理和監控，以及名為Impala的SQL引擎等。Cloudera的Hadoop發行版基于開源Hadoop，但也不是純開源的產品。當Cloudera的客戶需要Hadoop不具備的某些功能時，Cloudera的工程師們就會實現這些功能，或者找一個擁有這項技術的合作伙伴。Forrester表示：“Cloudera的創新方法忠于核心Hadoop，但因為其可實現快速創新并積極滿足客戶需求，這一點使它不同于其他那些供應商?！蹦壳?，Cloudera的平臺已經擁有200多個付費客戶，一些客戶在Cloudera的技術支持下已經可以跨1000多個節點實現對PB級數據的有效管理。

Hortonworks

和Cloudera一樣，Hortonworks是一個純粹的Hadoop技術公司。與Cloudera不同的是，Hortonworks堅信開源Hadoop比任何其他供應商的Hadoop發行版都要強大。Hortonworks的目標是建立Hadoop生態圈和Hadoop用戶社區，推進開源項目的發展。Hortonworks平臺和開源Hadoop聯系緊密，公司管理人員表示這會給用戶帶來好處，因為它可以防止被供應商套牢（如果Hortonworks的客戶想要離開這個平臺，他們可以輕松轉向其他開源平臺）。這并不是說Hortonworks完全依賴開源Hadoop技術，而是因為該公司將其所有開發的成果回報給了開源社區，比如Ambari，這個工具就是由Hortonworks開發而成，用來填充集群管理項目漏洞。Hortonworks的方案已經得到了Teradata、Microsoft、Red Hat和SAP這些供應商的支持。

IBM

當企業考慮一些大的IT項目時，很多人首先會想到IBM。IBM是Hadoop項目的主要參與者之一，Forrester稱IBM已有100多個Hadoop部署，它的很多客戶都有PB級的數據。IBM在網格計算、全球數據中心和企業大數據項目實施等眾多領域有著豐富的經驗。“IBM計劃繼續整合SPSS分析、高性能計算、BI工具、數據管理和建模、應對高性能計算的工作負載管理等眾多技術。”

Intel

和AWS類似，英特爾不斷改進和優化Hadoop使其運行在自己的硬件上，具體來說，就是讓Hadoop運行在其至強芯片上，幫助用戶打破Hadoop系統的一些限制，使軟件和硬件結合的更好，英特爾的Hadoop發行版在上述方面做得比較好。Forrester指出英特爾在最近才推出這個產品，所以公司在未來還有很多改進的可能，英特爾和微軟都被認為是Hadoop市場上的潛力股。

MapR Technologies

MapR的Hadoop發行版目前為止也許是最好的了，不過很多人可能都沒有聽說過。Forrester對Hadoop用戶的調查顯示，MapR的評級最高，其發行版在架構和數據處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發行版中。例如網絡文件系統（NFS）、災難恢復以及高可用性功能。Forrester說MapR在Hadoop市場上沒有Cloudera和Hortonworks那樣的知名度，MapR要成為一個真正的大企業，還需要加強伙伴關系和市場營銷。

Microsoft

微軟在開源軟件問題上一直很低調，但在大數據形勢下，它不得不考慮讓Windows也兼容Hadoop，它還積極投入到開源項目中，以更廣泛地推動Hadoop生態圈的發展。我們可以在微軟的公共云Windows Azure HDInsight產品中看到其成果。微軟的Hadoop服務基于Hortonworks的發行版，而且是為Azure量身定制的。

微軟也有一些其他的項目，包括名為Polybase的項目，讓Hadoop查詢實現了SQLServer查詢的一些功能。Forrester說：“微軟在數據庫、數據倉庫、云、OLAP、BI、電子表格（包括PowerPivot）、協作和開發工具市場上有很大優勢，而且微軟擁有龐大的用戶群，但要在Hadoop這個領域成為行業領導者還有很遠的路要走?！?/p>

Pivotal Software

EMC和Vmware部分大數據業務分拆組合產生了Pivotal。Pivotal一直努力構建一個性能優越的Hadoop發行版，為此，Pivotal在開源Hadoop的基礎上又添加了一些新的工具，包括一個名為HAWQ的SQL引擎以及一個專門解決大數據問題的Hadoop應用。Forrester稱Pivotal Hadoop平臺的優勢在于它整合了Pivotal、EMC、Vmware的眾多技術，Pivotal的真正優勢實際上等于EMC和Vmware兩大公司為其撐腰。到目前為止，Pivotal的用戶還不到100個，而且大多是中小型客戶。

Teradata

對于Teradata來說，Hadoop既是一種威脅也是一種機遇。數據管理，特別是關于SQL和關系數據庫這一領域是Teradata的專長。所以像Hadoop這樣的NoSQL平臺崛起可能會威脅到Teradata。相反，Teradata接受了Hadoop，通過與Hortonworks合作，Teradata在Hadoop平臺集成了SQL技術，這使Teradata的客戶可以在Hadoop平臺上方便地使用存儲在Teradata數據倉庫中的數據。

AMPLab

通過將數據轉變為信息，我們才可以理解世界，而這也正是AMPLab所做的。AMPLab致力于機器學習、數據挖掘、數據庫、信息檢索、自然語言處理和語音識別等多個領域，努力改進對信息包括不透明數據集內信息的甄別技術。除了Spark，開源分布式SQL查詢引擎Shark也源于AMPLab，Shark具有極高的查詢效率，具有良好的兼容性和可擴展性。近幾年的發展使計算機科學進入到全新的時代，而AMPLab為我們設想一個運用大數據、云計算、通信等各種資源和技術靈活解決難題的方案，以應對越來越復雜的各種難題。

網站標題：nosql的性能優化方案,請簡要總結一下nosql數據庫的技術特點
網站地址：http://www.yijiale78.com/article26/hdegjg.html

成都網站建設公司_創新互聯，為您提供、移動網站建設、軟件開發、域名注冊、網站制作、建站公司

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯