1、PostgreSQL

　　PostgreSQL聽起來比較陌生，其實這種關系數(shù)據(jù)庫解決方案自1997年以來一直存在，并且是Ruby，Python，Go等社區(qū)中的首選。

　　將PostgreSQL作為下一個項目的數(shù)據(jù)庫解決方案，您絕不會失望（國內(nèi)郵儲銀行開始全面使用PostgreSQL作為oracle的替代品。市面上已經(jīng)有大量不錯的SQL客戶端可用于連接到PostgreSQL數(shù)據(jù)庫進行管理和開發(fā)。

　　與其他關系數(shù)據(jù)庫（特別是MySQL）相比，PostgreSQL具有一些引人入勝的功能，例如：

　　數(shù)組，Range(范圍)，UUID，地理位置等的內(nèi)置數(shù)據(jù)類型。

　　支持文檔存儲（JSON樣式），XML以及key-value存儲（Hstore）。

　　引入了使用其它程序語言編寫函數(shù)的能力，可在PL，Perl，Python等中編寫腳本

　　全文搜索

　　何時使用PostgreSQL

　　如果您正在開始一個新項目，之前被MySQL事務鎖定打敗過，那么現(xiàn)在是考慮PostgreSQL的好時機。

　　如果需要部分NoSQL功能用于混合數(shù)據(jù)模型，則PostgreSQL也具有明顯的優(yōu)勢。由于天然支持文檔和key-value存儲，因此您無需去尋找，安裝，學習和維護另一個數(shù)據(jù)庫解決方案。

　　2、MariaDBMariaDB

　　是由開發(fā)MySQL的同一人創(chuàng)建的，以替代MySQL。奇怪不？在2010年MySQL被甲骨文接管之后（通過收購Sun Microsystems，這也是甲骨文控制Java的方式），MySQL的追隨者們開始了一個新的開源項目MariaDB。

　　MariaDB是使用與MySQL相同的代碼庫創(chuàng)建。顯而易見，MariaDB可以用作MySQL的完全替代品。從MySQL遷移到MariaDB基本上做到零成本。不過切記，從MariaDB返回MySQL是不可能的，這可能導致永久性數(shù)據(jù)損壞！

　　盡管MariaDB本質(zhì)上是MySQL的克隆，但事實上并非如此。兩者之間的差異一直在增長。采用MariaDB必須是您經(jīng)過深思熟慮的決定。MariaDB中有很多新特性：

　　真正的自由和開放：由于沒有單個公司實體控制MariaDB，無需擔心突然而來的掠奪性許可。滿足特定需求的存儲引擎。例如，用于分布式事務的Spider引擎；

　　ColumnStore用于海量數(shù)據(jù)倉庫；ColumnStore引擎，用于并行，分布式存儲；與MySQL相比，速度有所提高，尤其是Aria存儲引擎可處理復雜的查詢。

　　更好的復制功能（多源復制）

　　JSON數(shù)據(jù)格式支持

　　虛擬列。對表的每一行都可以有一個“虛擬列”，該列可以用于保存一個對象的不同屬性，每個屬性在各行之間可以完全不同，“虛擬列”的個數(shù)和內(nèi)容完全有應用程序來控制和解釋。

　　動態(tài)列。動態(tài)列允許在一個表中每個行可以存儲不同的列的集合。

　　何時使用MariaDB

　　如果您想真正地替代MySQL，希望保持創(chuàng)新并且不打算再次返回MySQL，則應該使用MariaDB。例如可以在MariaDB中使用新的存儲引擎來補充項目中現(xiàn)有的關系數(shù)據(jù)模型。

　　3、CockroachDB

　　CockroachDB背后的團隊似乎由受虐狂組成。有了這樣的產(chǎn)品名稱"蟑螂"。

　　估計“蟑螂”的邏輯是無論發(fā)生什么事蟑螂都能生存繁殖。CockroachDB背后的團隊（由前Google工程師組成）在使用傳統(tǒng)SQL解決方案時感到局限性。因為從歷史上看，SQL解決方案應該托管在一臺機器上（數(shù)據(jù)不是那么大）。長期以來，沒有運行SQL的數(shù)據(jù)庫集群。即使MySQL，PostgreSQL和MariaDB中使用各種復制技術來實現(xiàn)數(shù)據(jù)庫集群。事實上，通過復制功能來實現(xiàn)集群，使用起來還是復雜。

　　CoackroachDB希望改變這一點，為SQL世界帶來輕松的分片，集群和高可用性。

　　何時使用CockroachDB

　　如果您一直使用SQL并且對MongoDB的擴展功能有所了解，那么您會喜歡CockroachDB。CockroachDB可以快速設置集群，對集群進行查詢，我們終于不需要使用數(shù)據(jù)庫中間件這種臨時產(chǎn)物來實現(xiàn)集群數(shù)據(jù)庫了。

　　4、Neo4j

　　近十年來最重要的發(fā)展之一就是關聯(lián)數(shù)據(jù)。幾乎事物都相互關聯(lián)。社交網(wǎng)絡是一個很好的例子。使用SQL乃至文檔數(shù)據(jù)庫構建類似的數(shù)據(jù)模型就是一場噩夢。這些解決方案的理想數(shù)據(jù)結(jié)構是圖形，它是完全不同的結(jié)構。您可以考慮Neo4j這樣的圖形數(shù)據(jù)庫。

　　圖形數(shù)據(jù)庫本身是獨特的，Neo4j幾乎是使用圖形唯一選擇。它具有的任何功能都是獨一無二的。

　　支持事務應用程序和圖形分析。

　　數(shù)據(jù)轉(zhuǎn)換能力，可將大型表格數(shù)據(jù)提取為圖形。

　　用于查詢圖形數(shù)據(jù)庫的專用查詢語言（Cypher）

　　可視化和發(fā)現(xiàn)功能

　　如果您需要數(shù)據(jù)之間基于圖形的關系，則需要Neo4j。

　　5、MongoDB

　　MongoDB是第一個在技術行業(yè)引起轟動的非關系數(shù)據(jù)庫，并且占據(jù)相當大的關注份額。

　　與關系數(shù)據(jù)庫不同，MongoDB是一個“文檔數(shù)據(jù)庫”，這意味著它以大塊形式存儲數(shù)據(jù)，而相關數(shù)據(jù)聚集在同一塊中。MongoDB具有一些獨特的功能，這些功能使您再也不想使用關系數(shù)據(jù)庫：

　　適用于特殊/不可預測靈活模式。

　　簡單的分片和聚類。您只需要為集群設置配置。

　　從集群中添加或刪除節(jié)點非常簡單。

　　分布式事務鎖。早期版本中缺少此功能，最終已經(jīng)包含。

　　它針對寫入進行了優(yōu)化，使其非常適合作為緩存系統(tǒng)的分析數(shù)據(jù)。

　　何時使用MongoDB

　　MongoDB是結(jié)構化SQL到無序NoSQL的橋梁。您真正需要擴展時。是的，您可以使用云SQL服務來解決數(shù)據(jù)庫擴展問題，最后，有些場景用基于SQL的解決方案根本做不到。例如，如果您正在創(chuàng)建一個像Canva這樣的產(chǎn)品，用戶可以在其中創(chuàng)建任意復雜的設計，并可以在以后編輯它們，如果選擇使用關系數(shù)據(jù)庫，那就呵呵了！

　　6、RethinkDB

　　顧名思義，當涉及到實時應用程序時，RethinkDB會 “重新考慮”數(shù)據(jù)庫的思想和功能。

　　數(shù)據(jù)庫更新后，應用程序?qū)o法及時感知。公認的方法是應用程序在有更新時立即發(fā)出通知，該更新通過復雜的網(wǎng)橋推送到前端（PHP-> Redis-> Node-> Socket.io是一個示例）。但是，如果可以將更新直接從數(shù)據(jù)庫推送到前端怎么辦？是的，這就是RethinkDB的承諾。

　　因此，如果您要制作一個真正的實時應用程序（游戲，市場，分析等），Rethink DB值得一看。

　　7、redis

　　提起數(shù)據(jù)庫，很容易忽略Redis。這是因為Redis是一個內(nèi)存數(shù)據(jù)庫，主要用于緩存等支持功能。

　　Redis是一個簡單的K-V存儲，存儲的是帶有到期時間的字符串（當然，可以設置為無窮大）。Redis喪失了部分實用性，獲得性能方面巨大提升。由于它完全位于RAM中，因此讀寫速度非常快（每秒數(shù)十萬次操作并非聞所未聞）。Redis具有完善的pub-sub系統(tǒng)，該系統(tǒng)使該“數(shù)據(jù)庫”的吸引力提高了N倍。

　　如果您有一個可以從緩存中受益或具有一些分布式組件的項目，則Redis是首選。

　　8、SQLite

　　SQLite是一個輕量級的C庫，提供了一個關系數(shù)據(jù)庫存儲引擎。該數(shù)據(jù)庫中的所有內(nèi)容都保存在一個文件中（擴展名為.sqlite），您可以將其放在文件系統(tǒng)中的任何位置。這就是使用它所需要的全部！是的，無需安裝任何“服務器”軟件，也沒有要連接的任何服務。

　　即使SQLite是MySQL之類的數(shù)據(jù)庫的輕量級替代品，它也帶來了很大的沖擊。其令人震驚的功能包括：

　　通過COMMIT，ROLLBACK和BEGIN完全支持事務。

　　每張表格支持32,000列

　　JSON支持

　　64路JOIN支持

　　子查詢，全文搜索等

　　最大數(shù)據(jù)庫大小為140 TB！

　　最大行大小為1 GB！

　　比文件I / O快35％

　　何時使用SQLite

　　SQLite是一個非常專業(yè)的數(shù)據(jù)庫。如果您的應用程序相對簡單，并且您不希望擁有龐大的數(shù)據(jù)庫，那么SQLite是一個不錯的選擇。對于中小型CMS應用、演示應用程序、嵌入式系統(tǒng)，值得您考慮。

　　9、Cassandra

　　Cassandra屬于所謂的“ columnar”數(shù)據(jù)庫家族。Cassandra中的存儲抽象是一列而不是一行。它將所有數(shù)據(jù)物理上存儲在磁盤的同一列上，最大程度地減少查找時間。

　　獨特的功能

　　Cassandra設計時考慮了一個特定的用例——處理寫重負載和對停機時間的零容忍。這些成為其獨特的賣點。

　　極快的寫入性能。在處理繁重的寫入負載時，Cassandra可以說是目前最快的數(shù)據(jù)庫。

　　線性可伸縮性。也就是說，您可以繼續(xù)向群集中添加任意數(shù)量的節(jié)點，群集的復雜性或脆弱性將零增加。

　　無與倫比的分區(qū)容限。也就是說，即使Cassandra群集中的多個節(jié)點出現(xiàn)故障，數(shù)據(jù)庫也可以不喪失完整性。

　　static 類型。(聲明為 static 的列只有一個值的，只存儲一份)。

　　何時使用Cassandra

　　日志記錄和分析是Cassandra的兩個最佳用例。

　　當您需要處理非常大的數(shù)據(jù)量（蘋果公司有Cassandra部署，可以處理400 PB以上的數(shù)據(jù)，而在Netflix，每天處理1萬億個請求）

　　當您需要停機時間幾乎為零（高可用性是Cassandra的標志之一）。

　　10、Timescale

　　Timescale時序數(shù)據(jù)庫是物聯(lián)網(wǎng)（IoT）需要的最好的開源數(shù)據(jù)庫之一。

　　與傳統(tǒng)數(shù)據(jù)庫的區(qū)別在于，它主要關注的是海量數(shù)據(jù)集的分析和可視化。時間序列數(shù)據(jù)庫很少會看到已有的數(shù)據(jù)的變化；比如：溫室中的傳感器發(fā)送的溫度讀數(shù)-新數(shù)據(jù)保持每秒積累，這對于分析和報告很重要。

　　Timescale DB跟同類的其他數(shù)據(jù)庫相比具有一些令人興奮的功能：

　　它建立在PostgreSQL之上（目前最好的開源關系數(shù)據(jù)庫）。

　　如果您的項目已經(jīng)在運行PostgreSQL，Timescale可以重點考慮。

　　通過熟悉的SQL語法進行查詢，從而減少了學習難度。極快的寫入速度-每秒數(shù)百萬次的插入。

　　數(shù)十億行或PB的數(shù)據(jù)，對于Timescale來說沒什么大不了的。

　　模式具有真正的靈活性-可以根據(jù)需要選擇關系模式或無模式。