(原)MongoDB在系統中的使用

時間 2019-12-05

原文原文鏈接

序）Nosql並非要取代原有的數據產品，而是爲不一樣的應用場景提供更多的選擇。mysql

一）結構類型sql

　　傳統數據庫的領域在於結構化文檔，對於非結構化文檔和半結構化文檔，它能處理，可是有必定的缺陷，那麼什麼又是結構化文檔，歸納以下：shell

　　結構化信息——這種信息能夠在關係數據庫中找到，多年來一直主導着IT應用。這是關鍵任務OLTP系統業務所依賴的信息，另外，還可對結構數據庫信息進行排序和查詢；數據庫

　　半結構化信息——這是IT的第二次浪潮，包括電子郵件，文字處理文件以及大量保存和發佈在網絡上的信息。半結構化信息是之內容爲基礎，能夠用於搜索，這也是谷歌存在的理由；服務器

　　非結構化信息——該信息在本質形式上可認爲主要是位映射數據。數據必須處於一種可感知的形式中（諸如可在音頻、視頻和多媒體文件中被聽或被看）。許多大數據都是非結構化的，其龐大規模和複雜性須要高級分析工具來建立或利用一種更易於人們感知和交互的結構。網絡

二）MongoDB和行導向數據庫的區別分佈式

　　老實說，我以爲Nosql領域比較奇葩的東西算是Hive，不過在此不介紹它，對於項目中使用到MongoDB，也是有必定緣由的，我一直覺得Nosql這種東西和行導向數據庫並不衝突，它僅僅是行導向數據的一個補充，對於MongoDB，它和咱們用的mysql，Oracle等有什麼區別，曾經我也查找過一些東西，發現網上不少相關的文章都是千篇一概，幾乎如出一轍，沒啥價值，因而捉摸本身總結下。memcached

　　舉個栗子：工具

uid	name	age
1	張三	18

　　在上面的表中，很直接，數據也很直觀，可是若是咱們須要存儲另一個東西：頭像，通常人會這樣幹：oop

uid	name	age	photo
1	張三	18	./upload/1.png

　　儘管不一樣數據庫都提供了直接存儲二進制的數據庫字段，可是我仍是會選擇以上的存儲方式，我相信也有不少人也會這樣作，這樣作其實沒有什麼很差，可是若是咱們的文件很大，幾個GB，那麼不管讀仍是寫都會很耗時，成爲系統的瓶頸，基於這種狀況，纔會誕生雲計算以及Nosql這些東西，也就是說Hadoop，Hbase等誕生的緣由是：

　　多年來磁盤存儲容量快速增長的同時，訪問速度-磁盤數據讀取速度卻未能與時俱進,尋址時間的提升遠遠慢於傳輸速率的提升，尋址是將磁盤移動到特定磁盤位置進行讀寫操做，它是致使磁盤操做延遲的主要緣由，而傳輸速率取決與磁盤的帶寬。

　　因而人們想出了一個辦法：既然在一個服務器讀取一個文件須要100個小時，那麼將文件放在100個服務器，每一個服務器放1%的數據，那麼1小時就搞定了，這也是Hadoop的核心思想，MongoDB數據庫繼承了這一思想，它的區塊劃分，以及節點分裂，都延續了這樣的思想，另外一方面，MongoDB又吸收了memcached的東西，提早申請一片內存區域以及文件區域，將內存中的地址和物理地址對應起來，能夠極高的提升速度，這也是MongoDB至關的消耗內存和磁盤的緣由之一。

三）MongoDB應用範圍

　　1：MongoDB與傳統數據庫整合：

id	user_id	title	content	time
1	張三	文章標題	文章內容	時間

　　在以上表中，若是內容是一個包含上千上萬字的文章，通常會該字段的內容丟入MongoDB，而後在此放入MongoDB的ID。

　　2：MongoDB取代傳統數據庫：

　　在某些事物要求不高的場合，以及容許出現部分錯誤的系統中，可使用MongoDB取代傳統數據庫，例如論壇，博客等系統，舉個栗子：

　　博客有人發表了一篇文章，MongoDB存儲以下：

> db.article.insert({"title":"測試文章","content":"測試內容", "time":"17822455", "uid":"1"});
WriteResult({ "nInserted" : 1 })
> db.article.findOne();
{
        "_id" : ObjectId("546168c9573c0742d8be1544"),
        "title" : "測試文章",
        "content" : "測試內容",
        "time" : "17822455",
        "uid" : "1"
}
>

　　如今有一我的對這篇文章進行了評論，以下：

> var articleInfo = db.article.findOne({"_id":ObjectId("54616db1d92589121def0c70")});
> articleInfo;
{
        "_id" : ObjectId("54616db1d92589121def0c70"),
        "title" : "測試文章",
        "content" : "測試內容",
        "time" : "17822455",
        "uid" : "1"
}
> articleInfo.commentary={"uid":"2",info :{"content":"這篇文章不錯","times":"145881444"}};
{
        "uid" : "2",
        "info" : {
                "content" : "這篇文章不錯",
                "times" : "145881444"
        }
}
> db.article.update({"_id": ObjectId("54616db1d92589121def0c70")},articleInfo);
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.article.findOne({"_id":ObjectId("54616db1d92589121def0c70")});
{
        "_id" : ObjectId("54616db1d92589121def0c70"),
        "title" : "測試文章",
        "content" : "測試內容",
        "time" : "17822455",
        "uid" : "1",
        "commentary" : {
                "uid" : "2",
                "info" : {
                        "content" : "這篇文章不錯",
                        "times" : "145881444"
                }
        }
}
>

　　如今又有一我的對它評論以下：

　　因而MongoDB的存儲結構成了這樣：

> db.article.update({"_id":ObjectId("54617115d92589121def0c72")}, {"$push": {"commentary":{"uid":3,info :{"content":"我也這篇文章不錯","times":"1444"}}}});
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.article.findOne({"_id":ObjectId("54617115d92589121def0c72")});
{
        "_id" : ObjectId("54617115d92589121def0c72"),
        "title" : "測試文章",
        "content" : "測試內容",
        "time" : "17822455",
        "uid" : "1",
        "commentary" : [
                {
                        "uid" : 2,
                        "info" : {
                                "content" : "這篇文章不錯",
                                "times" : "1444"
                        }
                },
                {
                        "uid" : 3,
                        "info" : {
                                "content" : "我也這篇文章不錯",
                                "times" : "1444"
                        }
                }
        ]
}
>