SQLite、MySQL和PostgreSQL三種關(guān)系數(shù)據(jù)庫比較

2014-03-21 10:43:56來源:開源中國作者:

在這篇文章中,我們將嘗試?yán)斫庖恍┳畛S、最流行的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)的內(nèi)核區(qū)別。我們將會探索最底層的區(qū)別——特性與功能,它們?nèi)绾喂ぷ,在哪方面更出色,以幫助程序員選擇合適的RDBMS。

關(guān)系型數(shù)據(jù)庫的使用已經(jīng)有相當(dāng)長的時間了。它們變得流行起來托了管理系統(tǒng)的福,關(guān)系模型被實現(xiàn)得相當(dāng)?shù)暮,并且被證明是操作數(shù)據(jù)的好方法(特別是事務(wù)性強的應(yīng)用)。

在這篇DigitalOcean文章中,我們將嘗試?yán)斫庖恍┳畛S谩⒆盍餍械年P(guān)系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)的內(nèi)核區(qū)別。我們將會探索最底層的區(qū)別——特性與功能,它們?nèi)绾喂ぷ,在哪方面更出色,以幫助程序員選擇合適的RDBMS。 

條目表

1. 數(shù)據(jù)庫管理系統(tǒng)

  1. 關(guān)系型數(shù)據(jù)庫管理系統(tǒng)

  2. 關(guān)系與數(shù)據(jù)類型

  3. 重要的和流行的關(guān)系型數(shù)據(jù)庫

2. SQLite

  1. SQLite支持的數(shù)據(jù)類型

  2. SQLite的優(yōu)勢

  3. SQLite的劣勢

  4. 何時使用SQLite

  5. 何時不用SQLite

3. MySQL

  1. MySQL支持的數(shù)據(jù)類型

  2. MySQL的優(yōu)勢

  3. MySQL的劣勢

  4. 何時使用MySQL

  5. 何時不用MySQL

3. PostgreSQL

  1. PostgreSQL支持的數(shù)據(jù)類型

  2. PostgreSQL的優(yōu)勢

  3. PostgreSQL的劣勢

  4. 何時使用PostgreSQL

  5. 何時不用PostgreSQL

數(shù)據(jù)庫管理系統(tǒng)

數(shù)據(jù)庫是有組織地存儲模型數(shù)據(jù)的空間,存儲各種類型的信息(數(shù)據(jù))。每個數(shù)據(jù)庫,除了無模式型的,都有一個模型,提供數(shù)據(jù)的結(jié)構(gòu)描述。數(shù)據(jù)庫管理系統(tǒng)是管理數(shù)據(jù)庫結(jié)構(gòu)、大小和排序的應(yīng)用(或庫)。

注: 更多有關(guān)數(shù)據(jù)庫管理系統(tǒng)的內(nèi)容,請看我們的文章:理解數(shù)據(jù)庫。

關(guān)系型數(shù)據(jù)庫管理系統(tǒng)

關(guān)系型數(shù)據(jù)庫系統(tǒng)實現(xiàn)了關(guān)系模型,并用它來處理數(shù)據(jù)。關(guān)系模型在表中將信息與字段關(guān)聯(lián)起來(也就是schemas),從而存儲數(shù)據(jù)。

這種數(shù)據(jù)庫管理系統(tǒng)需要結(jié)構(gòu)(例如表)在存儲數(shù)據(jù)之前被定義出來。有了表,每一列(字段)都存儲一個不同類型(數(shù)據(jù)類型)的信息。數(shù)據(jù)庫中的每個記錄,都有自己唯一的key,作為屬于某一表的一行,行中的每一個信息都對應(yīng)了表中的一列——所有的關(guān)系一起,構(gòu)成了關(guān)系模型。

關(guān)系和數(shù)據(jù)類型

關(guān)系可以被看做是包含一系列共同表示被保持?jǐn)?shù)據(jù)庫以及相關(guān)信息的屬性的數(shù)學(xué)集合. 這種類型的識別和采集方法可以讓關(guān)系型數(shù)據(jù)庫以它們自己的方式運作.

在定義一個可以向其中插入數(shù)據(jù)的表時,每一個形成一條記錄的元素(例如: 屬性)都必須同定義的數(shù)據(jù)類型相匹配(例如:一個integer, 一個date 等等.). 不同的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)實現(xiàn)了不同的數(shù)據(jù)類型 -- 它們不總是能直接互相轉(zhuǎn)換的.

與限制的協(xié)作,就像我們之前已經(jīng)介紹過的,在關(guān)系數(shù)據(jù)庫的使用中是很普遍的。事實上,限制形成了關(guān)系的核心.

注意: 如果你需要實際上沒有關(guān)系的,隨機的數(shù)據(jù)(例如一份文檔),你也許會對使用NoSQL感興趣 (無模式數(shù)據(jù)庫). 如果你想對它們有更多了解,看看我們的文章 數(shù)據(jù)庫管理系統(tǒng)的比較吧.

重要和流行的關(guān)系型數(shù)據(jù)庫

本文中,我們將會介紹三種主要而且重要的開源關(guān)系型數(shù)據(jù)庫管理系統(tǒng),是他們影響了應(yīng)用開發(fā)世界。

  • SQLite:

一個強大的嵌入式關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。

  • MySQL:

最流行的RDBMS。

  • PostgreSQL:

最先進(jìn)SQL型開源objective-RDBMS。

注: 開源應(yīng)用總是可以自由使用的。大多數(shù)時候,復(fù)制工程(利用代碼)創(chuàng)建新應(yīng)用也是被允許的。如果你對DBMS感興趣,你可以看看一些基于這些工程的分支項目,例如MariaDB。

SQLite

SQLite是非凡的數(shù)據(jù)庫,他可以進(jìn)程在使用它的應(yīng)用中。作為一個自包含、基于文件的數(shù)據(jù)庫,SQLite提供了出色的工具集,可以處理所有類型的數(shù)據(jù),沒有什么限制,而且比起服務(wù)器運行的進(jìn)程型服務(wù)器使用起來輕松許多。

一個應(yīng)用使用SQLite時,它的功能直接被集成在其中,應(yīng)用會直接訪問包含數(shù)據(jù)的文件(即SQLite數(shù)據(jù)庫),而不是通過一些端口(port, socket)來交互。感謝這種底層技術(shù),這使SQLite變得非?焖俸透咝,并且十分強大。

SQLite支持的數(shù)據(jù)類型

  • NULL:

NULL值。

  • INTEGER:

有符號整數(shù),按照設(shè)置用1、2、3、4、6或8字節(jié)存儲。

  • REAL:

浮點數(shù),使用8字節(jié)IEEE浮點數(shù)方式存儲。

  • TEXT:

文本字符串,使用數(shù)據(jù)庫編碼存儲(UTF-8, UTF-16BE 或 UTF-16LE)。

  • BLOB:

二進(jìn)制大對象,怎么輸入就怎么存儲。

注: 想了解更多有關(guān)SQLite數(shù)據(jù)類型的信息,可以查看這一主題的 官方文檔 

SQLite 的優(yōu)點

  • 基于文件:

整個數(shù)據(jù)庫都包含在磁盤上的一個文件中,因此它有很好的遷移性。

  • 標(biāo)準(zhǔn)化:

盡管它看起來像個“簡化版”的數(shù)據(jù)庫,SQLite 確實支持 SQL。它略去了一些功能(RIGHT OUTER JOIN 和 FOR EACH STATEMENT),但是,又同時增加了一些其他功能。

  • 對開發(fā)乃至測試都很棒:

在絕大多數(shù)應(yīng)用的開發(fā)階段中,大部分人都非常需要解決方案能有并發(fā)的靈活性。SQLite 含有豐富功能基礎(chǔ),所能提供的超乎開發(fā)所需,并且簡潔到只需一個文件和一個 C 鏈接庫。

SQLite的缺點

  • 沒有用戶管理:

高級數(shù)據(jù)庫都能支持用戶系統(tǒng),例如,能管理數(shù)據(jù)庫連接對數(shù)據(jù)庫和表的訪問權(quán)限。但由于 SQLite 產(chǎn)生的目的和本身性質(zhì)(沒有多用戶并發(fā)的高層設(shè)計),它沒有這個功能。

  • 缺乏額外優(yōu)化性能的靈活性:

仍然是從設(shè)計之初,SQLite 就不支持使用各種技巧來進(jìn)行額外的性能優(yōu)化。這個庫容易配置,容易使用。既然它并不復(fù)雜,理論上就無法讓它比現(xiàn)在更快,其實現(xiàn)在它已經(jīng)很快了。

什么時候要用 SQLite

  • 嵌入式應(yīng)用:

所有需要遷移性,不需要擴展的應(yīng)用,例如,單用戶的本地應(yīng)用,移動應(yīng)用和游戲。

  • 代替磁盤訪問:

在很多情況下,需要頻繁直接讀/寫磁盤文件的應(yīng)用,都很適合轉(zhuǎn)為使用 SQLite ,可以得益于 SQLite 使用 SQL 帶來的功能性和簡潔性。

  • 測試:

它能秒殺大部分專門針對應(yīng)用業(yè)務(wù)邏輯(也就是應(yīng)用的主要目的:能完成功能)的測試。

什么時候不要用SQLite

  • 多用戶應(yīng)用:

如果你在開發(fā)的應(yīng)用需要被多用戶訪問,而且這些用戶都用同一個數(shù)據(jù)庫,那么相比 SQLite 最好還是選擇一個功能完整的關(guān)系型數(shù)據(jù)庫(例如 MySQL)。

  • 需要大面積寫入數(shù)據(jù)的應(yīng)用:

SQLite 的缺陷之一是它的寫入操作。這個數(shù)據(jù)庫同一時間只允許一個寫操作,因此吞吐量有限。

MySQL

MySQL 在所有大型數(shù)據(jù)庫服務(wù)器中最流行的一個. 它的特性豐富,產(chǎn)品的開源性質(zhì)使得其驅(qū)動了線上大量的網(wǎng)站和應(yīng)用程序. 要入手 MySQL 相對簡單,開發(fā)人員可以在互聯(lián)網(wǎng)上面訪問到大量有關(guān)這個數(shù)據(jù)庫的信息.

注意: 由于這個產(chǎn)品的普及性,大量的第三方應(yīng)用、工具和集成庫對于操作這個RDBCMS的方方面面大有幫助.

Mysql沒有嘗試去實現(xiàn)SQL標(biāo)準(zhǔn)的全部,而是為用戶提供了很多有用的功能. 作為一個獨立的數(shù)據(jù)庫服務(wù)器,應(yīng)用程序同Mysql守護(hù)進(jìn)程的交互,告訴它去訪問數(shù)據(jù)庫自身 -- 這一點不像 SQLite.

MySQL支持的數(shù)據(jù)類型

  • TINYINT:

一個非常小的整數(shù).

  • SMALLINT:

一個小整數(shù).

  • MEDIUMINT:

一個中間大小的整數(shù).

  • INT or INTEGER:

一個正常大小的整數(shù).

  • BIGINT:

一個大的整數(shù).

  • FLOAT:

一個小的 (單精度) 浮點數(shù),不能是無符號的那種.

  • DOUBLE, DOUBLE PRECISION, REAL:

一個正常大小 (雙精度) 的浮點數(shù),不能使無符號的那種.

  • DECIMAL, NUMERIC:

沒有被包裝的浮點數(shù)。不能使無符號的那種.

  • DATE:

一個日期.

  • DATETIME:

一個日期和時間的組合.

  • TIMESTAMP:

一個時間戳.

  • TIME:

一個時間.

  • YEAR:

一個用兩位或者4位數(shù)字格式表示的年份(默認(rèn)是4位).

  • CHAR:

一個固定長度的字符串,存儲時總是在其固定長度的空間里右對齊.

  • VARCHAR:

一個可變長度的字符串.

  • TINYBLOB, TINYTEXT:

一個BLOB或者TEXT列,最大長度255 (2^8 - 1)個字符.

  • BLOB, TEXT:

一個BLOB或者TEXT列,最大長度 65535 (2^16 - 1)個字符.

  • MEDIUMBLOB, MEDIUMTEXT:

一個BLOB或者TEXT列,最大長度 16777215 (2^24 - 1)個字符.

  • LONGBLOB, LONGTEXT:

一個BLOB或者TEXT列,最大長度4294967295 (2^32 - 1) 個字符.

  • ENUM:

一個枚舉類型.

  • SET:

一個集合.

MySQL的優(yōu)點

  • 容易使用:

安裝MySQL非常容易。第三方庫,包括可視化(也就是有GUI)的庫讓上手使用數(shù)據(jù)庫非常簡單。

  • 功能豐富:

MySQL 支持大部分關(guān)系型數(shù)據(jù)庫應(yīng)該有的 SQL 功能——有些直接支持,有些間接支持。

  • 安全:

MYSQL 有很多安全特性,其中有些相當(dāng)高級。

  • 靈活而強大:

MySQL 能處理很多數(shù)據(jù),此外如有需要,它還能“適應(yīng)”各種規(guī)模的數(shù)據(jù)。

  • 快速:

放棄支持某些標(biāo)準(zhǔn),讓 MySQL 效率更高并能使用捷徑,因此帶來速度的提升。

MySQL的缺點

  • 已知的局限:

從設(shè)計之初,MySQL 就沒打算做到全知全能,因此它有一些功能局限,無法滿足某些頂尖水平應(yīng)用的需求。

  • 可靠性問題:

MySQL 對于某些功能的實現(xiàn)方式(例如,引用,事務(wù),數(shù)據(jù)審核等) 使得它比其他一些關(guān)系型數(shù)據(jù)庫略少了一些可靠性。

  • 開發(fā)停滯:

盡管 MySQL 理論上仍是開源產(chǎn)品,也有人抱怨它誕生之后更新緩慢。然而,應(yīng)該注意到有一些基于 MySQL 并完整集成的數(shù)據(jù)庫(如 MariaDB),在標(biāo)準(zhǔn)的 MySQL 基礎(chǔ)上帶來了額外價值。

何時使用 MySQL?

  • 分布式操作:

當(dāng)你需要的比SQLite可以提供的更多時,把MySQL包括進(jìn)你的部署棧,就像任何一個獨立的數(shù)據(jù)庫服務(wù)器,會帶來大量的操作自由和一些先進(jìn)的功能。

  • 高安全性:

MySQL的安全功能,用一種簡單的方式為數(shù)據(jù)訪問(和使用)提供了可靠的保護(hù)。

  • Web網(wǎng)站 和 Web應(yīng)用:

絕大多數(shù)的網(wǎng)站(和Web應(yīng)用程序)可以忽視約束性地簡單工作在MySQL上。這種靈活的和可擴展的工具是易于使用和易于管理的——這被證明非常有助于長期運行。

  • 定制解決方案:

如果你工作在一個高度量身定制的解決方案上,MySQL能夠很容易地尾隨和執(zhí)行你的規(guī)則,這要感謝其豐富的配置設(shè)置和操作模式。

何時不用 MySQL?

  • SQL 服從性:

因為 MySQL 沒有[想要]實現(xiàn) SQL 的全部標(biāo)準(zhǔn),所以這個工具不完全符合SQL。如果你需要對這樣的關(guān)系數(shù)據(jù)庫管理系統(tǒng)進(jìn)行整合,從MySQL進(jìn)行切換是不容易的。

  • 并發(fā):

即使MySQL和一些存儲引擎能夠真地很好執(zhí)行讀取操作,但并發(fā)讀寫還是有問題的。

  • 缺乏特色:

再次提及,根據(jù)數(shù)據(jù)庫引擎的選擇標(biāo)準(zhǔn),MySQL會缺乏一定的特性,如全文搜索。

PostgreSQL

PostgreSQL 是一個先進(jìn)的,開放源代碼的[對象]-關(guān)系型數(shù)據(jù)庫管理系統(tǒng),它的主要目標(biāo)是實現(xiàn)標(biāo)準(zhǔn)和可擴展性. PostgreSQL, 或者說是 Postgres, 試圖把對 ANSI/ISO SQL標(biāo)準(zhǔn)的采用與修正結(jié)合起來.

對比其他的RDBMS, PostgreSQL以它對于對象-關(guān)系和\或關(guān)系型數(shù)據(jù)庫功能,比如對于可靠事務(wù),例如原子性,一致性,隔離性和持久性(ACID)的完全支持,這些東西的高度需求和集合的支持,以示其獨特性.

由于強大的底層技術(shù), Postgres對于高效的完成許多處理任務(wù)很有一手. 得益于其多版本并發(fā)控制 (MVCC)的實現(xiàn),在沒有讀取鎖的前提下也能達(dá)成并發(fā), 這也同樣確保了ACID的實施.

PostgreSQL是高度可編程的, 因而可以使用被稱作“存儲過程”的自定義程序進(jìn)行擴展. 這些功能可以被創(chuàng)建用來簡化一個寫重復(fù)、復(fù)雜并且常常需要數(shù)據(jù)庫操作的任務(wù)的執(zhí)行.

雖然特性強大,但這個 DBMS并沒有MySQL那么流行, 可還是有許多迷人的第三方工具和庫被設(shè)計出來用于使得對PostgreSQL的操作簡化. 如今通過許多操作系統(tǒng)默認(rèn)的包管理器輕松的獲取PostgreSQL已成為可能.

PostgreSQL支持的數(shù)據(jù)類型

  • bigint:

有符號的八位整數(shù)

  • bigserial:

自增長的八位整數(shù)

  • bit [(n)]:

固定長度的位串

  • bit varying [(n)]:

可變長度的位串

  • boolean:

邏輯布爾值(true/false)

  • box:

在一個平面上的矩形框

  • bytea:

二進(jìn)制數(shù)據(jù)("位數(shù)組")

  • character varying [(n)]:

可變長度的字符串

  • character [(n)]:

固定長度的字符串

  • cidr:

IPv4 或者 IPv6 網(wǎng)絡(luò)地址

  • circle:

平面上的一個圓

  • date:

日歷日期 ( 年月日)

  • double precision:

雙精度浮點數(shù)(8位)

  • inet:

IPv4 或者 IPv6 主機地址

  • integer:

有符號的四位整數(shù)

  • interval [fields] [(p)]:

時間跨度

  • line:

平面上的一個無限長的直線

  • lseg:

平面上的一個線段

  • macaddr:

MAC (媒體訪問控制)地址

  • money:

貨幣金額

  • numeric [(p, s)]:

可選精度的精確數(shù)字

  • path:

一個平面上的幾何路徑

  • point:

一個平面上的幾何點

  • polygon:

一個平面上的閉合的幾何路徑

  • real:

單精度浮點數(shù)(4 位)

  • smallint:有符號的兩位整數(shù)

  • serial:

自增長4位整數(shù)

  • text:

可變長度字符創(chuàng)

  • time [(p)] [without time zone]:

一天中的時間(無時區(qū))

  • time [(p)] with time zone:

一天中的時間,包含時區(qū)

  • timestamp [(p)] [without time zone]:

日期和時間(沒有時區(qū))

  • timestamp [(p)] with time zone:

日期和時間,包含時區(qū)

  • tsquery:

文本搜索查詢

  • tsvector:

文本搜索文檔

  • txid_snapshot:

用戶級事務(wù)ID快照

  • uuid:

通用的唯一標(biāo)識符

  • xml:

XML 數(shù)據(jù)

PostgreSQL的優(yōu)點

  • 標(biāo)準(zhǔn)支持 SQL 的開源關(guān)系型數(shù)據(jù)庫:

PostgreSQL 是一個開源的,免費的,同時非常強大的關(guān)系型數(shù)據(jù)管理系統(tǒng)。

  • 強大的社區(qū):

PostgreSQL 背后有熱忱而經(jīng)驗豐富的社區(qū),可以通過知識庫和問答網(wǎng)站獲取支持,全天候免費。

  • 強大的第三方支持:

即使其本身功能十分強大,PostgreSQL 仍附帶有許多強大的開源第三方工具來輔助系統(tǒng)的設(shè)計、管理和使用。

  • 可擴展性:

可以用預(yù)先存儲的流程來程序性擴展 PostgreSQL ,一個高級的關(guān)系型數(shù)據(jù)庫理應(yīng)如此。

  • 面向?qū)ο?

PostgreSQL 不只是一個關(guān)系型數(shù)據(jù)庫,還是一個面向?qū)ο髷?shù)據(jù)庫——支持嵌套,及一些其他功能。

PostgreSQL的缺點:

  • 性能:

對于簡單而繁重的讀取操作, 超過了 PostgreSQL 的殺傷力,可能會出現(xiàn)比同行(如MySQL)更低的性能。

  • 普及:

按給出的該工具的性質(zhì),從普及度來說它還缺乏足夠后臺支撐,盡管有大量的部署——這可能會影響能夠獲得支持的容易程度。

  • 托管:

由于上述因素的影響,要讓主機或服務(wù)提供商提出使用PostgreSQL實例是很難的。

何時使用PostgreSQL?

  • 數(shù)據(jù)完整性:

    當(dāng)可靠性和數(shù)據(jù)完整性是絕對必要而無需理由時,PostgreSQL是更好的選擇。

  • 復(fù)雜的自定義過程:

    如果你需要你的數(shù)據(jù)庫執(zhí)行自定義過程,可擴展的PostgreSQL是更好的選擇。

  • 整合:

    在將來,如果可能要把整個數(shù)據(jù)庫系統(tǒng)遷移到另一個適當(dāng)?shù)慕鉀Q方案(例如Oracle)中,PostgreSQL對于這種切換將是最兼容和易于操作的。

  • 復(fù)雜的設(shè)計:

相比其他的開源和免費的 RDBMS(關(guān)系數(shù)據(jù)庫管理系統(tǒng))實現(xiàn)來說,對于復(fù)雜的數(shù)據(jù)庫設(shè)計,PostgreSQL提供了大部分的功能和可能性,同時并沒放棄其他有價值的地方。

何時不用 PostgreSQL?

  • 速度:

如果你需要的只是快速的讀取操作, PostgreSQL 不是為此而準(zhǔn)備的工具。

  • 簡化體制:

除非你需要絕對的數(shù)據(jù)完整性,原子性,一致性,隔離性,耐久性,或復(fù)雜的設(shè)計,PostgreSQL 對簡化體制來說是殺手。

  • 復(fù)制:

除非你愿意花不少時間,精力和資源,否則對于那些缺乏數(shù)據(jù)庫和系統(tǒng)管理經(jīng)驗的人來說,實現(xiàn)與MySQL的(主從)復(fù)制可能不容易。

原文:https://www.digitalocean.com/community/articles/sqlite-vs-mysql-vs-postgresql-a-comparison-of-relational-database-management-systems

贊助商鏈接: