Access數(shù)據(jù)庫中報表特點？

用Access數(shù)據(jù)庫做報表特點是，很簡單方便，應(yīng)用難度不高，門檻低，缺點是可視化和拓寬思維化不強，這對大批量數(shù)據(jù)的分析和研究不夠

db模式有什么優(yōu)缺點？

mongodb按結(jié)構(gòu)數(shù)據(jù)文件預(yù)分配模式來生成數(shù)據(jù)文件，數(shù)據(jù)文件的大小從64M又開始，每減少一個文件，大小雙倍，等到2G，以后有時候增強數(shù)據(jù)可能會化合2G左右的數(shù)據(jù)文件，結(jié)合mongodb的mmap內(nèi)存模型，對此寫數(shù)據(jù)文件，將必掉寫可以轉(zhuǎn)換為順序?qū)?，一定程度上緩解了磁盤的io壓力。

但在實際可以使用中，遇上在預(yù)分配2G的數(shù)據(jù)文件時，要是磁盤io較慢，則mongodb都差不多卡住了，無法做出反應(yīng)各位的情況。短短時間則依據(jù)磁盤io的性能來確認(rèn)。這個問題在2.0之后版本可能會有些可以改善，但在磁盤性能低的服務(wù)器上，該問題依然存在.

這個問題目前沒有太好的解決方案，只能個人建議建議使用讀寫性能比較比較好的服務(wù)器來跑mongodb。

在數(shù)據(jù)存量大于0內(nèi)存大小時，mongodb遇上冷數(shù)據(jù)查詢速度變慢。

mongodb可以使用mmap的內(nèi)存管理模式，如果不是網(wǎng)上查詢的大都熱數(shù)據(jù)，這樣會在內(nèi)存中就去查詢，如果沒有遇上冷數(shù)據(jù)，就要從磁盤讀取，并將一部分熱數(shù)據(jù)從內(nèi)存卸載掉.

有人那一次說mongodb內(nèi)存管理是運行程序固定不動大小的文件塊到內(nèi)存，即如果不是冷數(shù)據(jù)在磁盤上，他會參照幫忙的數(shù)據(jù)，運行程序肯定會大小的數(shù)據(jù)塊到內(nèi)存，并軟件卸載掉則是的熱數(shù)據(jù)，這個操作本身會受到一定會io.

只不過mongodb不使用的是全局鎖，在某個操作緩慢時，這座能操作隊列會完全變慢。這個問題會造成了mongodb會出現(xiàn)偶發(fā)性堵塞問題，隨之整個庫的性能會下降。

該問題在應(yīng)用要不要盡量的避免又出現(xiàn)，必須將mongodb的數(shù)據(jù)大小規(guī)劃好，最好不要別使數(shù)據(jù)量達(dá)到內(nèi)存的大小，如果沒有遠(yuǎn)遠(yuǎn)超過內(nèi)存大小后，最好不要最好不要去各位冷數(shù)據(jù)。

Mongodb全局鎖機制。

mongodb大的問題或者可以算是它的鎖機制，在2.2版本之前，一個實例只能一個讀寫鎖，無論有多少數(shù)據(jù)庫和數(shù)據(jù)子集，當(dāng)一個操作通過時其他操作沒法等待，在2.2版本后，mongodb鎖降低了粒度，轉(zhuǎn)成按庫鎖。

MongoDB使用的是“readers-writer”鎖，是可以支持并發(fā)但有不大的局限性，當(dāng)一個讀鎖未知,許多讀操作也可以可以使用這把鎖，但他,當(dāng)一個寫鎖的存在，一個單一的寫操作會exclusively300499高瀾股份該鎖，另外其它讀，寫操作不能不能在用共享這個鎖；舉個例子，題中一個集合里有10個文檔，多個version操作沒法并發(fā)在這個集合上，就算是可以更新不同的文檔。

刪出數(shù)據(jù)集合后空間絕對不會自動釋放出

mongodb刪掉集合后磁盤空間不釋放者，只有一用()去能修復(fù)才能釋放者。

修復(fù)很有可能要花費很長的時間,在建議使用()去自動修復(fù)時必須得停掉讀寫，另外mongodb要有備機才可以，要不然千萬別隨便是建議使用()來修復(fù)數(shù)據(jù)庫，一定不要。

只不過在能修復(fù)的過程中如果再次出現(xiàn)了非都正常的mongodb的全死，再一次啟動后時啟動不了的，是需要先可以修復(fù)才也可以，也可以憑借./mongod--disassembly--dbpath/data/mongo/假如你是把數(shù)據(jù)庫單獨的放在一個文件夾中委托dbpath時就指向要修復(fù)的數(shù)據(jù)庫就這個可以。

一些含著問題

a)replicaset模式至少意見臺服務(wù)器，而有投票權(quán)的服務(wù)器只接受7臺，如果沒有超過7臺服務(wù)器，需可以設(shè)置部分服務(wù)器為無投票權(quán)服務(wù)器

b)replicaset模式中，一個set服務(wù)器如果不是大于臺服務(wù)器，則自動啟動默認(rèn)操作應(yīng)該不會起作用，如果沒有4臺服務(wù)器再次出現(xiàn)2/2相互交換ping不通的情況，同樣的應(yīng)該不會不自動故障恢復(fù)。一般來說，一個set中最好就是是有單數(shù)形式服務(wù)器。

c).replicaset中，因為mongodb是明確的時間進(jìn)行不能操作，如果set中某個服務(wù)器時間很超前或者延遲大，會容易又出現(xiàn)secondaries不斷的嘗試沒更新oplog也可以同步網(wǎng)絡(luò)延遲的問題。甚至于倒致某些操作失敗的話，如move你的操作。

8.分片模式的一些含著問題

盡量通過官方的要求，有3個configserver，假如唯有2個configserver，則shard的自動負(fù)載均衡和自動啟動切片功能不可用。

2.api中的nearest模式在shard中，判斷的是set到mongos的距離而非set到client的距離，在切片模式下，盡量別建議使用nearest模式，很有可能會造成一些請求服務(wù)器延遲減少的問題。

優(yōu)點

l文檔結(jié)構(gòu)的存儲，還能夠更便捷的查看數(shù)據(jù)

l內(nèi)置GridFS，意見大容量的存儲

l內(nèi)置Sharding，分片簡單的

l海量數(shù)據(jù)下，性能突出

l接受自動啟動系統(tǒng)失?。ń貓D集）

mongodb是另一個介于nosql數(shù)據(jù)庫和mysql數(shù)據(jù)庫之間的一個數(shù)據(jù)存儲系統(tǒng)，它沒有嚴(yán)格的的數(shù)據(jù)格式，但另外支持什么復(fù)雜網(wǎng)站查詢，而且那個軟件sharding模式和ReplicaSet模式，接受分片模式，剪切粘貼模式，手動故障維護(hù)，自動出現(xiàn)故障轉(zhuǎn)移，自動啟動快速擴容，全內(nèi)容索引，動態(tài)查詢等功能。擴展性和功能都比較比較強大。

mongodb在數(shù)據(jù)查詢方面，允許類sql查詢，可以不一個key多value內(nèi)容，也可以成組合多個value內(nèi)容來去查詢，允許索引，接受組織索引，支持什么復(fù)雜查詢，支持什么排序，基本除了join和事務(wù)類型的操作外，mongodb支持所有mysql支持的查詢，甚至某個客戶端api支持直接在用sql語句查詢mongodb。

mongodb的sharding功能目前漸長系統(tǒng)完善，意見下拉菜單范圍分片，hash自動啟動分片等，分片自動啟動內(nèi)存量，shard之間手動負(fù)載均衡等功能。不好算使用能還比較不錯。