SQLite、MySQL和PostgreSQL 三种关系数据库比较
關系型數據庫的使用已經有相當長的時間了。它們變得流行起來托了管理系統的福,關系模型被實現得相當的好,并且被證明是操作數據的好方法(特別是事務性強的應用)。
在這篇DigitalOcean文章中,我們將嘗試理解一些最常用、最流行的關系型數據庫管理系統(RDBMS)的內核區別。我們將會探索最底層的區別——特性與功能,它們如何工作,在哪方面更出色,以幫助程序員選擇合適的RDBMS。
目錄:
一、數據庫管理系統
1、關系型數據庫管理系統
2、關系與數據類型
3、重要的和流行的關系型數據庫
二、SQLite
1、SQLite支持的數據類型
2、SQLite的優勢
3、SQLite的劣勢
4、何時使用SQLite
5、何時不用SQLite
三、MySQL
1、MySQL支持的數據類型
2、MySQL的優勢
3、MySQL的劣勢
4、何時使用MySQL
5、何時不用MySQL
四、PostgreSQL
1、PostgreSQL支持的數據類型
2、PostgreSQL的優勢
3、PostgreSQL的劣勢
4、何時使用PostgreSQL
5、何時不用PostgreSQL
?
一、數據庫管理系統
數據庫是有組織地存儲模型數據的空間,存儲各種類型的信息(數據)。每個數據庫,除了無模式型的,都有一個模型,提供數據的結構描述。數據庫管理系統是管理數據庫結構、大小和排序的應用(或庫)。
1、關系型數據庫管理系統
關系型數據庫系統實現了關系模型,并用它來處理數據。關系模型在表中將信息與字段關聯起來(也就是schemas),從而存儲數據。
這種數據庫管理系統需要結構(例如表)在存儲數據之前被定義出來。有了表,每一列(字段)都存儲一個不同類型(數據類型)的信息。數據庫中的每個記錄,都有自己唯一的key,作為屬于某一表的一行,行中的每一個信息都對應了表中的一列——所有的關系一起,構成了關系模型。
2、關系和數據類型
關系可以被看做是包含一系列共同表示被保持數據庫以及相關信息的屬性的數學集合. 這種類型的識別和采集方法可以讓關系型數據庫以它們自己的方式運作.
在定義一個可以向其中插入數據的表時,每一個形成一條記錄的元素(例如: 屬性)都必須同定義的數據類型相匹配(例如:一個integer, 一個date 等等.). 不同的關系型數據庫管理系統實現了不同的數據類型 -- 它們不總是能直接互相轉換的.
與限制的協作,就像我們之前已經介紹過的,在關系數據庫的使用中是很普遍的。事實上,限制形成了關系的核心.
3、重要和流行的關系型數據庫
本文中,我們將會介紹三種主要而且重要的開源關系型數據庫管理系統,是他們影響了應用開發世界。
| SQLite | 一個強大的嵌入式關系型數據庫管理系統 |
| MySQL | 最流行的RDBMS |
| PostgreSQL | 最先進SQL型開源objective-RDBMS |
?
注: 開源應用總是可以自由使用的。大多數時候,復制工程(利用代碼)創建新應用也是被允許的。如果你對DBMS感興趣,你可以看看一些基于這些工程的分支項目,例如MariaDB。
?
二、SQLite
SQLite是非凡的數據庫,他可以進程在使用它的應用中。作為一個自包含、基于文件的數據庫,SQLite提供了出色的工具集,可以處理所有類型的數據,沒有什么限制,而且比起服務器運行的進程型服務器使用起來輕松許多。
一個應用使用SQLite時,它的功能直接被集成在其中,應用會直接訪問包含數據的文件(即SQLite數據庫),而不是通過一些端口(port, socket)來交互。感謝這種底層技術,這使SQLite變得非常快速和高效,并且十分強大。
1、SQLite支持的數據類型
| NULL | NULL值 |
| INTEGER | 有符號整數,按照設置用1、2、3、4、6或8字節存儲 |
| REAL | 浮點數,使用8字節IEEE浮點數方式存儲 |
| TEXT | 文本字符串,使用數據庫編碼存儲(UTF-8, UTF-16BE 或 UTF-16LE) |
| BLOB | 二進制大對象,怎么輸入就怎么存儲 |
?
2、SQLite 的優點
| 基于文件 | 整個數據庫都包含在磁盤上的一個文件中,因此它有很好的遷移性 |
| 標準化 | 盡管它看起來像個“簡化版”的數據庫,SQLite 確實支持 SQL。它略去了一些功能(RIGHT OUTER JOIN 和 FOR EACH STATEMENT),但是,又同時增加了一些其他功能 |
| 對開發乃至測試都很棒 | 在絕大多數應用的開發階段中,大部分人都非常需要解決方案能有并發的靈活性。SQLite 含有豐富功能基礎,所能提供的超乎開發所需,并且簡潔到只需一個文件和一個 C 鏈接庫 |
?
3、SQLite的缺點
| 沒有用戶管理 | 高級數據庫都能支持用戶系統,例如,能管理數據庫連接對數據庫和表的訪問權限。但由于 SQLite 產生的目的和本身性質(沒有多用戶并發的高層設計),它沒有這個功能 |
| 缺乏額外優化性能的靈活性 | 仍然是從設計之初,SQLite 就不支持使用各種技巧來進行額外的性能優化。這個庫容易配置,容易使用。既然它并不復雜,理論上就無法讓它比現在更快,其實現在它已經很快了 |
?
4、什么時候要用 SQLite
| 嵌入式應用 | 所有需要遷移性,不需要擴展的應用,例如,單用戶的本地應用,移動應用和游戲 |
| 代替磁盤訪問 | 在很多情況下,需要頻繁直接讀/寫磁盤文件的應用,都很適合轉為使用 SQLite ,可以得益于 SQLite 使用 SQL 帶來的功能性和簡潔性 |
| 測試 | 它能秒殺大部分專門針對應用業務邏輯(也就是應用的主要目的:能完成功能)的測試 |
?
5、什么時候不要用SQLite
| 多用戶應用 | 如果你在開發的應用需要被多用戶訪問,而且這些用戶都用同一個數據庫,那么相比 SQLite 最好還是選擇一個功能完整的關系型數據庫(例如 MySQL) |
| 需要大面積寫入數據的應用 | SQLite 的缺陷之一是它的寫入操作。這個數據庫同一時間只允許一個寫操作,因此吞吐量有限 |
?
?
三、MySQL
MySQL 在所有大型數據庫服務器中最流行的一個. 它的特性豐富,產品的開源性質使得其驅動了線上大量的網站和應用程序. 要入手 MySQL 相對簡單,開發人員可以在互聯網上面訪問到大量有關這個數據庫的信息.
注意: 由于這個產品的普及性,大量的第三方應用、工具和集成庫對于操作這個RDBCMS的方方面面大有幫助.
Mysql沒有嘗試去實現SQL標準的全部,而是為用戶提供了很多有用的功能. 作為一個獨立的數據庫服務器,應用程序同Mysql守護進程的交互,告訴它去訪問數據庫自身 -- 這一點不像 SQLite.
1、MySQL支持的數據類型
| TINYINT | 一個非常小的整數 |
| SMALLINT | 一個小整數 |
| MEDIUMINT | 一個中間大小的整數 |
| INT or INTEGER | 一個正常大小的整數 |
| BIGINT | 一個大的整數 |
| FLOAT | 一個小的 (單精度) 浮點數,不能是無符號的那種 |
| DOUBLE, DOUBLE PRECISION, REAL | 一個正常大小 (雙精度) 的浮點數,不能使無符號的那種 |
| DECIMAL, NUMERIC | 沒有被包裝的浮點數。不能使無符號的那種 |
| DATE | 一個日期 |
| DATETIME | 一個日期和時間的組合 |
| TIMESTAMP | 一個時間戳 |
| TIME | 一個時間 |
| YEAR | 一個用兩位或者4位數字格式表示的年份(默認是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 | 一個集合 |
?
2、MySQL的優點
| 容易使用 | 安裝MySQL非常容易。第三方庫,包括可視化(也就是有GUI)的庫讓上手使用數據庫非常簡單 |
| 功能豐富 | MySQL 支持大部分關系型數據庫應該有的 SQL 功能——有些直接支持,有些間接支持 |
| 安全 | MYSQL 有很多安全特性,其中有些相當高級 |
| 靈活而強大 | MySQL 能處理很多數據,此外如有需要,它還能“適應”各種規模的數據 |
| 快速 | 放棄支持某些標準,讓 MySQL 效率更高并能使用捷徑,因此帶來速度的提升 |
?
3、MySQL的缺點
| 已知的局限 | 從設計之初,MySQL 就沒打算做到全知全能,因此它有一些功能局限,無法滿足某些頂尖水平應用的需求 |
| 可靠性問題 | MySQL 對于某些功能的實現方式(例如,引用,事務,數據審核等) 使得它比其他一些關系型數據庫略少了一些可靠性 |
| 開發停滯 | 盡管 MySQL 理論上仍是開源產品,也有人抱怨它誕生之后更新緩慢。然而,應該注意到有一些基于 MySQL 并完整集成的數據庫(如 MariaDB),在標準的 MySQL 基礎上帶來了額外價值 |
?
4、何時使用 MySQL?
| 分布式操作 | 當你需要的比SQLite可以提供的更多時,把MySQL包括進你的部署棧,就像任何一個獨立的數據庫服務器,會帶來大量的操作自由和一些先進的功能 |
| 高安全性 | MySQL的安全功能,用一種簡單的方式為數據訪問(和使用)提供了可靠的保護 |
| Web網站 和 Web應用 | 絕大多數的網站(和Web應用程序)可以忽視約束性地簡單工作在MySQL上。這種靈活的和可擴展的工具是易于使用和易于管理的——這被證明非常有助于長期運行 |
| 定制解決方案 | 如果你工作在一個高度量身定制的解決方案上,MySQL能夠很容易地尾隨和執行你的規則,這要感謝其豐富的配置設置和操作模式 |
?
5、何時不用 MySQL?
| SQL 服從性 | 因為 MySQL 沒有[想要]實現 SQL 的全部標準,所以這個工具不完全符合SQL。如果你需要對這樣的關系數據庫管理系統進行整合,從MySQL進行切換是不容易的 |
| 并發 | 即使MySQL和一些存儲引擎能夠真地很好執行讀取操作,但并發讀寫還是有問題的 |
| 缺乏特色 | 再次提及,根據數據庫引擎的選擇標準,MySQL會缺乏一定的特性,如全文搜索 |
?
?
四、PostgreSQL
PostgreSQL 是一個先進的,開放源代碼的[對象]-關系型數據庫管理系統,它的主要目標是實現標準和可擴展性. PostgreSQL, 或者說是 Postgres, 試圖把對 ANSI/ISO SQL標準的采用與修正結合起來.
對比其他的RDBMS, PostgreSQL以它對于對象-關系和或關系型數據庫功能,比如對于可靠事務,例如原子性,一致性,隔離性和持久性(ACID)的完全支持,這些東西的高度需求和集合的支持,以示其獨特性.
由于強大的底層技術, Postgres對于高效的完成許多處理任務很有一手. 得益于其多版本并發控制 (MVCC)的實現,在沒有讀取鎖的前提下也能達成并發, 這也同樣確保了ACID的實施.
PostgreSQL是高度可編程的, 因而可以使用被稱作“存儲過程”的自定義程序進行擴展. 這些功能可以被創建用來簡化一個寫重復、復雜并且常常需要數據庫操作的任務的執行.
雖然特性強大,但這個 DBMS并沒有MySQL那么流行, 可還是有許多迷人的第三方工具和庫被設計出來用于使得對PostgreSQL的操作簡化. 如今通過許多操作系統默認的包管理器輕松的獲取PostgreSQL已成為可能.
1、PostgreSQL支持的數據類型
| bigint | 有符號的八位整數 |
| bigserial | 自增長的八位整數 |
| bit [(n)] | 固定長度的位串 |
| bit varying [(n)] | 可變長度的位串 |
| boolean | 邏輯布爾值(true/false) |
| box | 在一個平面上的矩形框 |
| bytea | 二進制數據("位數組") |
| character varying [(n)] | 可變長度的字符串 |
| character [(n)] | 固定長度的字符串 |
| cidr | IPv4 或者 IPv6 網絡地址 |
| circle | 平面上的一個圓 |
| date | 日歷日期 ( 年月日) |
| double precision | 雙精度浮點數(8位) |
| inet | IPv4 或者 IPv6 主機地址 |
| integer | 有符號的四位整數 |
| interval [fields] [(p)] | 時間跨度 |
| line | 平面上的一個無限長的直線 |
| lseg | 平面上的一個線段 |
| macaddr | MAC (媒體訪問控制)地址 |
| money | 貨幣金額 |
| numeric [(p, s)] | 可選精度的精確數字 |
| path | 一個平面上的幾何路徑 |
| point | 一個平面上的幾何點 |
| polygon | 一個平面上的閉合的幾何路徑 |
| real | 單精度浮點數(4 位) |
| smallint | 有符號的兩位整數 |
| serial | 自增長4位整數 |
| text | 可變長度字符創 |
| time [(p)] [without time zone] | 一天中的時間(無時區) |
| time [(p)] with time zone | 一天中的時間,包含時區 |
| timestamp [(p)] [without time zone] | 日期和時間(沒有時區) |
| timestamp [(p)] with time zone | 日期和時間,包含時區 |
| tsquery | 文本搜索查詢 |
| tsvector | 文本搜索文檔 |
| txid_snapshot | 用戶級事務ID快照 |
| uuid | 通用的唯一標識符 |
| xml | XML 數據 |
?
2、PostgreSQL的優點
| 標準支持 SQL 的開源關系型數據庫 | PostgreSQL 是一個開源的,免費的,同時非常強大的關系型數據管理系統 |
| 強大的社區 | PostgreSQL 背后有熱忱而經驗豐富的社區,可以通過知識庫和問答網站獲取支持,全天候免費 |
| 強大的第三方支持 | 即使其本身功能十分強大,PostgreSQL 仍附帶有許多強大的開源第三方工具來輔助系統的設計、管理和使用 |
| 可擴展性 | 可以用預先存儲的流程來程序性擴展 PostgreSQL ,一個高級的關系型數據庫理應如此 |
| 面向對象 | PostgreSQL 不只是一個關系型數據庫,還是一個面向對象數據庫——支持嵌套,及一些其他功能 |
3、PostgreSQL的缺點:
| 性能 | 對于簡單而繁重的讀取操作, 超過了 PostgreSQL 的殺傷力,可能會出現比同行(如MySQL)更低的性能 |
| 普及 | 按給出的該工具的性質,從普及度來說它還缺乏足夠后臺支撐,盡管有大量的部署——這可能會影響能夠獲得支持的容易程度 |
| 托管 | 由于上述因素的影響,要讓主機或服務提供商提出使用PostgreSQL實例是很難的 |
?
4、何時使用PostgreSQL?
| 數據完整性 | 當可靠性和數據完整性是絕對必要而無需理由時,PostgreSQL是更好的選擇 |
| 復雜的自定義過程 | 如果你需要你的數據庫執行自定義過程,可擴展的PostgreSQL是更好的選擇 |
| 整合 | 在將來,如果可能要把整個數據庫系統遷移到另一個適當的解決方案(例如Oracle)中,PostgreSQL對于這種切換將是最兼容和易于操作的 |
| 復雜的設計 | 相比其他的開源和免費的 RDBMS(關系數據庫管理系統)實現來說,對于復雜的數據庫設計,PostgreSQL提供了大部分的功能和可能性,同時并沒放棄其他有價值的地方 |
?
5、何時不用 PostgreSQL?
| 速度 | 如果你需要的只是快速的讀取操作, PostgreSQL 不是為此而準備的工具 |
| 簡化體制 | 除非你需要絕對的數據完整性,原子性,一致性,隔離性,耐久性,或復雜的設計,PostgreSQL 對簡化體制來說是殺手 |
| 復制 | 除非你愿意花不少時間,精力和資源,否則對于那些缺乏數據庫和系統管理經驗的人來說,實現與MySQL的(主從)復制可能不容易 |
?
總結
以上是生活随笔為你收集整理的SQLite、MySQL和PostgreSQL 三种关系数据库比较的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 中断处理程序与中断服务例程
- 下一篇: map和hash_map