mongodb列存儲
Ⅰ mongodb 是列存資料庫嗎
Mongodb使用的是文件存儲系統。只是在文件系統的基礎之上增加了文件地址的索引以提高查詢速度。
Ⅱ mongodb資料庫排名第一嗎
答案：A
1.文檔型資料庫
作為最受歡迎的Nosql產品，文檔型資料庫MongoDB當仁不讓地佔據了第一的位置，同時它也是所有NoSQL資料庫中排名最靠前的產品(總排行榜第七名)。Apache基金會的CouchDB排在第二，基於.Net的資料庫RavenDB排在第三，Couchbase排在第四。
2.鍵值(Key-value)資料庫
鍵值(Key-value)資料庫是NoSQL領域中應用范圍最廣的，也是涉及產品最多的一種模型。從最簡單的BerkeleyDB到功能豐富的分布式資料庫Riak再到Amazon託管的DynamoDB不一而足。
在鍵值資料庫流行度排行中，Redis不出意外地排名第一，它是一款由Vmware支持的內存資料庫，總體排名第十一。排在第二位的是Memcached，它在緩存系統中應用十分廣泛。排在之後的是Riak、BerkeleyDB、SimpleDB、DynamoDB以及甲骨文的Oracle NoSQL資料庫。值得注意的是，Oracle NoSQL資料庫上榜不久，得分已經翻番，上升勢頭非常迅猛。
3.列式存儲
列式存儲被視為NoSQL資料庫中非常重要的一種模式，其中Cassandra流行度最高，它已經由Facebook轉交給到Apache進行管理，同時Cassandra在全體資料庫排名中排在第十位，緊隨MongoDB成為第二受歡迎的NoSQL資料庫。基於Hadoop的Hbase排在第二位，Hypertable排在第三。而Google的BigTable並未列入排名，原因是它並未正式公開。
Ⅲ 老去的MongoDB，未來在哪裡
大概六年前，在為ZDNet撰寫文章時，我們曾經認真思考過一個問題：MongoDB未來要走向何方？隨著時間推移，答案已經逐漸浮出水面：要讓資料庫更具可擴展性，支持開發者編寫好的各種應用程序。為此，MongoDB增加了原生搜索功能，以支持內容管理；物聯網用例也獲得了時序數據支持；另外還有變更流，可幫助電商應用快速預測出下一最佳行動。
順帶一說，MongoDB的客戶還需要一種能夠與開發工具良好匹配、易於上手的雲解決方案。 結果就是Atlas，這項託管雲服務目前佔MongoDB整體業務的60%。
但平心而論，與大多數其他操作型資料庫一樣，MongoDB直到最近才剛剛得到重視。畢竟大家可能很難想像要在一套操作型資料庫中，執行涵蓋多個表（或文檔集合）的復雜查詢。
— 1 —
為什麼要引入分析？
大多數操作型應用程序的共同之處是一旦添加了分析功能，其實用性將馬上飛升。例如，分析可以幫助 汽車 製造商增強預防性維護，醫療保健服務商能夠確定最佳護理方案，電子商務或 游戲 廠商則可以改善客戶交互、防止客戶流失。這些出於決策優化而設計出的分析功能，是對操作型資料庫的良好補充。
把分析跟交易型資料庫聯系起來絕不是什麼新鮮想法，HTAP、translytical或增強型交易資料庫都是分析廠商們拿出的相應成果。
雲原生提出的計算與存儲彼此分離的理念，則讓我們有了另一個在不影響性能或吞吐量的情況下、將操作數據處理與分析加以結合的好機會。 最近亮相的Oracle MySQL HeatWaev和谷歌AlloyDB，正是大廠在這個方向上的積極嘗試。
大多數此類混合資料庫都會使用專為分析而設計的柱狀表，對傳統行存儲進行補充。順帶一提，它們也都使用相同的常見關系數據結構，確保轉換更加簡便易行。與之對應，如果引入包含分層和嵌套數據結構的文檔模型，那麼轉譯過程往往會更加困難。
那麼，MongoDB是不是也該擁有自己的分析功能？這還是要看我們如何定義「分析」。如前所述，如果我們向交易中引入智能化操作分析，那麼應用程序的實用性將大大增強。所以只要把范圍設定在快速決策分析，而非復雜的分析建模，那麼答案就是肯定的。
— 2 —
無法一蹴而就的事業
MongoDB已經開始嘗試支持分析功能。它從可視化開始，著手提供自己的圖表功能與商務智能（BI）連接器，現在的MongoDB在Tableaus與Qliks端看來已經幾乎與MySQL無異。雖然一圖勝萬言，但對於分析來說，可視化還只是萬里長征第一步。MongoDB盡管能提供趨勢快照，但還無法進一步實現數據關聯（往往涉及更復雜的查詢），也無法完全回答「為什麼」會出現哪些狀況。
MongoDB決心已定，開始通過分析提升自身競爭力。但在這個分析復雜度愈發高企的時代，它顯然無法取代Snowflake、Redshift、Databricks或者其他專業分析方案。 但MongoDB分析面向的也並非數據分析師，而是應用程序開發者。 回到操作型資料庫的首要原則——盡量別把它，跟需要高度復雜的連接及/或高並發查詢扯在一起。只要能讓開發者構建起更好的應用程序，MongoDB就算是成功了。
Atlas能夠靈活預留專門的分析節點。MongoDB也將在不久後，全面允許客戶在更適合分析的節點上選擇不同的計算實例。這些節點將提供在線數據復制功能，藉此實現近實時分析。
但這還只是第一步：由於Atlas可運行在多種雲環境上，因此客戶還可以選擇更多其他實例。不過大家無需擔心，MongoDB未來將推出規范性指南，同時提供機器學習方案幫助大家自動選擇最適應工作負載的實例類型。
對分析的嘗試當然不可能止步於此，去年預覽發布的Atlas Serverless將於本周推出正式版。剛剛起步的分析自然也將成為受益者，因為分析類工作負載一般與交易事務不同、突發峰值往往更多。
— 3 —
有沒有可能對接SQL？
其實引入SQL的想法在MongoDB發展早期一直備受反對，當時有聲音認為MongoDB永遠不該成為關系資料庫。但是，理性終將戰勝情緒。
本周，MongoDB引入了新的Atlas SQL介面，可用於讀取Atlas數據。這是一種全新結構，採用不同於BI連接器的通道。Atlas SQL將是MongoDB為數據提供SQL介面的第一次真正嘗試，其思路絕不是簡單把JSON扁平化以使其在Tableau中看起來像MySQL，而是提供更加精細的視圖、反映JSON文檔架構的豐富性。
但SQL介面編寫工作不可能一蹴而就，所以預計Atlas SQL將在未來幾年內逐漸發展完善。 畢竟要想與各類SQL工具（不止是可視化）實現全面集成，MongoDB還得在豐富的數據倉庫選項上多下工夫。 我們還希望看到對upserts等操作的支持，分析平台沒有了這些核心功能，就相當於分析表中失去了行插入功能。
與Atlas SQL介面一同推出預覽版的全新列存儲索引，則意在提高分析查詢的性能水平。同樣的，這還僅僅只是開始。例如，MongoDB用戶目前仍需要手動設置列存儲索引、指定欄位。但從長遠來看，我們可以通過分析訪問模式來實現自動化。設想一下：後續我們可以豐富元數據以分析欄位基數，添加Bloom過濾器以進一步優化掃描功能，也可以繼續完善查詢計劃器。
接下來是Atlas Data Lake，負責為雲對象存儲中的JSON文檔提供聯合視圖。Atlas Data Lake在改造完成後，將針對多個Atlas集群和雲對象存儲提供更多的通用聯合查詢功能。新的存儲層會自動將Atlas集群數據集提取到雲對象存儲和內部技術目錄 （並非Alation）組合當中，藉此加快分析查詢。
— 4 —
以人為本
長期以來，MongoDB一直是開發者們最喜歡的資料庫之一。 這是因為開發者熱愛javaScript和JSON，目前JS在Tiobe人氣指數中排名第七。而JavaScript、JSON和文檔模型將是MongoDB的永恆主題。但很遺憾，由於MongoDB此前一直刻意迴避SQL，所以也就失去了相應的龐大人才庫——SQL開發者同樣體量龐大，讓這一查詢語言在人氣指數中位列第九。現在，是時候做出改變了。
雖然MongoDB仍然認為文檔模型優於、並有望取代關系模型（只是一家之言），但相信大家都認同一點：為了進一步擴大影響范圍，MongoDB必須接納那些以往被忽略的受眾群體。要想雙贏，兩大陣營應該團結一致、實現簡化；對於某些操作用例，我們不必將數據移動並轉移至獨立的數據倉庫目標，而是簡化為在統一平台內操作，最終將數據提取轉化為更簡單的數據復制。
— 5 —
意不在取代數據倉庫、數據湖或智能湖倉
MongoDB絕不是要取代獨立的數據倉庫、數據湖或智能湖倉。目前復雜建模與發現已經成為分析工作中的重要組成部分，所以必須與操作型系統分別執行。 更重要的是，在操作型資料庫中支持分析，最大的意義其實是實現流程內聯並盡可能實時化。
換言之，MongoDB將由此實現與Snowflakes或者Databricks的全面協同。大家可以在數據倉庫、數據湖或智能湖倉中開發用於識別異常值的模型，再將結果整理為一個相對簡單、易於處理的分類、預測或規范模型。這樣只要交易中出現異常，該模型就會被自動觸發。
如今，在MongoDB中實現這樣的閉環流程已經頗具可行性，但具體方法仍然非常復雜。大家需要將MongoDB中的變更流、觸發器和函數拼湊起來，共同組織成某種封閉式的分析反饋循環。 相信在不久的將來，MongoDB將把這些復雜性要素隱藏在後台，直接提供簡單易用的閉環與近實時分析選項。 這絕不是憑空想像，而是技術發展趨勢的必然結果。如今，MongoDB已經踏上了這段分析 探索 之旅，我們也期待著它能早傳捷報。
Ⅳ Mongodb和mysql的區別
Mongodb和mysql的區別
1.Mongodb簡介及優缺點分析
Mongodb是非關系型資料庫(nosql ),屬於文檔型資料庫。文檔是mongoDB中數據的基本單元，類似關系資料庫的行，多個鍵值對有序地放置在一起便是文檔，語法有點類似javascript面向對象的查詢語言，它是一個面向集合的，模式自由的文檔型資料庫。
存儲方式：虛擬內存+持久化。
查詢語句：是獨特的Mongodb的查詢方式。
適合場景：事件的記錄，內容管理或者博客平台等等。
架構特點：可以通過副本集，以及分片來實現高可用。
數據處理：數據是存儲在硬碟上的，只不過需要經常讀取的數據會被載入到內存中，將數據存儲在物理內存中，從而達到高速讀寫。
成熟度與廣泛度：新興資料庫，成熟度較低，Nosql資料庫中最為接近關系型資料庫，比較完善的DB之一，適用人群不斷在增長。
優點：
快速！在適量級的內存的Mongodb的性能是非常迅速的，它將熱數據存儲在物理內存中，使得熱數據的讀寫變得十分快。高擴展性，存儲的數據格式是json格式！
缺點：
① mongodb不支持事務操作。
② mongodb佔用空間過大。
③ 開發文檔不是很完全，完善。
2.MySQL優缺點分析
優點：
在不同的引擎上有不同 的存儲方式。
查詢語句是使用傳統的sql語句，擁有較為成熟的體系，成熟度很高。
開源資料庫的份額在不斷增加，mysql的份額頁在持續增長。
缺點：
在海量數據處理的時候效率會顯著變慢。
3.Mongodb和MySQL資料庫的對比
傳統的關系資料庫一般由資料庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB是由資料庫（database）、集合（collection）、文檔對象（document）三個層次組成。
MongoDB對於關系型資料庫里的表，但是集合中沒有列、行和關系概念，這體現了模式自由的特點。
4.MongoDB常用語句
# 連接Mongo資料庫，並設置數據存儲地址
mongod.exe --dbpath "d:softwareMongoDBServer3.0data"
#-----------------------#1# 資料庫
# 查看所有的資料庫
show dbs
# 刪除當前使用的資料庫
db.dropDatabase()
# 使用這個資料庫（只有插入數據後完成創建資料庫）
use dbt
# 查看當前使用的資料庫
db
db.getName()
# 查看當前資料庫狀態
db.stats()
# 修復當前資料庫
db.repairDatabase()
# 從一個資料庫復制到另一個資料庫
db.Database("mydb", "temp", "127.0.0.1");
#-----------------------#2# 集合
# 查看當前資料庫下所有的集合
show collections
show tables
# 創建名稱為coll集合
db.createCollection('coll')
db.createCollection("coll2", {capped:true, autoIndexId:true, size:6142800, max:10000}) # 可選參數
# 查看當前集合狀態
db.coll.stats()
# 刪除名稱為coll集合
db.coll.drop()
#-----------------------#3# 集合數據
# 插入空數據並且直接創建名稱為coll集合
db.coll.insert({})
# 插入一個或多個數據
db.coll.insert({name:'tom', age:22})
db.coll.insert([{name:'adam', age:10},{name:'john', age:23}])
# 添加數據（save方法可以修改相同id的數據）
db.coll.save({name:'allen'})
# 刪除一個或所有的數據
db.coll.remove({name:'tom'})
db.coll.remove({})
# 刪除符合條件的數據中的第一條
db.coll.remove({name:'tom'}, 1)
# 更改數據
db.coll.update({name:'tom', age:22}, {$set:{name:'tom', age:222}})
# 查看數據
db.coll.find()
# 查看一條數據
db.coll.findOne()
db.coll.find({}, {name:1, '_id':0}) # 1表示顯示，0表示不顯示（find默認顯示_id）
# 格式化顯示數據，使數據更加清晰明了
db.coll.find().pretty()
# 使用and，or查看數據
db.coll.find({name:'tom', age:22}) # 等同and使用
db.coll.find({$or:[{name:'tom'}, {age:21}]}) # or使用
# 操作符大於，小於，等於，不等於，大於不等於，小於不等於
db.coll.find({age: {$gt: 22}}) # 大於
db.coll.find({age: {$lt: 22}}) # 大於
db.coll.find({age: 22}) # 等於
db.coll.find({age: {$ne: 22}}) # 不等於
db.coll.find({age: {$gte: 22}}) # 大於等於
db.coll.find({age: {$lte: 22}}) # 小於等於
# 顯示從skip之後limit個
db.coll.find().limit(2).skip(1)
#-----------------------# # 用戶
# 3.x之後版本添加用戶
use admin
db.createUser({user:'nu', pwd:'nu', roles:[{role:'readWrite',db:'admin'}]})
# 用戶認證
db.auth("nu", "nu");
# 顯示當前所有用戶
show users;
db.system.users.find()
3.x版本刪除用戶
db.removeUser('nu') # 不推薦使用，已經廢棄
db.dropUser("nu");
# 當前db版本
db.version();
# 當前db的鏈接機器地址和埠
db.getMongo();
# 備份到備份目錄
mongomp
# 從備份目錄恢復備份語句。
mongorestore
咱們下期見。
Ⅳ 北大青鳥java培訓：Hbase知識點總結
hbase概念:非結構化的分布式的面向列存儲非關系型的開源的資料庫，根據谷歌的三大論文之一的bigtable高寬厚表作用:為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題。
能幹什麼:存儲大量結果集數據，低延遲的隨機查詢。
sql:結構化查詢語言nosql:非關系型資料庫，列存儲和文檔存儲(查詢低延遲),hbase是nosql的一個種類，其特點是列式存儲。
非關系型資料庫--列存儲(hbase)非關系型資料庫--文檔存儲(MongoDB)非關系型資料庫--內存式存儲(redis)非關系型資料庫--圖形模型(graph)hive和hbase區別?Hive的定位是數據倉庫，雖然也有增刪改查，但其刪改查對應的是整張表而不是單行數據，查詢的延遲較高。
其本質是更加方便的使用mr的威力來進行離線分析的一個數據分析工具。
HBase的定位是hadoop的資料庫，電腦培訓http://www.kmbdqn.cn/發現是一個典型的Nosql，所以HBase是用來在大量數據中進行低延遲的隨機查詢的。
hbase運行方式:standalonedistrubited單節點和偽分布式?單節點:單獨的進程運行在同一台機器上hbase應用場景:存儲海量數據低延遲查詢數據hbase表由多行組成hbase行一行在hbase中由行健和一個或多個列的值組成，按行健字母順序排序的存儲。
Ⅵ mongodb數據導出和數據備份的區別
MongoDB是文檔型的行存儲，行存儲的讀寫過程是一致的，都是從第一列開始，到最後一列結束。行存儲的寫入是一次性完成，消耗的時間比列存儲少，並且能夠保證數據的完整性，缺點是數據讀取過程中會產生冗餘數據，如果只有少量數據，此影響可以忽略...
Ⅶ MongoDB是什麼，怎麼用看完你就知道了
MongoDB是一款為web應用程序和互聯網基礎設施設計的資料庫管理系統。沒錯MongoDB就是資料庫，是NoSQL類型的資料庫。
（1）MongoDB提出的是文檔、集合的概念，使用BSON（類JSON）作為其數據模型結構，其結構是面向對象的而不是二維表，存儲一個用戶在MongoDB中是這樣子的。
使用這樣的數據模型，使得MongoDB能在生產環境中提供高讀寫的能力，吞吐量較於mysql等SQL資料庫大大增強。
（2）易伸縮，自動故障轉移。易伸縮指的是提供了分片能力，能對數據集進行分片，數據的存儲壓力分攤給多台伺服器。自動故障轉移是副本集的概念，MongoDB能檢測主節點是否存活，當失活時能自動提升從節點為主節點，達到故障轉移。
（3）數據模型因為是面向對象的，所以可以表示豐富的、有層級的數據結構，比如博客系統中能把「評論」直接懟到「文章「的文檔中，而不必像myqsl一樣創建三張表來描述這樣的關系。
（1）文檔數據類型
SQL類型的資料庫是正規化的，可以通過主鍵或者外鍵的約束保證數據的完整性與唯一性，所以SQL類型的資料庫常用於對數據完整性較高的系統。MongoDB在這一方面是不如SQL類型的資料庫，且MongoDB沒有固定的Schema，正因為MongoDB少了一些這樣的約束條件，可以讓數據的存儲數據結構更靈活，存儲速度更加快。
（2）即時查詢能力
MongoDB保留了關系型資料庫即時查詢的能力，保留了索引（底層是基於B tree）的能力。這一點汲取了關系型資料庫的優點，相比於同類型的NoSQL redis 並沒有上述的能力。
（3）復制能力
MongoDB自身提供了副本集能將數據分布在多台機器上實現冗餘，目的是可以提供自動故障轉移、擴展讀能力。
（4）速度與持久性
MongoDB的驅動實現一個寫入語義 fire and forget ，即通過驅動調用寫入時，可以立即得到返回得到成功的結果（即使是報錯），這樣讓寫入的速度更加快，當然會有一定的不安全性，完全依賴網路。
MongoDB提供了Journaling日誌的概念，實際上像mysql的bin-log日誌，當需要插入的時候會先往日誌裡面寫入記錄，再完成實際的數據操作，這樣如果出現停電，進程突然中斷的情況，可以保障數據不會錯誤，可以通過修復功能讀取Journaling日誌進行修復。
（5）數據擴展
MongoDB使用分片技術對數據進行擴展，MongoDB能自動分片、自動轉移分片裡面的數據塊，讓每一個伺服器裡面存儲的數據都是一樣大小。
MongoDB核心伺服器主要是通過mongod程序啟動的，而且在啟動時不需對MongoDB使用的內存進行配置，因為其設計哲學是內存管理最好是交給操作系統，缺少內存配置是MongoDB的設計亮點，另外，還可通過mongos路由伺服器使用分片功能。
MongoDB的主要客戶端是可以交互的js shell 通過mongo啟動，使用js shell能使用js直接與MongoDB進行交流，像使用sql語句查詢mysql數據一樣使用js語法查詢MongoDB的數據，另外還提供了各種語言的驅動包，方便各種語言的接入。
mongomp和mongorestore,備份和恢復資料庫的標准工具。輸出BSON格式，遷移資料庫。
mongoexport和mongoimport，用來導入導出JSON、CSV和TSV數據，數據需要支持多格式時有用。mongoimport還能用與大數據集的初始導入，但是在導入前順便還要注意一下，為了能充分利用好mongoDB通常需要對數據模型做一些調整。
mongosniff,網路嗅探工具，用來觀察發送到資料庫的操作。基本就是把網路上傳輸的BSON轉換為易於人們閱讀的shell語句。
因此，可以總結得到，MongoDB結合鍵值存儲和關系資料庫的最好特性。因為簡單，所以數據極快，而且相對容易伸縮還提供復雜查詢機制的資料庫。MongoDB需要跑在64位的伺服器上面，且最好單獨部署，因為是資料庫，所以也需要對其進行熱備、冷備處理。
因為本篇文章不是API手冊，所有這里對shell的使用也是基礎的介紹什麼功能可以用什麼語句，主要是為了展示使用MongoDB shell的方便性，如果需要知道具體的MongoDB shell語法可以查閱官方文檔。
創建資料庫並不是必須的操作，資料庫與集合只有在第一次插入文檔時才會被創建，與對數據的動態處理方式是一致的。簡化並加速開發過程，而且有利於動態分配命名空間。如果擔心資料庫或集合被意外創建，可以開啟嚴格模式。
以上的命令只是簡單實例，假設如果你之前沒有學習過任何資料庫語法，同時開始學sql查詢語法和MongoDB 查詢語法，你會發現哪一個更簡單呢？如果你使用的是java驅動去操作MongoDB，你會發現任何的查詢都像Hibernate提供出來的查詢方式一樣，只要構建好一個查詢條件對象，便能輕松查詢（接下來會給出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成沒問題，也正因為這樣簡潔，完善的查詢機制，深深的愛上了MongoDB。
使用java驅動鏈接MongoDB是一件非常簡單的事情，簡單的引用，簡單的做增刪改查。在使用完java驅動後我才發現spring 對MongoDB 的封裝還不如官方自身提供出來的東西好用，下面簡單的展示一下使用。
這里只舉例了簡單的鏈接與簡單的MongoDB操作，可見其操作的容易性。使用驅動時是基於TCP套接字與MongoDB進行通信的，如果查詢結果較多，恰好無法全部放進第一伺服器中，將會向伺服器發送一個getmore指令獲取下一批查詢結果。
插入數據到伺服器時間，不會等待伺服器的響應，驅動會假設寫入是成功的，實際是使用客戶端生成對象id，但是該行為可以通過配置配置，可以通過安全模式開啟，安全模式可以校驗伺服器端插入的錯誤。
要清楚了解MongoDB的基本數據單元。在關系型資料庫中有帶列和行的數據表。而MongoDB數據的基本單元是BSON文檔，在鍵值中有指向不定類型值的鍵，MongoDB擁有即時查詢，但不支持聯結操作，簡單的鍵值存儲只能根據單個鍵來獲取值，不支持事務，但支持多種原子更新操作。
如讀寫比是怎樣的，需要何種查詢，數據是如何更新的，會不會存在什麼並發問題，數據結構化的程度是要求高還是低。系統本身的需求決定mysql還是MongoDB。
在關於schema 的設計中要注意一些原則，比如：
資料庫是集合的邏輯與物理分組，MongoDB沒有提供創建資料庫的語法，只有在插入集合時，資料庫才開始建立。創建資料庫後會在磁碟分配一組數據文件，所有集合、索引和資料庫的其他元數據都保存在這些文件中，查閱資料庫使用磁碟狀態可通過。
集合是結構上或概念上相似得文檔的容器，集合的名稱可以包含數字、字母或 . 符號，但必須以字母或數字開頭，完全。
限定集合名不能超過128個字元，實際上 . 符號在集合中很有用，能提供某種虛擬命名空間，這是一種組織上的原則，和其他集合是一視同仁的。在集合中可以使用。
其次是鍵值，在MongoDB裡面所有的字元串都是UTF-8類型。數字類型包括double、int、long。日期類型都是UTC格式，所以在MongoDB裡面看到的時間會比北京時間慢8小時。整個文檔大小會限制在16m以內，因為這樣可以防止創建難看的數據類型，且小文檔可以提升性能，批量插入文檔理想數字范圍是10~200，大小不能超過16MB。
（1）索引能顯著減少獲取文檔的所需工作量，具體的對比可以通過 .explain()方法進行對比
（2）解析查詢時MongoDB通過最優計劃選擇一個索引進行查詢，當沒有最適合索引時，會先不同的使用各個索引進行查詢，最終選出一個最優索引做查詢
（3）如果有一個a-b的復合索引，那麼僅針對a的索引是冗餘的
（4）復合索引里的鍵的順序是很重要的
（1）單鍵索引
（2）復合索引
（3）唯一性索引
（4）稀疏索引
如索引的欄位會出現null的值，或是大量文檔都不包含被索引的鍵。
如果數據集很大時，構建索引將會花費很長的時間，且會影響程序性能，可通過
當使用 mongorestore 時會重新構建索引。當曾經執行過大規模的刪除時，可使用
對索引進行壓縮，重建。
（1）查閱慢查詢日誌
（2）分析慢查詢
注意新版本的MongoDB 的explain方法是需要參數的，不然只顯示普通的信息。
本節同樣主要簡單呈現MongoDB副本集搭建的簡易性，與副本集的強壯性，監控容易性
提供主從復制能力，熱備能力，故障轉移能力
實際上MongoDB對副本集的操作跟mysql主從操作是差不多的，先看一下mysql的主從數據流動過程
而MongoDB主要依賴的日誌文件是oplog
寫操作先被記錄下來，添加到主節點的oplog里。與此同時，所有從結點復制oplog。首先，查看自己oplog里最後一條的時間戳；其次，查詢主節點oplog里所有大於此時間戳的條目;最後，把那些條目添加到自己的oplog里並應用到自己的庫里。從節點使用長輪詢立即應用來自主結點oplog的新條目。
當遇到以下情況，從節點會停止復制
local資料庫保存了所有副本集元素據和oplog日誌
可以使用以下命令查看復制情況
每個副本集成員每秒鍾ping一次其他所有成員，可以通過rs.status()看到節點上次的心跳檢測時間戳和 健康 狀況。
這個點沒必要過多描述，但是有一個特殊場景，如果從節點和仲裁節點都被殺了，只剩下主節點，他會把自己降級成為從節點。
如果主節點的數據還沒有寫到從庫，那麼數據不能算提交，當該主節點變成從節點時，便會觸發回滾，那些沒寫到從庫的數據將會被刪除，可以通過rollback子目錄中的BSON文件恢復回滾的內容。
（1）使用單節點鏈接
只能鏈接到主節點，如果鏈接到從節點的話，會被拒絕寫入操作，但是如果沒有使用安全模式，因為mongo的fire and forget 特性，會把拒絕寫入的異常給吃掉。
（2）使用副本集方式鏈接
能根據寫入的情況自動進行故障轉移，但是當副本集進行新的選舉時，還是會出現故障，如果不使用安全模式，依舊會出現寫不進去，但現實成功的情況。
分片是資料庫切分的一個概念實現，這里也是簡單總結為什麼要使用分片以及分片的原理，操作。
當數據量過大，索引和工作數據集佔用的內存就會越來越多，所以需要通過分片負載來解決這個問題
（1）分片組件
（2）分片的核心操作
分片一個集合：分片是根據一個屬性的范圍進行劃分的，MongoDB使用所謂的分片鍵讓每個文檔在這些范圍里找到自己的位置
塊：是位於一個分片中的一段連續的分片鍵范圍，可以理解為若干個塊組成分片，分片組成MongoDB的全部數據
（3）拆分與遷移
塊的拆分：初始化時只有一個塊，達到最大塊尺寸64MB或100000個文檔就會觸發塊的拆分。把原來的范圍一分為二，這樣就有了兩個塊，每個塊都有相同數量的文檔。
遷移：當分片中的數據大小不一時會產生遷移的動作，比如分片A的數據比較多，會將分片A裡面的一些塊轉移到分片B裡面去。分片集群通過在分片中移動塊來實現均衡，是由名為均衡器的軟體進程管理的，任務是確保數據在各個分片中保持均勻分布，當集群中擁有塊最多的分片與擁有塊最少分片的塊差大於8時，均衡器就會發起一次均衡處理。
啟動兩個副本集、三個配置伺服器、一個mongos進程
配置分片
（1）分片查詢類型
（2）索引
分片集合只允許在_id欄位和分片鍵上添加唯一性索引，其他地方不行，因為這需要在分片間進行通信，實施起來很復雜。
當創建分片時，會根據分片鍵創建一個索引。
（1）分片鍵是不可修改的、分片鍵的選擇非常重要
（2）低效的分片鍵
（3）理想的分片鍵
（1）部署拓撲
根據不同的數據中心劃分
這里寫圖片描述
（2）最低要求
（3）配置的注意事項
需要估計集群大小，可使用以下命令對現有集合進行分片處理
（4）備份分片集群
備份分片時需要停止均衡器
（1）部署架構
使用64位機器、32位機器會制約mongodb的內存，使其最大值為1.5GB
（2）cpu
mongodb 只有當索引和工作集都可放入內存時，才會遇到CPU瓶頸，CPU在mongodb使用中的作用是用來檢索數據，如果看到CPU使用飽和的情況，可以通過查詢慢查詢日誌，排查是不是查詢的問題導致的，如果是可以通過添加索引來解決問題
mongodb寫入數據時會使用到CPU，但是mongodb寫入時間一次只用到一個核，如果有頻繁的寫入行為，可以通過分片來解決這個問題
（3）內存
大內存是mongodb的保障，如果工作集大小超過內存，將會導致性能下降，因為這將會增加數據載入入內存的動作
（4）硬碟
mongodb默認每60s會與磁碟強制同步一次，稱為後台刷新，會產生I/O操作。在重啟時mongodb會將磁碟裡面的數據載入至內存，高速磁碟將會減少同步的時間
（5）文件系統
使用ext4 和 xfs 文件系統
禁用最後訪問時間
（6）文件描述符
linux 默認文件描述符是1024，需要大額度的提升這個額度
（7）時鍾
mongodb各個節點伺服器之間使用ntp伺服器
（1）綁定IP
啟動時使用 - -bind_ip 命令
（2）身份驗證
啟動時使用 - -auth 命令
（3）副本集身份認證
使用keyFile，注意keyFile文件的許可權必須是600，不然會啟動不起來
（1）拓撲結構
搭建副本集至少需要兩個節點，其中仲裁結點不需要有自己的伺服器
（2）Journaling日誌
寫數據時會先寫入日誌，而此時的數據也不是直接寫入硬碟，而是寫入內存
但是Journaling日誌會消耗內存，所以可以在主庫上面關閉，在從庫上面啟動
可以單獨為Journaling日誌使用一塊固態硬碟
在插入時，可以通過驅動確保Journaling插入後再反饋，但是會非常影響性能。
logpath 選項指定日誌存儲地址
-vvvvv 選項（v越多，輸出越詳細）
db.runCommand({logrotare:1}) 開啟滾動日誌
（1）serverStatus
這里寫圖片描述
（2）top
（3）db.currentOp()
動態展示mongodb活動數據
佔用當前mongodb監聽埠往上1000號的埠
（1）mongomp
把資料庫內容導出成BSON文件，而mongorestore能讀取並還原這些文件
（2）mongorestore
把導出的BSON文件還原到資料庫
（3）備份原始數據文件
可以這么做，但是，操作之前需要進行鎖庫處理 db.runCommand({fsync:1,lock:true})
db.$cmd.sys.unlock.findOne() 請求解鎖操作，但是資料庫不會立刻解鎖，需要使用db.currentOp()驗證。
（1）修復
mongd --repair 修復所有資料庫
db.runCommand({repairDatabase:1}) 修復單個資料庫
修復就是根據Jourling文件讀取和重寫所有數據文件並重建各個索引
（2）壓緊
壓緊，會重寫數據文件，並重建集合的全部索引，需要停機或者在從庫上面運行,如果需要在主庫上面運行，需要添加force參數 保證加寫鎖。
（1）監控磁碟狀態
（2）為提升性能檢查索引和查詢
總的來說，掃描盡可能少的文檔。
保證沒有冗餘的索引，冗餘的索引會佔用磁碟空間、消耗更多的內存，在每次寫入時還需做更多工作
（3）添加內存
dataSize 數據大小 和 indexSize 索引大小，如果兩者的和大於內存，那麼將會影響性能。
storageSize超過dataSize 數據大小 兩倍以上，就會因磁碟碎片而影響性能，需要壓縮。
Ⅷ 常見的基於列存儲的大數據資料庫有哪些
目前大數據存儲有兩種方案可供選擇：行存儲和列存儲。業界對兩種存儲方案有很多爭持，集中焦點是:誰能夠更有效地處理海量數據，且兼顧安全、可靠、完整性。從目前發展情況看，關系資料庫已經不適應這種巨大的存儲量和計算要求，基本是淘汰出局。在已知的幾種大數據處理軟體中，Hadoop的HBase採用列存儲，MongoDB是文檔型的行存儲，Lexst是二進制型的行存儲。在這里，我不討論這些軟體的技術和優缺點，只圍繞機械磁碟的物理特質，分析行存儲和列存儲的存儲特點，以及由此產生的一些問題和解決辦法。
Ⅸ mongodb 是列存資料庫嗎
Mongodb使用的是文件存儲系統。只是在文件系統的基礎之上增加了文件地址的索引以提高查詢速度。
如果你還不是很熟悉，可以看看慕課網。
Ⅹ MongoDB 是什麼看完你就知道了
點擊上方 藍色字體 ，選擇「置頂公眾號」
優質文章，第一時間送達
鏈接 | blog.csdn.net/hayre/article/details/80628431
1.MongoDB是什麼？用一句話總結
MongoDB是一款為web應用程序和互聯網基礎設施設計的資料庫管理系統。沒錯MongoDB就是資料庫，是NoSQL類型的資料庫。
（1）MongoDB提出的是文檔、集合的概念，使用BSON（類JSON）作為其數據模型結構，其結構是面向對象的而不是二維表，存儲一個用戶在MongoDB中是這樣子的。
使用這樣的數據模型，使得MongoDB能在生產環境中提供高讀寫的能力，吞吐量較於mysql等SQL資料庫大大增強。
（2）易伸縮，自動故障轉移。易伸縮指的是提供了分片能力，能對數據集進行分片，數據的存儲壓力分攤給多台伺服器。自動故障轉移是副本集的概念，MongoDB能檢測主節點是否存活，當失活時能自動提升從節點為主節點，達到故障轉移。
（3）數據模型因為是面向對象的，所以可以表示豐富的、有層級的數據結構，比如博客系統中能把「評論」直接懟到「文章「的文檔中，而不必像myqsl一樣創建三張表來描述這樣的關系。
3.主要特性
（1）文檔數據類型
SQL類型的資料庫是正規化的，可以通過主鍵或者外鍵的約束保證數據的完整性與唯一性，所以SQL類型的資料庫常用於對數據完整性較高的系統。MongoDB在這一方面是不如SQL類型的資料庫，且MongoDB沒有固定的Schema，正因為MongoDB少了一些這樣的約束條件，可以讓數據的存儲數據結構更靈活，存儲速度更加快。 （2）即時查詢能力
MongoDB保留了關系型資料庫即時查詢的能力，保留了索引（底層是基於B tree）的能力。這一點汲取了關系型資料庫的優點，相比於同類型的NoSQL redis 並沒有上述的能力。 （3）復制能力
MongoDB自身提供了副本集能將數據分布在多台機器上實現冗餘，目的是可以提供自動故障轉移、擴展讀能力。 （4）速度與持久性
MongoDB的驅動實現一個寫入語義 fire and forget ，即通過驅動調用寫入時，可以立即得到返回得到成功的結果（即使是報錯），這樣讓寫入的速度更加快，當然會有一定的不安全性，完全依賴網路。
MongoDB提供了Journaling日誌的概念，實際上像mysql的bin-log日誌，當需要插入的時候會先往日誌裡面寫入記錄，再完成實際的數據操作，這樣如果出現停電，進程突然中斷的情況，可以保障數據不會錯誤，可以通過修復功能讀取Journaling日誌進行修復。
（5）數據擴展
MongoDB使用分片技術對數據進行擴展，MongoDB能自動分片、自動轉移分片裡面的數據塊，讓每一個伺服器裡面存儲的數據都是一樣大小。
MongoDB核心伺服器主要是通過mongod程序啟動的，而且在啟動時不需對MongoDB使用的內存進行配置，因為其設計哲學是內存管理最好是交給操作系統，缺少內存配置是MongoDB的設計亮點，另外，還可通過mongos路由伺服器使用分片功能。
MongoDB的主要客戶端是可以交互的js shell 通過mongo啟動，使用js shell能使用js直接與MongoDB進行交流，像使用sql語句查詢mysql數據一樣使用js語法查詢MongoDB的數據，另外還提供了各種語言的驅動包，方便各種語言的接入。
mongomp和mongorestore,備份和恢復資料庫的標准工具。輸出BSON格式，遷移資料庫。
mongoexport和mongoimport，用來導入導出JSON、CSV和TSV數據，數據需要支持多格式時有用。mongoimport還能用與大數據集的初始導入，但是在導入前順便還要注意一下，為了能充分利用好mongoDB通常需要對數據模型做一些調整。
mongosniff,網路嗅探工具，用來觀察發送到資料庫的操作。基本就是把網路上傳輸的BSON轉換為易於人們閱讀的shell語句。
因此，可以總結得到，MongoDB結合鍵值存儲和關系資料庫的最好特性。因為簡單，所以數據極快，而且相對容易伸縮還提供復雜查詢機制的資料庫。MongoDB需要跑在64位的伺服器上面，且最好單獨部署，因為是資料庫，所以也需要對其進行熱備、冷備處理。
因為本篇文章不是API手冊，所有這里對shell的使用也是基礎的介紹什麼功能可以用什麼語句，主要是為了展示使用MongoDB shell的方便性，如果需要知道具體的MongoDB shell語法可以查閱官方文檔。
創建資料庫並不是必須的操作，資料庫與集合只有在第一次插入文檔時才會被創建，與對數據的動態處理方式是一致的。簡化並加速開發過程，而且有利於動態分配命名空間。如果擔心資料庫或集合被意外創建，可以開啟嚴格模式。
以上的命令只是簡單實例，假設如果你之前沒有學習過任何資料庫語法，同時開始學sql查詢語法和MongoDB 查詢語法，你會發現哪一個更簡單呢？如果你使用的是java驅動去操作MongoDB，你會發現任何的查詢都像Hibernate提供出來的查詢方式一樣，只要構建好一個查詢條件對象，便能輕松查詢（接下來會給出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成沒問題，也正因為這樣簡潔，完善的查詢機制，深深的愛上了MongoDB。
使用java驅動鏈接MongoDB是一件非常簡單的事情，簡單的引用，簡單的做增刪改查。在使用完java驅動後我才發現spring 對MongoDB 的封裝還不如官方自身提供出來的東西好用，下面簡單的展示一下使用。
這里只舉例了簡單的鏈接與簡單的MongoDB操作，可見其操作的容易性。使用驅動時是基於TCP套接字與MongoDB進行通信的，如果查詢結果較多，恰好無法全部放進第一伺服器中，將會向伺服器發送一個getmore指令獲取下一批查詢結果。
插入數據到伺服器時間，不會等待伺服器的響應，驅動會假設寫入是成功的，實際是使用客戶端生成對象id，但是該行為可以通過配置配置，可以通過安全模式開啟，安全模式可以校驗伺服器端插入的錯誤。
要清楚了解MongoDB的基本數據單元。在關系型資料庫中有帶列和行的數據表。而MongoDB數據的基本單元是BSON文檔，在鍵值中有指向不定類型值的鍵，MongoDB擁有即時查詢，但不支持聯結操作，簡單的鍵值存儲只能根據單個鍵來獲取值，不支持事務，但支持多種原子更新操作。
如讀寫比是怎樣的，需要何種查詢，數據是如何更新的，會不會存在什麼並發問題，數據結構化的程度是要求高還是低。系統本身的需求決定mysql還是MongoDB。
在關於schema 的設計中要注意一些原則，比如：
資料庫是集合的邏輯與物理分組，MongoDB沒有提供創建資料庫的語法，只有在插入集合時，資料庫才開始建立。創建資料庫後會在磁碟分配一組數據文件，所有集合、索引和資料庫的其他元數據都保存在這些文件中，查閱資料庫使用磁碟狀態可通過。
集合是結構上或概念上相似得文檔的容器，集合的名稱可以包含數字、字母或 . 符號，但必須以字母或數字開頭，完全。
限定集合名不能超過128個字元，實際上 . 符號在集合中很有用，能提供某種虛擬命名空間，這是一種組織上的原則，和其他集合是一視同仁的。在集合中可以使用。
其次是鍵值，在MongoDB裡面所有的字元串都是UTF-8類型。數字類型包括double、int、long。日期類型都是UTC格式，所以在MongoDB裡面看到的時間會比北京時間慢8小時。整個文檔大小會限制在16m以內，因為這樣可以防止創建難看的數據類型，且小文檔可以提升性能，批量插入文檔理想數字范圍是10~200，大小不能超過16MB。
（2）解析查詢時MongoDB通過最優計劃選擇一個索引進行查詢，當沒有最適合索引時，會先不同的使用各個索引進行查詢，最終選出一個最優索引做查詢
（3）如果有一個a-b的復合索引，那麼僅針對a的索引是冗餘的
（4）復合索引里的鍵的順序是很重要的
（2）復合索引
（3）唯一性索引
（4）稀疏索引
如索引的欄位會出現的值，或是大量文檔都不包含被索引的鍵。
如果數據集很大時，構建索引將會花費很長的時間，且會影響程序性能，可通過
當使用 mongorestore 時會重新構建索引。當曾經執行過大規模的刪除時，可使用
對索引進行壓縮，重建。
（1）查閱慢查詢日誌
（2）分析慢查詢
注意新版本的MongoDB 的explain方法是需要參數的，不然只顯示普通的信息。
本節同樣主要簡單呈現MongoDB副本集搭建的簡易性，與副本集的強壯性，監控容易性
提供主從復制能力，熱備能力，故障轉移能力
實際上MongoDB對副本集的操作跟mysql主從操作是差不多的，先看一下mysql的主從數據流動過程
而MongoDB主要依賴的日誌文件是oplog
寫操作先被記錄下來，添加到主節點的oplog里。與此同時，所有從結點復制oplog。首先，查看自己oplog里最後一條的時間戳；其次，查詢主節點oplog里所有大於此時間戳的條目;最後，把那些條目添加到自己的oplog里並應用到自己的庫里。從節點使用長輪詢立即應用來自主結點oplog的新條目。
當遇到以下情況，從節點會停止復制
local資料庫保存了所有副本集元素據和oplog日誌
可以使用以下命令查看復制情況
每個副本集成員每秒鍾ping一次其他所有成員，可以通過rs.status看到節點上次的心跳檢測時間戳和 健康 狀況。
這個點沒必要過多描述，但是有一個特殊場景，如果從節點和仲裁節點都被殺了，只剩下主節點，他會把自己降級成為從節點。
如果主節點的數據還沒有寫到從庫，那麼數據不能算提交，當該主節點變成從節點時，便會觸發回滾，那些沒寫到從庫的數據將會被刪除，可以通過rollback子目錄中的BSON文件恢復回滾的內容。
只能鏈接到主節點，如果鏈接到從節點的話，會被拒絕寫入操作，但是如果沒有使用安全模式，因為mongo的fire and forget 特性，會把拒絕寫入的異常給吃掉。
（2）使用副本集方式鏈接
能根據寫入的情況自動進行故障轉移，但是當副本集進行新的選舉時，還是會出現故障，如果不使用安全模式，依舊會出現寫不進去，但現實成功的情況。
分片是資料庫切分的一個概念實現，這里也是簡單總結為什麼要使用分片以及分片的原理，操作。
當數據量過大，索引和工作數據集佔用的內存就會越來越多，所以需要通過分片負載來解決這個問題
（2）分片的核心操作
分片一個集合：分片是根據一個屬性的范圍進行劃分的，MongoDB使用所謂的分片鍵讓每個文檔在這些范圍里找到自己的位置
塊：是位於一個分片中的一段連續的分片鍵范圍，可以理解為若干個塊組成分片，分片組成MongoDB的全部數據
（3）拆分與遷移
塊的拆分：初始化時只有一個塊，達到最大塊尺寸64MB或100000個文檔就會觸發塊的拆分。把原來的范圍一分為二，這樣就有了兩個塊，每個塊都有相同數量的文檔。
遷移：當分片中的數據大小不一時會產生遷移的動作，比如分片A的數據比較多，會將分片A裡面的一些塊轉移到分片B裡面去。分片集群通過在分片中移動塊來實現均衡，是由名為均衡器的軟體進程管理的，任務是確保數據在各個分片中保持均勻分布，當集群中擁有塊最多的分片與擁有塊最少分片的塊差大於8時，均衡器就會發起一次均衡處理。
啟動兩個副本集、三個配置伺服器、一個mongos進程
配置分片
（2）索引
分片集合只允許在_id欄位和分片鍵上添加唯一性索引，其他地方不行，因為這需要在分片間進行通信，實施起來很復雜。
當創建分片時，會根據分片鍵創建一個索引。
（2）低效的分片鍵
（3）理想的分片鍵
根據不同的數據中心劃分
（2）最低要求
（3）配置的注意事項
需要估計集群大小，可使用以下命令對現有集合進行分片處理
（4）備份分片集群
備份分片時需要停止均衡器
使用64位機器、32位機器會制約mongodb的內存，使其最大值為1.5GB
（2）cpu mongodb 只有當索引和工作集都可放入內存時，才會遇到CPU瓶頸，CPU在mongodb使用中的作用是用來檢索數據，如果看到CPU使用飽和的情況，可以通過查詢慢查詢日誌，排查是不是查詢的問題導致的，如果是可以通過添加索引來解決問題
mongodb寫入數據時會使用到CPU，但是mongodb寫入時間一次只用到一個核，如果有頻繁的寫入行為，可以通過分片來解決這個問題 （3）內存
大內存是mongodb的保障，如果工作集大小超過內存，將會導致性能下降，因為這將會增加數據載入入內存的動作
（4）硬碟
mongodb默認每60s會與磁碟強制同步一次，稱為後台刷新，會產生I/O操作。在重啟時mongodb會將磁碟裡面的數據載入至內存，高速磁碟將會減少同步的時間
（5）文件系統
使用ext4 和 xfs 文件系統
禁用最後訪問時間
（6）文件描述符
linux 默認文件描述符是1024，需要大額度的提升這個額度
（7）時鍾
mongodb各個節點伺服器之間使用ntp伺服器
啟動時使用 - -bind_ip 命令
（2）身份驗證
啟動時使用 - -auth 命令
（3）副本集身份認證
使用keyFile，注意keyFile文件的許可權必須是600，不然會啟動不起來
搭建副本集至少需要兩個節點，其中仲裁結點不需要有自己的伺服器
（2）Journaling日誌 寫數據時會先寫入日誌，而此時的數據也不是直接寫入硬碟，而是寫入內存
但是Journaling日誌會消耗內存，所以可以在主庫上面關閉，在從庫上面啟動
可以單獨為Journaling日誌使用一塊固態硬碟
在插入時，可以通過驅動確保Journaling插入後再反饋，但是會非常影響性能。
-vvvvv 選項（v越多，輸出越詳細）
db.runCommand({logrotare:1}) 開啟滾動日誌
（2）top
（3）db.currentOp
動態展示mongodb活動數據
佔用當前mongodb監聽埠往上1000號的埠
把資料庫內容導出成BSON文件，而mongorestore能讀取並還原這些文件
（2）mongorestore
把導出的BSON文件還原到資料庫
（3）備份原始數據文件 可以這么做，但是，操作之前需要進行鎖庫處理 db.runCommand({fsync:1,lock:true}) db.$cmd.sys.unlock.findOne 請求解鎖操作，但是資料庫不會立刻解鎖，需要使用 db.currentOp 驗證。
db.runCommand({repairDatabase:1}) 修復單個資料庫
修復就是根據Jourling文件讀取和重寫所有數據文件並重建各個索引 （2）壓緊
壓緊，會重寫數據文件，並重建集合的全部索引，需要停機或者在從庫上面運行,如果需要在主庫上面運行，需要添加force參數 保證加寫鎖。
（2）為提升性能檢查索引和查詢
總的來說，掃描盡可能少的文檔。
保證沒有冗餘的索引，冗餘的索引會佔用磁碟空間、消耗更多的內存，在每次寫入時還需做更多工作
（3）添加內存
dataSize 數據大小 和 indexSize 索引大小，如果兩者的和大於內存，那麼將會影響性能。
storageSize超過dataSize 數據大小 兩倍以上，就會因磁碟碎片而影響性能，需要壓縮。