作者：汪洋，平安集團平安科技數據庫技術部總監。迄今已從事Oracle相關開發運維工作20年。在平安負責數據庫技術引入，數據庫產品選型，數據庫架構設計，數據庫規范制定，開發、測試、生產環境運維等工作。近年，對開源數據庫技術以及DBaaS產生濃厚興趣，一直致力于相關的研究和引入工作。 責編：仲培藝，關注數據庫領域，糾錯、尋求報道或者投稿請致郵：zhongpy@csdn.net。 本文為《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2017年《程序員》

對于數據庫技術領域來講，2016無疑是飛速發展的一年，同時也是令人振奮的一年。在這一年快要過去，2017即將到來的時刻，是時候對數據庫領域進行盤點，看看都發生了什么，正在發生什么，以及即將發生什么。

隨著近幾年互聯網、大數據的快速發展和廣泛應用，數據格式趨于多樣化，數據庫引擎也如雨后春筍一般，層出不窮，多達三、四百種之多，充分證明數據庫技術的日新月異。篇幅有限，無法對每種數據庫引擎展開陳述，我們將主要聚焦在DB-Engines Ranking TOP 5引擎，它們已經可以代表當今數據庫技術的發展趨勢，況且也積極吸收來自于其他數據庫好的技術和經驗，無論從技術前瞻性還是功能實現上并不落后。

流行度比較

截止2016年到11月，在DB-Engines上排名的數據庫引擎多達310種。我們先簡單解釋其排名依據。它并非按照數據庫引擎的技術指標或者市場占有率進行排名，而是當前的流行度。而流行度的評判取決于以下6個維度：

在搜索引擎中被提及的次數（包括Google、Bing、Yandex）；公眾對該數據庫的興趣，借用了Google Trend；關于該數據庫技術討論的頻度，例如在Stack Overflow；與該數據庫相關的職位數量；在專業社交網絡中提及到該數據庫的PRofile數量，例如LinkedIn；在社交網絡中的相關性，例如Twitter中提到的數量。

從圖2中可以看出，前3名Oracle、MySQL和Microsoft SQL Server相比起其他數據庫引擎的領先優勢非常明顯，幾乎可以用望塵莫及來形容。從表格中具體的分值也可以看到差距巨大。相對其他數據庫也比較穩定，已經位于成熟期，但同時也說明成長空間有限。而PostgreSQL和MongoDB雖然和前面3個巨無霸相比仍有明顯差距，但發展勢頭卻很好，一直以來都有穩定的增長。

排名覆蓋了近4年來的走勢。如果單看頭三名，也有一些值得注意的現象。

Oracle做為老大哥，雖然一直位于第一，但分值卻處于下滑通道，和第二名MySQL的差距越來越小，極有被超越的可能，不禁讓人擔心領先的地位還能保持多久？MySQL年輕氣盛，在前3年一直比較穩定，勻速前進，但進入2016后卻突然發力，增長非常迅速。在11月的統計中，差距只有2.83%，極有在未來超越的可能。Microsoft SQL Server做為常青樹，前期下滑趨勢非常明顯，給人感覺似乎體力不支，后繼無力，于2015年9月跌至谷底。但從2015年10月開始卻突然又獲得了動能，一路向上，讓人有所期待。

最新發布版本新特性對比

2016年，各個數據庫廠商或者社區都在頻頻發力，或發布版本，或完善功能以期獲得更大的市場占用率。可以說，今年是各數據庫產品大版本發布非常集中的一年，帶來了很多令人激動的新特性。我們現在就來看一下。

Oracle于9月18-22號的Oracle Open World大會上，發布了12c的第二個Major Release，期待已久的12cR2。了解Oracle的都知道，Oracle的每一個大版本例如10g、11g等都會包含兩個Major Release，Release 1和Release 2。而Release 2是非常穩定的版本，各種新功能和新特性也基本固定，不會再有大變化。所以一般生產系統的升級都會等待Release 2發布才開始。12cR2包含了16個大類多達幾百種新特性，涵蓋了開發、分布式、性能、高可用、安全等方方面面。而對于我個人來講，最吸引的莫過于Sharding功能的發布了。也就是說Oracle在12cR2，數據庫內置支持分庫分表，而且對于應用完全透明，無需修改代碼。這也秉承了Oracle一貫的原則，一是對應用透明；二是要么不做，要做就做到極致。Sharding特性的發布大大增強了應用系統的線性擴展能力，對于一直需要使用Oracle數據庫來獲得最高的可用性、穩定性、可靠性但又愁于無法獲得象MySQL一樣線性擴展和跨數據中心部署的企業無疑是一個巨大的福音。Oracle的Sharding特性提供：

數據相關的路由；Oracle Data Guard自動化部署；Statement-level Routing and Cross-Shard Queries；線性的擴展能力；良好的故障隔離性；應用數據的跨地域分布部署；數據庫的滾動升級；簡化云部署，支持本地、云以及混合部署方式。

Sharding被集成到Oracle數據庫的方方面面，也就是說在使用Sharding的同時，你仍然可以享受Oracle給你帶來的所有好處，獲得整體良好的體驗。

PostgreSQL做為一個近幾年發展迅速的RDBMS產品，一直維持著一年發布一個大版本的節奏，在每個版本中都能給我們帶來很多驚喜。在9月29號發布了令人期待的9.6版本，無論從垂直擴展性，系統性能、管理維護都有很大的提升。主要的特性包括：

增加了對于全表掃描、表關聯和聚合的并行執行。這是一個里程碑式的進步，可以使得查詢充分利用服務器的多核資源，大幅提升處理性能；

避免在進行vacuum freeze操作時掃描不必要的數據頁面；

為了提升系統整體可靠性，同步復制現在可以配置多個Standby Servers；

內置的全文檢索功能可以針對段落進行查詢；

postgres_fdw現在支持remote joins, sorts, UPDATEs and DELETEs；

系統性能大幅提升，特別針對多CPU服務器的擴展能力。

還有一點非常值得注意，在經過開發社區嚴肅的討論之后，對于PostgreSQL之后的版本編號策略進行了修訂。也就是說，從明年開始，PostgreSQL不再延續當前的編號規則發布5.7版本，而是直接從10開始。以后就是10、11、12依此類推。這是PostgreSQL發展的必然結果，是否也意味著每個版本都會有更多的新特性呢？我們先來看一下10的特性都可能會有哪些吧，摘錄如下：

Logical Replication；Column Storage & Executor Efficiency；分布式系統，將Postgres-XL引入PostgreSQL核心，內置支持Sharding；更多的并行處理，例如vacuum和analyze；進一步簡化分區管理維護以及提升分區查詢性能；Adaptive Query Planning；對于等待事件的監控，方便問題的定位和診斷。

是否很令人期待？

Microsoft SQL Server做為一個老牌數據庫也在今年6月1號發布了最新產品SQL Server 2016，難怪排名從5、6月份開始直線上升。而在Garner于10月5號發布的Operational Database Management Systems的“魔力象限報告”中，SQL Server也連續第二年不僅位于Leaders象限中，而且領先于Oracle。版本中的新特性包括：

數據庫作用域配置。新的 ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL) 語句可用于控制特定數據庫的特定配置；

內存優化表格式更改以及支持并行掃描；

并行更新抽樣統計信息以及實時查看查詢的活動執行計劃；

查詢存儲是一種新功能，讓DBA可以探查查詢計劃選擇和性能；

SQL Server 2016針對導入和導出JSON以及處理JSON字符串添加了內置支持；

PolyBase允許使用T-SQL語句訪問存儲在Hadoop或Azure Blob存儲中的數據并以即時方式對其進行查詢；

Stretch Database是SQL Server 2016中的新功能，可以既透明又安全地將歷史數據遷移到Microsoft Azure云，無縫訪問SQL Server數據，不管這些數據位于本地還是延伸到云中。

值得一提的是Stretch Database技術，數據位置對于應用透明，無論這些數據是位于自己的數據中心還是云中。Gartner也特別提到了SQL Server 2016的這一特性。

此外，微軟今年動作多多，不僅宣布了自己的SQL Server將會推出linux版本，而且在前兩天還加入了Linux基金會，積極向開源社區靠攏。

MySQL在10月12號發布了5.7.16 GA版。但更重要的是，MySQL的版本編號策略也和PostgreSQL一樣進行了調整，下一個MySQL版本不再是5.7，而且直接從8開始，然后9、10，依此類推。這難道是開源數據庫的趨勢嗎？每一個大版本都是重要的里程碑，使用小數點之后的數字區分不再適合。MySQL 8.0在9月12號發布了第一個Release，雖然不是GA版本，但我們直接來看一下即將到來的8會帶來什么令人期待的新特性吧：

MySQL服務器開始使用事務數據字典來存儲數據庫對象的信息；

開始支持role角色的概念；

可以通過innodb_deadlock_detect來禁用死鎖檢測，對于高并發系統，可以提升系統并發度。而可以依賴innodb_lock_wait_timeout來處理死鎖事務；

新的innodb_cached_indexes報告每個索引在buffer pool中緩存的索引頁數量；

所有innodb臨時表創建在共享臨時表空間ibtmp1中；

JSON處理的增強

增加->>操作符；增加兩個JSON聚集函數JSON_ARRAYAGG()和JSON_OBJECTAGG()。

MongoDB做為TOP 5中唯一的NoSQL數據庫，而且是Document DB類別中的佼佼者，也在2015年11月3號發布了3.2版本。而一年過去，就在2016年11月1號，MongoDB正式宣布了3.4版本，雖然還沒有發布GA版本。我們將3.2和3.4合并一起來看下MongoDB這顆冉冉升起之星都包含了哪些特性，為什么會獲得市場的認可。

為內存計算和對安全敏感的應用設計的新型可插拔存儲引擎；

在實時分析和搜索上提供更快的商業洞察；

通過document合法性校驗提供簡化的數據治理；

通過提供更強的管理平臺，提升分布式跨地區的部署的uptime，零停機升級等降低維護成本，提升運維效率啊；

Multimodel支持。提供內置圖計算，實時分析和針對BI和Spark的連接器；

Mission-Critical應用支持：

跨地域分布式MongoDB區彈性集群可調節的一致性級別增強的安全性提供豐富的DBA和DevOps工具，更快地和更高質量地發布應用：Schema Management細粒度監控內置的云集成工具

由此可以看出，現在的數據庫市場確實是一個百花齊放，百家爭鳴的時代。但其中也 有很多共性，不知大家發現沒有？

分布式數據庫技術

分布式數據庫技術由于其優良的線性橫向擴展能力和良好的故障隔離性，近幾年也受到了普遍關注。市場上不僅出現了很多新興的分布式數據庫引擎，老牌的數據庫也在分布式技術上投入重兵，加緊部署。

Oracle通過12cR2版本中Sharding功能的發布，支持了數據庫的跨地域分布式部署。一個SDB（Sharded Database）在邏輯上是一個數據庫，但每一個Shard其實都是一個獨立的傳統意義上的Oracle數據庫，Shard之間不共享任何資源，主機、存儲都是獨立的，屬于Share-nothing架構。同時，每一個Shard又可以搭建自己的高可用架構，例如RAC、同城和遠程災備。這樣就保證了SDB整體上的高可用、線性擴展能力以及故障隔離性。通過Sharding功能的推出，Oracle在高可用和橫向擴展上擁有了兩種技術，一種是RAC，一種是Sharding，兩種技術既可獨立使用，也可以協同使用。各自適應于不同的場景供企業選擇。

而PostgreSQL在分布式方面也發展迅速，社區非常活躍，積極地推進。當前存在幾種分布式的技術。

以Postgres-XL和Postgres-XZ為代表的技術，具備全局事務管理功能，協調器負責接收客戶端請求，解析和生成執行計劃并將它們發往數據節點進行處理，可以同時運行OLTP和OLAP負載。

還有Citus公司的開源插件pg_shard，現在已經進化為citus插件，并于今年3月24號開源。

再者就是基于postgres_fdw實現的sharding。postgres_fdw最近1年發展也非常迅速。現在已經可以實現join、sorts和aggregates下放到各foreign server也就是shard上面執行，以釋放協調器的資源提升整體吞吐量。未來還可以在整個架構中增加全局事務管理器，保證全局事務一致性，想象空間很大。

PostgreSQL的FDW（Foreign Data Wrapper）非常強大，其強大之處在于經過適當的配置甚至可以實現MySQL的Sharding。

還有一種分布式數據庫技術是基于Google的F1和Spanner，通過Paxos協議實現了同步跨數據中心的復制和分布式事務的強一致性，例如CockroachDB和TiDB。其中TiDB是我們的國產數據庫，將傳統的RDBMS和NoSQL的優勢合為一體。TiDB與MySQL完全兼容，得益于其架構中的MySQL協議層，MySQL應用無需修改便可直接運行。TiDB還支持多種存儲引擎，未來的發展值得期待。

MongoDB自不用說，做為NoSQL數據庫的翹楚，從產品設計之初便充分考慮了Sharding的支持和跨地域分布式部署。整個架構中包括路由節點、配置服務器和shard。通過路由節點和配置服務器，MongoDB對于數據在shard間的分布一清二楚，而數據的位置對于應用也完全透明。每一個shard都是一個獨立的副本集用于實現高可用和讀寫分離。在實際運維過程中，一個副本集內主從的切換非常方便，對于應用透明，由MongoDB自動完成，大大減少了運維復雜度和風險。

消除數據孤島，實現對不同數據存

隨著IoT和大數據時代的來臨，以及Polyglot Persistence概念的提出，數據的格式和存儲趨于多樣化。同時，產生數據的速度越來越快，數據量越來越大，企業不可能將所有數據放置于一個數據庫中，也不可能由單一的數據庫引擎來管理。如何將企業的數據邏輯上整合為一個整體，減少數據遷移成本，數據的位置對于計算引擎或者分析引擎透明成為了另外一個重要課題。各個數據庫廠商和社區也紛紛推出自己的解決方案來支持未來的發展。

在這個領域，Oracle推出了Big Data SQL。對于企業，無論數據是在Oracle中，還是在Hadoop上，抑或是在NoSQL數據庫里，都可以使用統一的SQL查詢語言來訪問，極大得降低了對人員技能的門檻要求以及進行企業數據分析的復雜度。Big Data SQL可以：

無縫地查詢位于Oracle、Hadoop以及NoSQL數據庫中的數據；使用Oracle SQL的強大功能查詢分析企業的全部數據；將Oracle數據庫的安全特性擴展至Hadoop和NoSQL數據庫。

而Microsoft SQL Server推出了PolyBase功能。PolyBase是一種訪問和合并所有來自SQL Server中的非關系和關系數據的技術。它允許對Hadoop或Azure blob存儲中的外部數據運行查詢。查詢會進行優化以將計算推送到Hadoop。僅使用Transact-SQL (T-SQL) 語句，你就可以在SQL Server中的關系表和存儲在Hadoop或Azure Blob存儲中的非關系數據之間來回導入和導出。還可以從T-SQL查詢內查詢外部數據并將其與關系數據聯接。

PostgreSQL通過前面提到的FDW可以勝任同樣的工作甚至可以做得更多。FDW支持數據源極其豐富：

SQL數據庫中支持Oracle、MySQL、Microsoft SQL Server，當然還有PostgreSQL自身等；而大數據方面支持Hadoop、Hive和Impala等；NoSQL數據庫支持MongoDB、Redis、Neo4j等。

可以看到，基本上可以實現全互聯互通，充滿無限可能。通過PostgreSQL的SQL查詢，我們可以訪問存儲在任何外部數據源中的數據，以統一的方式進行，并且實現安全管理。這正好符合了Gartner提出的LDW（Logical DataWarehouse）的概念，無論何時何地，在你面前只有一個PostgreSQL數據庫。

這個領域，MongoDB也不甘落后，推出了兩款產品。一個是BI Connector，可以讓用戶將他們存儲在MongoDB中的數據通過當前的關系型商業智能工具例如Tableau實現可視化。但有趣的是，BI Connector是通過PostgreSQL的FDW實現對MongoDB數據的SQL訪問。另外一個產品是Spark Connector，可以允許我們使用所有Spark的庫來訪問和分析存儲在MongoDB中的數據，包括SQL訪問、streaming、機器學習以及Graph API等。

Multimodel數據庫的出現和發展

Polyglot Persistence多態化存儲是指根據不同的數據格式提供不同持久化存儲格式，以往很難通過一種數據庫引擎達成，因此市場上出現了很多針對不同數據格式的數據庫產品。數據庫市場變得生機勃勃的同時，也帶來了一個問題，就是數據孤島Data Silo。每種數據庫引擎還可能提供不同的接口來訪問數據，無法統一。這些都給企業訪問、分析數據帶來了很頭疼的問題。雖然有前面提到的Big Data SQL，PostgreSQL FDW等技術可以使企業數據看起來是一個邏輯上的整體，可是對于不同數據間關聯分析的需求還是不理想，無論從性能上還是成本上。如何消除這些數據孤島，使得數據可以被更加便捷地訪問？數據庫廠商或者開源社區也意識到了這個潛在的市場空間，Gartner也相應地提出了一個新概念Multimodel database。顧名思義，Multimodel就是在一個數據庫產品中支持多種數據模型，包括關系型和非關系型（例如document、key-value和graph），并且提供統一的訪問接口，這樣就大大簡化了數據訪問層的復雜度，而且提升了訪問性能。而且，Gartner預測，2017年所有的Operational DBMS將會在一個DBMS平臺上同時支持多種數據模型，關系型和非關系型。2017年，NoSQL也將不再會成為區分multimodel、key-value、document、graph和table-style引擎的標簽。事實上，各個數據庫廠商已經開始支持multimodel。而對于multimodel來講，對JSON數據類型的支持幾乎成為代表，不可不提。

對于Oracle來講，一直以來的原則就是在一個數據庫中可運行任意類型的負載，支持任何數據類型，One For All。所以很早就支持結構化數據和非結構化數據同時存儲在數據庫中并且通過標準的SQL語言進行訪問，例如對Spatial和xml的支持。在當前最新的12c版本中，Oracle也提供了對JSON的支持來進一步完善Multimodel組合。而在12cR2中，Oracle進一步優化和改進了對JSON的支持，包括對JSON文檔查詢和JSON索引查詢的改進，在PLSQL中增加對JSON處理的操作符，在In-Memory中增加對JSON的支持等很多新特性。

PostgreSQL可謂是支持JSON數據類型的先驅，早在Oracle和MySQL之前于2012年9.2版本就開始增加了對JSON數據類型的支持。此后在每個版本中也都針對JSON進行持續的優化，例如在2014年的9.4版本又增加了對JSONB存儲格式的支持。由于多年經驗的積累，PostgreSQL在處理JSON方面的功能也是相當完善的。此外，PostgreSQL還通過H-Store插件提供對key-value的支持。

MySQL在5.7.8版本中開始支持JSON數據類型，并且在8中增加了很多對JSON的操作。需要特別提到的是，MySQL還支持通過Memcached的訪問接口來訪問innoDB中的數據。

SQL Server 2016也針對導入和導出JSON以及處理JSON字符串添加了內置支持。

MongoDB宣稱自己的體系結構就是multimodel。允許用戶在一個環境中自由搭配多種存儲引擎，而數據庫能夠通過內置的復制功能自動地管理數據在不同存儲引擎間的移動。MongoDB允許數據以多種形態出現，既可以是簡單的key-value，也可以是扁平的table-style結構，也可以是帶有深層嵌套數組和子文檔的復雜文檔結構。而這些數據也可以通過多種方式被訪問，包括簡單的查找到JOIN到圖遍歷都可以。因為這種靈活的存儲架構，應用程序可以針對不同的負載和訪問類型選擇不同的存儲引擎。

圖數據庫（Graph Database）的興起

互聯網、移動互聯、物聯網（IoT）帶來了數據爆炸式的增長，而數據的增長反過來又促進了人與人、人與物之間的聯系，未來我們將會生活在一個萬物互聯的世界。事實上，比之以前，我們已經生活在一個互聯的時代。幾乎每個人都在使用微信、Facebook或者Twitter這些社交網絡，有自己的社交圈。而Facebook也正是利用這些數據幫我們找到了已經失去聯系的朋友，或者向我們推薦可能感興趣的內容。我們在Amazon網站下的每一個書籍的訂單，也被用于向我們推薦更適合自己品味的書籍或者其他商品。這一切都依賴于relationship，不同的是，這個relationship不止指人與人，也指人與物和物與物；而每個人，每個物品都是這個無形的巨大網絡中的node（節點）。Node和relationship正是世間萬物最自然的表達方式。如何存儲node和relationship數據，以及如何進行快速訪問來回答我們的問題，改善我們的生活，Graph Database應運而生。

Graph Database兩個最重要的概念就是node和relationship，更學術一些的名稱是vertices和edges。通過node和relationship數據，可以非常容易地回答類似這樣的問題：

我朋友的朋友都有哪些朋友？我買的書同時還有誰買并且他們還買了什么其他書？

大家可否發現，這些問題正是我們熟知的稱之為推薦引擎所做的事情？這樣的問題可以有無窮多，這正是Graph Database的應用場景之一。以下是Graph Database的一些應用場景：

實時推薦；MDM（Master Data Management）；金融服務行業的反欺詐；基于圖的搜索，例如兩點之間的路徑搜索以及最短路徑；網絡和IT運維；身份和訪問管理。

可以看到，應用場景非常豐富，因此Graph Database的前景非常光明。有人也許會有疑問，關系型數據庫不是也有entity和relationship的概念嗎？難道不能實現這些功能？不是不行，但代價高昂。關系型數據庫中的entity存儲具有相同屬性的數據，entity之間的relationship需要通過JOIN來實現，這就是在關系型理論中的ER圖。JOIN是相對昂貴的操作，而且稍有不慎，便會對計算和I/O資源產生巨大消耗。像上面的問題，需要在不同的entity之間多級JOIN才能回答，不僅性能不理想，而且會對資源造成較大消耗。而Graph Database通過對圖的遍歷（Traversal）操作則可以在資源消耗最低的情況下快速完成查詢給出答案。傳統關系型數據庫不具備天然的Graph Traversal功能。

當前Graph Database主要分為兩類：Native和Non-native圖技術。而區分兩種技術分為兩個層面：storage和processing。

Storage是指用于存儲graph data的存儲格式。對于Native graph storage來講，設計上從每一個角度對node和relationship數據的寫入和查詢進行優化，確保相關聯的nodes和relationships在物理上是接近的，可以進行高速訪問。而Non-native graph storage依賴于外部存儲引擎，可以是關系型、columnar或者NoSQL例如MongoDB。由于這些外部存儲引擎并沒有針對graph data進行存儲優化，nodes和relationships可能被存放在相互距離很遠的地方而造成訪問延遲。

另一個關鍵因素processing是指如何對圖數據進行處理。對于native graph processing來講，一個關鍵區分點是進行無索引的相鄰訪問（index-free adjacency）。在寫入時，確保每一個node都能夠寫入到相鄰的nodes和relationships；而在查詢時，由于相鄰的nodes和relationships在物理上相近，無需索引便可完成高速訪問。而non-native processing則需要借助于global indexes完成訪問，而且訪問的速度可能還會取決于整個數據集的大小。

Graph Database的代表應該是Neo Technology公司的Neo4j數據庫。Neo4j同時也是一個native graph database，無論從存儲格式上還是訪問處理上都針對graph data進行了大量優化。在2016年的4月26號，Neo4j也發布了自己的3.0版本，在各方面都進行了重大改進：

新的存儲引擎解決了之前的擴展性限制并且保持了良好的訪問性能；為快速訪問圖數據而設計的新的二進制協議bolt；新的基于成本的優化器無論對于寫入還是查詢提供更好更快的訪問；新的配置和日志結構更好地支持各種部署場景。

此外，Neo4j還支持諸如服務端腳本、觸發器、主從復制、事務ACID等特性。所有這些，使得Neo4j的流行度越來越高，獲得了大家的認可。eBay、Walmart、Cisco、UBS等大型企業都有采用。

還有一點需要提到，Neo4j使用Cypher做為描述性的圖查詢語言。

另外一個native graph database叫做orientdb。但是orientdb不止是一個graph database，它還是一個支持multi-model的分布式數據庫引擎。也就是說，除了圖數據，還支持documents、對象、key-value、spatial和full-text類型的數據，而所有這些數據類型都被orientdb的核心直接管理，從而可以獲得良好的性能。除了對不同數據類型的支持，orientdb還支持不同的schema模式，schema-full、schema-less和schema-hybrid在orientdb中都可以使用。Orientdb區別于Neo4j還有兩點：一是可以進行multi-master replication，而Neo4j是master-slave replication；二是orientdb支持數據分片sharding而具有橫向擴展能力。

前面兩個graph database發展時間較長，而將要介紹的卻是一個新星，同樣屬于native graph database家族，叫做DGraph。DGraph使用時下流行的Go語言編寫，設計之初的考慮就是要支撐高并發和具備良好的擴展性。DGraph具有7大設計原則：

分布式，可以擴展至上百臺服務器并且跨越數據中心；低延遲，提供不僅低而且穩定的延遲，通過最小化查詢訪問的機器和網絡調用的數量；高吞吐量，提供讀和寫兩種操作的高并發；開源；強壯，足夠強壯和可靠以做為用戶的主要數據庫來使用；最小化，保持核心的簡單化和最小化，避免任何不必要的功能；干凈的設計。

但DGraph仍然在緊鑼密鼓地開發過程中，當前的版本是0.4.2，并不能夠應用于生產環境。DGraph通過GraphQL查詢語言來訪問。

接下來要介紹的是一個non-native graph database，叫做Titan。Titan也是一個具備擴展能力的分布式graph databsae。它支持多種存儲引擎來存放圖數據，例如Cassandra。成千上萬億的vertices和edges都可以存放在Titan由多臺服務器組成的集群中，并且可以進行高并發的實時復雜圖遍歷。Titan的特性包括：

數據的分布式存儲和復制；多數據中心的高可用和熱備份；支持ACID和最終一致性；支持多種存儲引擎，包括Cassandra、HBase和Oracle BerkeleyDB；通過和大數據平臺技術集成支持全局圖數據分析，報表和ETL，包括Hadoop和Spark；通過ElasticSearch、Solr和Lucene支持地理信息和全文檢索；和TinkerPop內置集成，支持Gremlin圖查詢語言。

在graph database小節的最后，再介紹一種non-native graph database，叫做Cayley。和前面介紹的DGraph一樣，Cayley也是使用Go語言開發。和DGraph不同的是Cayley沒有自己的存儲引擎，使用的是外部存儲，因此屬于non-native分類。Cayley的特性包括：

使用Go語言編寫，可以做為Go庫被使用；提供RESTful API；內置的查詢編輯器和可視化組件；支持多種查詢語言包括Gremlin和MQL；支持多種存儲引擎包括LevelDB、Bolt、PostgreSQL和MongoDB。其中使用MongoDB可以提供分布式存儲特性；模塊化的設計，很容易擴展使用新的語言和后端存儲引擎。

從以上對于graph database的介紹來看，這個領域整體上處于快速成長期，并沒有形成統一的標準和規范。無論存儲引擎還是查詢語言每個產品都有自己的實現，遷移轉換的成本較高。大家在選擇使用graph database時，需要謹慎評估和選型。

最后總結一下，本文通過以下幾個維度對2016年數據庫技術的發展趨勢進行了盤點。

在db-engines.com網站上的流行度走勢分析；本年度發布的版本中的新特性；分布式數據庫技術的流行；大數據時代對于數據統一訪問和分析的需要；數據類型多樣化促使multimodel數據庫的發展；圖形數據庫在萬物互聯下應運而生。

在每個維度中都以代表性的數據庫進行了詳細的闡述，從這些數據庫廠商又或者是活躍的開源數據庫身上，我們更可以清晰地看出當前世界數據庫技術發展的方向。

我相信，2017也將會是數據庫技術蓬勃發展的一年，讓我們一起期待！