MySQL和MongoDB設計實例對比

2020-12-16 站長之家
首頁

 > 

語言

 > 

關鍵詞

 > 

資料庫最新資訊

 > 

正文

MySQL和MongoDB設計實例對比

MySQL是關係型資料庫中的明星,MongoDB是文檔型資料庫中的翹楚。下面通過一個設計實例對比一下二者:假設我們正在維護一個手機產品庫,裡面除了包含手機的名稱,品牌等基本信息,還包含了待機時間,外觀設計等參數信息,應該如何存取數據呢?

如果使用MySQL的話,應該如何存取數據呢?

如果使用MySQL話,手機的基本信息單獨是一個表,另外由於不同手機的參數信息差異很大,所以還需要一個參數表來單獨保存。

CREATE TABLE IF NOT EXISTS `mobiles` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(100) NOT NULL,
    `brand` VARCHAR(100) NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE IF NOT EXISTS `mobile_params` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `mobile_id` int(10) unsigned NOT NULL,
    `name` varchar(100) NOT NULL,
    `value` varchar(100) NOT NULL,
    PRIMARY KEY (`id`)
);

INSERT INTO `mobiles` (`id`, `name`, `brand`) VALUES
(1, 'ME525', '摩託羅拉'),
(2, 'E7'   , '諾基亞');

INSERT INTO `mobile_params` (`id`, `mobile_id`, `name`, `value`) VALUES
(1, 1, '待機時間', '200'),
(2, 1, '外觀設計', '直板'),
(3, 2, '待機時間', '500'),
(4, 2, '外觀設計', '滑蓋');

註:為了演示方便,沒有嚴格遵守關係型資料庫的範式設計。

如果想查詢待機時間大於100小時,並且外觀設計是直板的手機,需要按照如下方式查詢:

SELECT * FROM `mobile_params` WHERE name = '待機時間' AND value > 100;
SELECT * FROM `mobile_params` WHERE name = '外觀設計' AND value = '直板';

註:參數表為了方便,把數值和字符串統一保存成字符串,實際使用時,MySQL允許在字符串類型的欄位上進行數值類型的查詢,只是需要進行類型轉換,多少會影響一點性能。

兩條SQL的結果取交集得到想要的MOBILE_ID,再到mobiles表查詢即可:

SELECT * FROM `mobiles` WHERE mobile_id IN (MOBILE_ID)

如果使用MongoDB的話,應該如何存取數據呢?

如果使用MongoDB的話,雖然理論上可以採用和MySQL一樣的設計方案,但那樣的話就顯得無趣了,沒有發揮出MongoDB作為文檔型資料庫的優點,實際上使用MongoDB的話,和MySQL相比,形象一點來說,可以合二為一:

db.getCollection("mobiles").ensureIndex({
    "params.name": 1,
    "params.value": 1
});

db.getCollection("mobiles").insert({
    "_id": 1,
    "name": "ME525",
    "brand": "摩託羅拉",
    "params": [
        {"name": "待機時間", "value": 200},
        {"name": "外觀設計", "value": "直板"}
    ]
});

db.getCollection("mobiles").insert({
    "_id": 2,
    "name": "E7",
    "brand": "諾基亞",
    "params": [
        {"name": "待機時間", "value": 500},
        {"name": "外觀設計", "value": "滑蓋"}
    ]
});

如果想查詢待機時間大於100小時,並且外觀設計是直板的手機,需要按照如下方式查詢:

db.getCollection("mobiles").find({
    "params": {
        $all: [
            {$elemMatch: {"name": "待機時間", "value": {$gt: 100}}},
            {$elemMatch: {"name": "外觀設計", "value": "直板"}}
        ]
    }
});

註:查詢中用到的$all$elemMatch等高級用法的詳細介紹請參考官方文檔中相關說明。

MySQL需要多個表,多次查詢才能搞定的問題,MongoDB只需要一個表,一次查詢就能搞定,對比完成,相對MySQL而言,MongoDB顯得更勝一籌,至少本例如此。

相關焦點

  • 為什麼Mongodb索引用B樹,而MySQL用B+樹?
    B樹和B+樹開頭,我們先回憶一下,B樹和B+樹的結構以及特點,如下所示:B樹注意一下B樹的兩個明顯特點B+樹確實,這麼設計是可以的,我沒說不行。只是不符合非關係型資料庫的設計初衷。在MongoDB中,根本不推薦這麼設計。雖然,Mongodb中有一個$lookup操作,可以做join查詢。但是理想情況下,這個$lookup操作應該不會經常使用,如果你需要經常使用它,那麼你就使用了錯誤的數據存儲了(資料庫):如果你有相關聯的數據,應該使用關係型資料庫(SQL)。
  • OpenResty、PHP-fpm與NodeJs操作MySQL的性能對比
    agentzh:我剛才在對比測試大結果集查詢時,發現NodeJS在使用 node-mysql庫訪問MySQL時,上下文切換次數居高不下,都快趕上 php-fpm + php-mysql了。但Node只起了一個進程,而且 strace 確認了確實是非阻塞的(不像 node-mysql-libmysqlclient 和 node-db-mysql 那樣濫用 OS 線程池玩阻塞通信),很是奇怪
  • MongoDB 如何上手和避坑?
    簡單說一下問題提到的幾個資料庫中,mongodb優勢的地方。vs hbase:hbase是基於row key存儲寬列的一款nosql,乍一看結構類似mongodb的_id主鍵和可變長的列數量。具體的原理和區別這裡不展開。
  • MongoDB 常見問題:MongoDB診斷
    在[MongoDB Cloud Manager](https://www.mongodb.com/cloud/cloud-manager/?jmp=docs)和 [在MongoDB的企業提供先進的內部部署解決方案的Ops Manager](https://www.mongodb.com/products/mongodb-enterprise-advanced?
  • MySQL資料庫實例管理器命令行選項詳解
    MySQL實例管理器支持許多命令行選項。/mysqlmanager --help命令可以簡單列出。有下面的選項: 顯示幫助消息並退出。 綁定地址用於連接。Instance Manager將嘗試連接每個監視的實例來檢查它們是否是活動的/沒有掛起。出現故障,IM將重啟幾次(實際上是多次)實例。可以用nonguarded選項為特定實例禁用該行為。如果未給定任何值, 默認使用20秒。 編寫passwd文件並退出。 從該文件中尋找Instance Manager用戶和密碼。
  • mongoHelper 0.3.9 發布,spring-data-mongodb 增強工具包
    mongoHelper 是基於 spring-data-mongodb 的增強工具包,簡化 CRUD 操作,提供類 jpa 的資料庫操作。
  • Node.js 學習資料和教程(值得收藏)
    Node.js C++ addon編寫實戰系列熱門node.js模塊排行榜,方便找出你想要的模塊nodejs多線程,真正的非阻塞淺析nodejs的buffer類利用libuv編寫異步多線程的addon實例
  • 代碼 | Spark讀取mongoDB數據寫入Hive普通表和分區表
    ", "mongodb://127.0.0.1:27017/test.mgtest")                .enableHiveSupport()                .getOrCreate();        JavaSparkContext sc = new JavaSparkContext(spark.sparkContext());
  • MySQL數據克隆的用戶權限設計
    6)數據補丁合併,基於業務邏輯的數據操作和數據補丁整理整個實現的過程有很多考慮的細節,不過還是在設計和實現中由同事和我一併解決了。到了交付的時機了,我們想到還有一個關鍵的地方需要補充,那就是資料庫和用戶的權限關聯,也就意味著每個人可以看到和使用的資料庫應該是不大一樣的,因為做一些權限隔離,所以接下來我會說說數據克隆方向的用戶權限設計。
  • MongoDB 不得不知的 12 個知識點
    《MongoDB應用設計模式》關於MongoDB設計適用的書,非常短,值得一看。2. MongoDB中文社區有部分官方文檔的翻譯。3. MongoDB中文社區的公眾號及博客,雲棲社區MongoDB板塊2、MongoDB用在什麼樣的場景合適?
  • php mysql PDO 查詢操作的實例詳解
    http://www.jb51.net/article/124388.htm這篇文章主要介紹了php mysql PDO
  • 實例,PHP+MySql 實現簡單的分頁功能
    1、mysql limit 用法SELECT * FROM table limit [offset,] count;參數:(1)開始位置計算方法:(頁數-1) x 每頁顯示個數(2)limit語句:limit 開始位置,每頁顯示個數3、實現代碼上述代碼使用 mysqli函數連接資料庫和查詢數據。
  • CUBRID和MySQL使用SSD前後性能測試對比
    使用CUBRID的公司可以得到更好的性能,高可靠性,靈活性,擴展性和高可用性,為其重要客戶提供7*24小時的持續服務」  CUBRID被韓國IT業的領頭企業NHN公司大量的使用,該公司部署了超過一萬臺CUBRID伺服器,看來它的確和MySQL有得一比,本文主要測試兩者的性能,我們同時在HDD硬碟和SSD硬碟上完成了測試,為了保證公平,每個資料庫(CUBRID和MySQL)都安裝在兩臺伺服器上
  • MongoDB安裝筆記
    介紹1.1 介紹MongoDB是一個文檔資料庫引擎,文檔資料庫和MySQL這種關係型資料庫是不一樣的設計,文檔資料庫和Redis這種Key-Value資料庫也有很大差別。不過文檔資料庫和Key-Value資料庫都屬於NoSQL型的資料庫,也就是說MongoDB也是不支持SQL語句的。
  • Oppo百萬級高並發mongodb集群性能數十倍提升優化實踐
    一個連結一個線程,該線程除了負責網絡收發外,還負責寫數據到存儲引擎,整個網絡I/O處理和磁碟I/O處理都由同一個線程負責,本身架構設計就是一個缺陷。此外,加上serviceExecutor: adaptive配置後,藉助boost:asio網絡模塊實現網絡IO復用,同時實現網絡IO和磁碟IO分離。這樣高並發情況下,通過網絡連結IO復用和mongodb的鎖操作來控制磁碟IO訪問線程數,最終降低了大量線程創建和消耗帶來的高系統負載,最終通過該方式提升高並發讀寫性能。
  • 不容忽視:MongoDB的JavaScript性能
    【IT168 技術】mongodb使用javascript做shell, mongodb的db.eval可以提供給數據驅動與這種javascript shell類似的js接口。
  • SpringBoot+Vue完整的外賣系統,手機端和後臺管理,可以玩一下!
    一個完整的外賣系統,包括手機端,後臺管理,api基於spring boot和vue的前後端分離的外賣系統包含完整的手機端,後臺管理功能本項目主要供交流學習,不建議商用。技術選型核心框架:Spring Boot資料庫層:Spring data jpa/Spring data mongodb資料庫連接池:Druid緩存:Ehcache前端:Vue.js資料庫:mysql5.5以上,Mongodb4.0(不要使用最新版4.2)模塊flash-waimai-mobile 手機端站點flash-waimai-manage後臺管理系統flash-waimai-api
  • 一文詳解MySQL權限
    資料庫級別的權限,作用於某個指定的資料庫上或者所有的資料庫上資料庫對象級別的權限,作用於指定的資料庫對象上(表、視圖等)或 者所有的資料庫對象上權限存儲在mysql庫的user, db, tables_priv, columns_priv, and procs_priv這幾個系統表中,待MySQL實例啟動後就加載到內存中MySQL權限級別介紹
  • MySQL innochecksum 工具
    MySQL innochecksum 工具主要用於MySQL innodb表空間文件的校驗,通過讀取表空間文件,計算頁的checksum值,將計算的結果與頁內存儲的checksum值進行對比,檢查對比結果是否一致,如果不一致,說明文件頁可能發生了損壞,innochecksum工具同時提供了checksum校驗值修復功能,能夠將頁checksum值不正確的頁進行修復。