NoSQL，指的是非關係型的數據庫。NoSQL 有時也稱作 Not Only SQL（意即"不僅僅是SQL"） 的縮寫，其顯著特點是不使用SQL作爲查詢語言，數據儲存不需要特定的表格模式。
NoSQL和SQL的主要區別有如下區別：
儲存方式：
儲存結構
儲存規範
儲存擴充套件
查詢方式
事務
SQL：MariaDB、MySQL、SQLite、SQLServer、Oracle、PostgreSQL。
NoSQL代表：Redis、MongoDB、Memcache、HBASE。
MongoDB是一個開源的、基於分佈式的、面向文件儲存的非關係型數據庫。是非關係型數據庫當中功能最豐富、最像關係數據庫的。其主要特點如下：
查詢豐富：MongoDB最大的特點是支援的查詢語言非常強大，其語法有點類似於物件導向的查詢語言，幾乎可以實現類似關係數據庫單表查詢的絕大部分功能，而且還支援對數據建立索引。面向文件：文件就是儲存在MongoDB中的一條記錄,是一個由鍵值對組成的數據結構。模式自由：MongoDB每一個Document都包含了元數據資訊，每個文件之間不強迫要求使用相同的格式，同時他們也支援各種索引。高可用性：MongoDB支援在複製集(Replica Set)通過非同步複製達到故障轉移，自動恢復，叢集中主伺服器崩潰停止服務和丟失數據，備份伺服器通過選舉獲得大多數投票成爲主節點，以此來實現高可用。水平拓展：MongoDB支援分片技術，它能夠支援並行處理和水平擴充套件。支援豐富：MongoDB另外還提供了豐富的BSON數據型別，還有MongoDB的官方不同語言的driver支援(C/C++、C#、Java、Node.js、Perl、PHP、Python、Ruby、Scala)。MongoDB屬於典型的非關係型數據庫。
主要適應場景
不適應場景
庫：MongoDB可以建立多個數據庫，MongoDB預設數據庫爲"db"。MongoDB的單個範例可以容納多個獨立的數據庫，每一個都有自己的集合和許可權，不同的數據庫也放置在不同的檔案中。集合：MongoDB集合就是 MongoDB 文件組，類似於 RDBMS （關係數據庫中的表格）。集合存在於數據庫中，集合沒有固定的結構。文件：MongoDB的Document是一組鍵值(key-value)對(即 BSON)，相當於關係型數據庫的行。且不需要設定相同的欄位，並且相同的欄位不需要相同的數據型別。MongoDB支援豐富的數據型別，常見的有：
索引通常能夠極大的提高查詢的效率，如果沒有索引，MongoDB在讀取數據時必須掃描集閤中的每個檔案並選取那些符合查詢條件的記錄。
這種掃描全集合的查詢效率是非常低的，特別在處理大量的數據時，查詢可能要花費幾十秒甚至幾分鐘，這對網站的效能是非常致命的。
索引是特殊的數據結構，索引儲存在一個易於遍歷讀取的數據集閤中，索引是對數據庫表中一列或多列的值進行排序的一種結構。
MongoDB常見的索引有：
mongodb的複製至少需要兩個節點。其中一個是主節點，負責處理用戶端請求，其餘的都是從節點，負責複製主節點上的數據。
mongodb各個節點常見的搭配方式爲：一主一從、一主多從。
主節點記錄在其上的所有操作oplog，從節點定期輪詢主節點獲取這些操作，然後對自己的數據副本執行這些操作，從而保證從節點的數據與主節點一致。
Primary節點寫入數據，Secondary通過讀取Primary的oplog（即Primary的oplog.rs表）得到複製資訊，開始複製數據並且將複製資訊寫入到自己的oplog。如果某個操作失敗，則備份節點停止從當前數據源複製數據。如果某個備份節點由於某些原因掛掉了，當重新啓動後，就會自動從oplog的最後一個操作開始同步。同步完成後，將資訊寫入自己的oplog，由於複製操作是先複製數據，複製完成後再寫入oplog，有可能相同的操作會同步兩份，MongoDB設定將oplog的同一個操作執行多次，與執行一次的效果是一樣的。
當Primary節點完成數據操作後，Secondary的數據同步過程如下：
MongoDB副本集是一組Mongod維護相同數據集的範例，副本集可以包含多個數據承載點和多個仲裁點。在承載數據的節點中，僅有一個節點被視爲主節點，其他節點稱爲次節點。
主要特點：
MongoDB中Secondary角色存在一些特殊的成員型別：
MongoDB分片叢集（Sharded Cluster）：主要利用分片技術，使數據分散儲存到多個分片（Shard）上，來實現高可延伸性。
分片是將數據水平切分到不同的物理節點。當數據量越來越大時，單臺機器有可能無法儲存數據或讀取寫入吞吐量有所降低，利用分片技術可以新增更多的機器來應對數據量增加以及讀寫操作的要求。
MongoDB分片叢集主要可以解決副本集如下的不足：
MongoDB分片叢集主要有如下優勢：
MongoDB架構元件主要有：
副本集不是爲了提高讀效能存在的，在進行oplog的時候，讀操作是被阻塞的；
提高讀取效能應該使用分片和索引，它的存在更多是作爲數據冗餘，備份。
MongoDB的數據劃分是基於集合級別爲標準，通過shard key來劃分集合數據。主要分片策略有如下三種：
差異：
新加入的數據及伺服器都會導致叢集數據分佈不平衡，MongoDB採用兩種方式確保數據分佈的平衡：
拆分
拆分是一個後臺進程，防止塊變得太大。當一個塊增長到指定塊大小的時候，拆分進程就會塊一分爲二，整個拆分過程是高效的。不會涉及到數據的遷移等操作。
平衡
平衡器是一個後臺進程，管理塊的遷移。平衡器能夠執行在叢集任何的mongd範例上。當叢集中數據分佈不均勻時，平衡器就會將某個分片中比較多的塊遷移到擁有塊較少的分片中，直到數據分片平衡爲止。
分片採用後臺操作的方式管理着源分片和目標分片之間塊的遷移。在遷移的過程中，源分片中的塊會將所有文件發送到目標分片中，然後目標分片會獲取並應用這些變化。最後，更新設定伺服器上關於塊位置元數據。
mongodb備份恢復方式通常有以下三種：
檔案快照方式：此方式相對簡單，需要系統檔案支援快照和mongod必須啓用journal。可以在任何時刻建立快照。恢復時，確保沒有執行mongod，執行快照恢復操作命令，然後啓動mongod進程，mongod將重放journal日誌。複製數據檔案方式：直接拷貝數據目錄下的一切檔案，但是在拷貝過程中必須阻止數據檔案發生更改。因此需要對數據庫加鎖，以防止數據寫入。恢復時，確保mongod沒有執行，清空數據目錄，將備份的數據拷貝到數據目錄下，然後啓動mongod。使用mongodump和mongorestore方式：在Mongodb中我們使用mongodump命令來備份MongoDB數據。該命令可以導出所有數據到指定目錄中。恢復時，使用mongorestore命令來恢復MongoDB數據。該命令可以從指定目錄恢復相應數據。聚合操作能夠處理數據記錄並返回計算結果。聚合操作能將多個文件中的值組合起來，對成組數據執行各種操作，返回單一的結果。它相當於 SQL 中的 count(*) 組合 group by。對於 MongoDB 中的聚合操作，應該使用aggregate()方法。
GridFS是一種將大型檔案儲存在MongoDB中的檔案規範。使用GridFS可以將大檔案分隔成多個小文件存放，這樣我們能夠有效的儲存大文件，而且解決了BSON物件有限制的問題。
MongoDB查詢優化大致可能從如下步驟着手：
第一步：找出慢速查詢
如下方式開啓內建的查詢分析器,記錄讀寫操作效率：
db.setProfilingLevel(n,{m}),n的取值可選0,1,2；
查詢監控結果：監控結果儲存在一個特殊的集合system.profile裡。
第二步：分析慢速查詢
找出慢速查詢的原因，通常可能的原因有：應用程式設計不合理、不正確的數據模型、硬體設定問題、缺少索引等
第三部：根據不同的分析結果進行優化，如建立索引。
不會，磁碟寫操作預設是延時執行的，寫操作可能在兩三秒（預設在60秒內）後到達磁碟，可通過syncPeriodSecs參數進行設定。
是數據庫管理系統中一個排序的數據結構，根據不同的儲存引擎索引分爲Hash索引、B+樹索引等。常見的InnoDB儲存引擎的預設索引實現爲：B+樹索引。
索引可以協助快速查詢、更新數據庫表中數據。
事務是一系列的操作，需要要符合ACID特性，即：事務中的操作要麼全部成功，要麼全部失敗。
MySQL事務支援如下四種隔離：
未提交讀(Read Uncommitted)：允許髒讀，其他事務只要修改了數據，即使未提交，本事務也能看到修改後的數據值。也就是可能讀取到其他對談中未提交事務修改的數據。提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫預設都是該級別 (不重複讀)。可重複讀(Repeated Read)：可重複讀。無論其他事務是否修改並提交了數據，在這個事務中看到的數據值始終不受其他事務影響。序列讀(Serializable)：完全序列化的讀，每次讀都需要獲得表級共用鎖，讀寫相互都會阻塞。鎖機制 機製是爲了避免，在數據庫有併發事務的時候，可能會產生數據的不一致而誕生的的一個機制 機製。鎖從類別上分爲：
共用鎖：又叫做讀鎖，當使用者要進行數據的讀取時，對數據加上共用鎖，共用鎖可以同時加上多個。排他鎖：又叫做寫鎖，當使用者要進行數據的寫入時，對數據加上排他鎖，排他鎖只可以加一個，他和其他的排他鎖,共用鎖都相斥。主鍵是數據庫確保數據行在整張表唯一性的保障，即使數據庫中表沒有主鍵，也建議新增一個自增長的ID列作爲主鍵，設定了主鍵之後，在後續的刪改查的時候可能更加快速以及確保操作數據範圍安全。
MySQL支援多種儲存引擎，常見的有InnoDB、MyISAM、Memory、Archive等。通常使用InnoDB引擎都是最合適的，InnoDB也是MySQL的預設儲存引擎。
MySQL+Amoeba讀寫分離方案：Amoeba(變形蟲)專案，這個工具致力於MySQL的分佈式數據庫前端代理層，它主要在應用層存取MySQL的時候充當SQL路由功能。具有負載均衡、高可用性、SQL 過濾、讀寫分離、可路由相關的到目標數據庫、可併發請求多臺數據庫合併結果。通過Amoeba你能夠完成多數據源的高可用、負載均衡、數據切片、讀寫分離的功能。
MySQL+MMM讀寫分離方案：MMM即Multi-Master Replication Manager for MySQL，mysql多主複製管理器是關於mysql主主複製設定的監控、故障轉移和管理的一套可伸縮的指令碼套件(在任何時候只有一個節點可以被寫入)。MMM也能對從伺服器進行讀負載均衡，通過MMM方案能實現伺服器的故障轉移，從而實現mysql的高可用。MMM不僅能提供浮動IP的功能，如果當前的主伺服器掛掉後，會將你後端的從伺服器自動轉向新的主伺服器進行同步複製，不用手工更改同步設定。
MySQL主從複製：Mysql內建的複製功能是構建大型，高效能應用程式的基礎。將Mysql的數據分佈在多個節點（slaves）之上，複製過程中一個伺服器充當主伺服器，而一個或多個其它伺服器充當從伺服器。主伺服器將更新寫入二進制日誌檔案，並維護檔案的一個索引以跟蹤日誌回圈。這些日誌可以記錄發送到從伺服器的更新。MySQL雙主：參考MySQL主從複製。MySQL雙主多從：參考MySQL主從複製。MySQL複製+Keepalived高可用：MySQL自身的複製，對外基於Keepalived技術，暴露一個VIP，從而實現高可用。Heartbeat + MySQL 實現MySQL的高可用：通過Heartbeat的心跳檢測和資源接管、叢集中服務的監測、失效切換等功能，結合MySQL來實現高可用性。MySQL可通過如下方式優化：
MySQL自帶
mysqldump：mysqldump支援基於innodb的熱備份，使用mysqldump完全備份+二進制日誌可以實現基於時間點的恢復，通常適合備份數據比較小的場景 。
系統層面
tar備份：可以使用tar之類的系統命令對整個數據庫目錄進行打包備份。
lvm快照備份：可基於檔案系統的LVM製作快照，進行對整個數據庫目錄所在的邏輯卷備份。
第三方備份工具
可使用其他第三方工具進行備份，如xtrabackup工具，該工具支援innodb的物理熱備份，支援完全備份、增量備份，而且速度非常快，支援innodb儲存引起的數據在不同數據庫之間遷移，支援複製模式下的從機備份恢復備份恢復。
常見的監控軟體有：
Cacti：是一套基於PHP、MySQL、SNMP及RRDTool開發的網路流量監測圖形分析工具。Zabbix：Zabbix是一個企業級的高度整合開源監控軟體，提供分佈式監控解決方案。可以用來監控裝置、服務等可用性和效能。Open-falcon：open-falcon是一款用golang和python寫的監控系統，由小米啓動這個專案。Prometheus：Prometheus是由SoundCloud開發的開源監控報警系統和時序列數據庫(TSDB)。Prometheus使用Go語言開發，是Google BorgMon監控系統的開源版本。Prometheus是一個已加入CNCF的開源監控報警系統和時序列數據庫專案，通過不同的元件完成數據的採集，數據的儲存和告警。
Prometheus主要特性：
多維數據模型
靈活的查詢語句（PromQL），可以利用多維數據完成複雜的查詢
Prometheus server 是一個單獨的二進制檔案，不依賴（任何分佈式）儲存，支援 local 和 remote 不同模型
採用 http 協定，使用 pull 模式，拉取數據，或者通過中間閘道器推播方式採集數據
監控目標，可以採用服務發現或靜態設定的方式
支援多種統計數據模型，圖形化友好
高效：一個 Prometheus server 可以處理數百萬的 metrics
適用於以機器爲中心的監控以及高度動態面向服務架構的監控
Prometheus 的主要模組包含：prometheus server, exporters, push gateway, PromQL, Alertmanager, WebUI 等。
prometheus server：定期從靜態設定的 targets 或者服務發現（主要是DNS、consul、k8s、mesos等）的 targets 拉取數據，用於收集和儲存時間序列數據。exporters：負責向prometheus server做數據彙報，暴露一個http服務的介面給Prometheus server定時抓取。而不同的數據彙報由不同的exporters實現，比如監控主機有node-exporters，mysql有MySQL server exporter。push gateway：主要使用場景爲，當Prometheus 採用 pull 模式，可能由於不在一個子網或者防火牆原因，導致 Prometheus 無法直接拉取各個 target 數據。此時需要push gateway接入，以便於在監控業務數據的時候，將不同數據彙總, 由 Prometheus 統一收集。實現機制 機製類似於zabbix-proxy功能。Alertmanager：從 Prometheus server 端接收到 alerts 後，會進行去除重複數據，分組，並路由到對收的接受方式，發出報警，即主要實現prometheus的告警功能。AlertManager的整體工作流程如下圖所示:webui：Prometheus內建一個簡單的Web控制檯，可以查詢指標，檢視設定資訊或者Service Discovery等，實踐中通常結合Grafana，Prometheus僅作爲Grafana的數據源。Prometheus簡單機制 機製如下：
Prometheus 儲存的是時序數據,，時序數據是指按照相同時序(相同的名字和標籤)，以時間維度儲存連續的數據的集合。時序(time series) 是由名字(Metric)，以及一組 key/value 標籤定義的，具有相同的名字以及標籤屬於相同時序。
Prometheus 時序數據分爲 Counter, Gauge, Histogram, Summary 四種類型。
Counter：計數器表示收集的數據是按照某個趨勢（增加／減少）一直變化的，通常用它記錄服務請求總量，錯誤總數等。Gauge：計量器表示蒐集 搜集的數據是一個瞬時的，與時間沒有關係，可以任意變高變低，往往可以用來記錄記憶體使用率、磁碟使用率等。Histogram：直方圖 Histogram 主要用於對一段時間範圍內的數據進行採樣，（通常是請求持續時間或響應大小），並能夠對其指定區間以及總數進行統計，通常我們用它計算分位數的直方圖。Summary：彙總Summary 和 直方圖Histogram 類似，主要用於表示一段時間內數據採樣結果，（通常是請求持續時間或響應大小），它直接儲存了 quantile 數據，而不是根據統計區間計算出來的。Zabbix是一個企業級的高度整合開源監控軟體，提供分佈式監控解決方案。可以用來監控裝置、服務等可用性和效能。其主要優勢有：
Zabbix體系相對清晰，其主要元件有：
Zabbix Server：負責接收agent發送的報告資訊的核心元件，所有設定、統計數據及操作數據均由其組織進行。Database Storage：專用於儲存所有設定資訊，以及有zabbix收集的數據。Web interface（frontend）：zabbix的GUI介面，通常與server執行在同一臺機器上。Proxy：可選元件，常用於分佈式監控環境中，代理Server收集部分被監控數據並統一發往Server端。Agent：部署在被監控主機上，負責收集本地數據併發往Server端或者Proxy端。目前由zabbix提供包括但不限於以下事項型別的支援：
Zabbix agent checks：這些用戶端來進行數據採集，又分爲Zabbix agent（被動模式：用戶端等着伺服器端來要數據），Zabbix agent (active)（主動模式：用戶端主動發送數據到伺服器端）SNMP agent checks：SNMP方式，如果要監控印表機網路裝置等支援SNMP裝置的話，但是又不能安裝agent的裝置。SNMP traps ：IPMI checks：IPMI即智慧平臺管理介面，現在是業界通過的標準。使用者可以利用IPMI監視伺服器的物理特性，如溫度、電壓、電扇工作狀態、電源供應以及機箱入侵等。zabbix proxy 可以代替 zabbix server 收集效能和可用性數據,然後把數據彙報給 zabbix server，並且在一定程度上分擔了zabbix server 的壓力。
此外，當所有agents和proxy報告給一個Zabbix server並且所有數據都集中收集時，使用proxy是實現集中式和分佈式監控的最簡單方法。
zabbix proxy 使用場景:
CDN即內容分發網路，是在現有網路中增加一層新的網路架構，從而實現將源站內容發佈和傳送到最靠近使用者的邊緣地區，使使用者可以就近存取想要的內容，提高使用者存取的響應速度。