回顧2018年最受歡迎的十四款NoSQL產品

​​雖然NoSQL的流行與火起來才短短一年的時間，可是不能否認，如今已經開始了第二代運動。儘管早期的堆棧代碼只能算是一種實驗，然而如今的系統已經更加的成熟、穩定。不過如今也面臨着一個嚴酷的事實：技術愈來愈成熟——以致於原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認爲這就是所謂的2.0版本。該工具能夠爲大數據創建快速、可擴展的存儲庫。

MongoDB

MongoDB是一個基於分佈式文件存儲的數據庫。由C++語言編寫。主要解決的是海量數據的訪問效率問題，爲WEB應用提供可擴展的高性能數據存儲解決方案。當數據量達到50GB以上的時候，MongoDB的數據庫訪問速度是MySQL的10倍以上。MongoDB的併發讀寫效率不是特別出色，根據官方提供的性能測試代表，大約每秒能夠處理0.5萬~1.5萬次讀寫請求。MongoDB還自帶了一個出色的分佈式文件系統GridFS，能夠支持海量的數據存儲。

MongoDB也有一個Ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB接口，使用起來很是簡單，幾乎和DataMapper如出一轍，功能很是強大。

MongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散，是相似json的bjson格式，所以能夠存儲比較複雜的數據類型。Mongo最大的特色是他支持的查詢語言很是強大，其語法有點相似於面向對象的查詢語言，幾乎能夠實現相似關係數據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。

所謂「面向集合」（Collenction-Orented），意思是數據被分組存儲在數據集中，被稱爲一個集合（Collenction)。每一個 集合在數據庫中都有一個惟一的標識名，而且能夠包含無限數目的文檔。集合的概念相似關係型數據庫（RDBMS）裏的表（table），不一樣的是它不須要定義任何模式（schema)。

模式自由（schema-free)，意味着對於存儲在mongodb數據庫中的文件，咱們不須要知道它的任何結構定義。若是須要的話，你徹底能夠把不一樣結構的文件存儲在同一個數據庫裏。

存儲在集合中的文檔，被存儲爲鍵-值對的形式。鍵用於惟一標識一個文檔，爲字符串類型，而值則能夠是各中複雜的文件類型。咱們稱這種存儲形式爲BSON（Binary Serialized dOcument Format）。

MongoDB服務端可運行在Linux、Windows或OS X平臺，支持32位和64位應用，默認端口爲27017。推薦運行在64位平臺，由於MongoDB在32位模式運行時支持的最大文件尺寸爲2GB。

MongoDB把數據存儲在文件中（默認路徑爲：/data/db），爲提升效率使用內存映射文件進行管理。

它的特色是高性能、易部署、易使用，存儲數據很是方便。

主要功能特性有：

面向集合存儲，易存儲對象類型的數據。
基於文檔的數據庫系統，格式是以BSON（JSON，半結構化數據）存儲。
性能的保證，基於C++研發，速度快。
支持徹底索引（數據讀取全靠索引）
不支持事務，意味每個操做都是原子的且是強一致性。
操做在內存中進行，定義同步到磁盤。
支持很好的擴展性，好比複製，auto_sharding。
能基於複製自動完整故障轉移。
支持文檔的查詢，能夠返回一個文檔也能夠返回一個遊標（結果集）。
支持查詢性能分析。
支持動態查詢，就是能夠像MySQL那樣本身書寫查詢條件，而有些NoSQL這不行。
支持使用Map Redure作分組聚合操做，處理大數據極強。
支持空間索引，用於地理數據表述的場景，如地圖。
自動處理碎片，以支持雲計算層次的擴展性。

Hbase

HBase是一個分佈式的、面向列的開源數據庫，該技術來源於Chang et al所撰寫的Google論文「Bigtable：一個結構化數據的分佈式存儲系統」。就像Bigtable利用了Google文件系統（File System）所提供的分佈式數據存儲同樣，HBase在Hadoop之上提供了相似於Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不一樣於通常的關係數據庫,它是一個適合於非結構化數據存儲的數據庫.另外一個不一樣的是HBase基於列的而不是基於行的模式。

HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集羣。 HBase是Google Bigtable的開源實現，相似Google Bigtable利用GFS做爲其文件存儲系統，HBase利用Hadoop HDFS做爲其文件存儲系統；Google運行MapReduce來處理Bigtable中的海量數據，HBase一樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable利用 Chubby做爲協同服務，HBase利用Zookeeper做爲對應。

HBase訪問接口

Native Java API，最常規和高效的訪問方式，適合Hadoop MapReduce Job並行批處理HBase表數據

HBase Shell，HBase的命令行工具，最簡單的接口，適合HBase管理使用

Thrift Gateway，利用Thrift序列化技術，支持C++，PHP，Python等多種語言，適合其餘異構系統在線訪問HBase表數據

REST Gateway，支持REST 風格的Http API訪問HBase, 解除了語言限制

Pig，可使用Pig Latin流式編程語言來操做HBase中的數據，和Hive相似，本質最終也是編譯成MapReduce Job來處理HBase表數據，適合作數據統計

Hive，當前Hive的Release版本尚沒有加入對HBase的支持，但在下一個版本Hive 0.7.0中將會支持HBase，可使用相似SQL語言來訪問HBase

主要功能特性有：

支持數十億行X上百萬列
採用分佈式架構 Map/reduce
對實時查詢進行優化
高性能 Thrift網關
經過在server端掃描及過濾實現對查詢操做預判
支持 XML, Protobuf, 和binary的HTTP
基於 Jruby（ JIRB）的shell
對配置改變和較小的升級都會從新回滾
不會出現單點故障
堪比MySQL的隨機訪問性能

Redis

Redis是一個開源（BSD許可）的內存中的數據結構存儲系統，它能夠用做數據庫、緩存和消息中間件。因爲Redis採用運行在內存中的數據集工做方式，其性能卓越，能支持超過100K+每秒的讀寫頻率。它支持多種類型的數據結構，如字符串（strings）， 散列（hashes），列表（lists），集合（sets），有序集合（sorted sets）與範圍查詢和地理空間（geospatial）索引半徑查詢。Redis內置了複製（replication）， LUA腳本（Lua scripting），LRU淘汰機制，事務實現（transactions），發佈訂閱（publish/subscribe）和不一樣級別的磁盤持久化（persistence）等能力， 並經過Redis哨兵（Sentinel）和自動分區（Cluster）提供高可用性（high availability）。

Redis的主要功能都是基於單線程網絡模型實現，也就是說Redis使用一個線程來服務全部的客戶端請求，同時Redis採用了非阻塞式IO，並精細地優化各類命令的算法和時間複雜度，大部分命令的算法都是O(1)的，具體能夠看Redis命令參考。

另外Redis的大部分操做都是原子性的（簡單的單線程模型），同時Redis還支持對幾個操做全並後的原子性執行。列如：字符串（strings）的append命令；散列（hashes）的hincrby命令；列表（lists）的lpush命令；集合（sets）計算交集sinter命令，計算並集union命令和計算差集sdiff命令；或者在有序集合（sorted sets）裏面獲取成員的最高排名zrangebyscore命令等。

官方站點：http://redis.io

Memcachedb

MemcacheDB是一個分佈式、key-value形式的持久存儲系統。它不是一個緩存組件，而是一個基於對象存取的、可靠的、快速的持久存儲引擎。協議跟memcache一致（不完整），因此不少memcached客戶端均可以跟它鏈接。MemcacheDB採用Berkeley DB做爲持久存儲組件，故不少Berkeley DB的特性的他都支持

MemcacheDB是一個分佈式、key-value形式的持久存儲系統。它不是一個緩存組件，而是一個基於對象存取的、可靠的、快速的持久存儲引擎。 協議跟memcache一致（不完整），因此不少memcached客戶端均可以跟它鏈接。MemcacheDB採用Berkeley DB做爲持久存儲組件，故不少Berkeley DB的特性的他都支持。咱們是站在巨人的肩膀上的。MemcacheDB的前端緩存是Memcached 。

前端：memcached的網絡層

後端：BerkeleyDB存儲

寫速度：從本地服務器經過memcache客戶端（libmemcache）set2億條16字節長的key，10字節長的Value的記錄，耗時 16572秒，平均速度12000條記錄/秒。

讀速度：從本地服務器經過memcache客戶端（libmemcache）get100萬條16字節長的key，10字節長的Value的記錄，耗 時103秒，平均速度10000條記錄/秒。支持的memcache命令。

官方站點：http://memcachedb.org

Hypertable

Hypertable是一個開源、高性能、可伸縮的數據庫，它採用與Google的Bigtable類似的模型。在過去數年中，Google爲在 PC集羣 上運行的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統，提供了一個全局的命名空間。它經過跨機器（和跨機架）的文件數據複製來達到高可用性，並所以免受傳統 文件存儲系統沒法避免的許多失敗的影響，好比電源、內存和網絡端口等失敗。第二個基礎設施是名爲Map-Reduce的計算框架，它與GFS緊密協做，幫 助處理收集到的海量數據。第三個基礎設施是Bigtable，它是傳統數據庫的替代。Bigtable讓你能夠經過一些主鍵來組織海量數據，並實現高效的 查詢。Hypertable是Bigtable的一個開源實現，而且根據咱們的想法進行了一些改進。

主要功能特色：

負載均衡的處理
版本控制和一致性
可靠性
分佈爲多個節點

CouchDB

Apache CouchDB是一個面向文檔的數據庫管理系統。它提供以 JSON 做爲數據格式的 REST 接口來對其進行操做，並能夠經過視圖來操縱文檔的組織和呈現。 CouchDB 是 Apache 基金會的頂級開源項目。

CouchDB是用Erlang開發的面向文檔的數據庫系統，其數據存儲方式相似Lucene的Index文件格式。CouchDB最大的意義在於它是一個面向Web應用的新一代存儲系統，事實上，CouchDB的口號就是：下一代的Web應用存儲系統

主要功能特性有：

CouchDB是分佈式的數據庫，他能夠把存儲系統分佈到n臺物理的節點上面，而且很好的協調和同步節點之間的數據讀寫一致性。這固然也得以於Erlang無與倫比的併發特性才能作到。對於基於web的大規模應用文檔應用，然的分佈式可讓它沒必要像傳統的關係數據庫那樣分庫拆表，在應用代碼層進行大量的改動。

CouchDB是面向文檔的數據庫，存儲半結構化的數據，比較相似lucene的index結構，特別適合存儲文檔，所以很適合CMS，電話本，地址本等應用，在這些應用場合，文檔數據庫要比關係數據庫更加方便，性能更好。

CouchDB支持REST API，可讓用戶使用JavaScript來操做CouchDB數據庫，也能夠用JavaScript編寫查詢語句，咱們能夠想像一下，用AJAX技術結合CouchDB開發出來的CMS系統會是多麼的簡單和方便。其實CouchDB只是Erlang應用的冰山一角，在最近幾年，基於Erlang的應用也獲得的蓬勃的發展，特別是在基於web的大規模，分佈式應用領域，幾乎都是Erlang的優點項目。

cassandra

Cassandra是一個混合型的非關係的數據庫，相似於Google的BigTable。其主要功能比Dynomite（分佈式的Key-Value存儲系統）更豐富，但支持度卻不如文檔存儲MongoDB（介於關係數據庫和非關係數據庫之間的開源產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。支持的數據結構很是鬆散，是相似json的bjson格式，所以能夠存儲比較複雜的數據類型。）Cassandra最初由Facebook開發，後轉變成了開源項目。它是一個網絡社交雲計算方面理想的數據庫。以Amazon專有的徹底分佈式的Dynamo爲基礎，結合了Google BigTable基於列族（Column Family）的數據模型。P2P去中心化的存儲。不少方面均可以稱之爲Dynamo 2.0

特性和其餘數據庫比較，有幾個突出特色：模式靈活 ：使用Cassandra，像文檔存儲，你沒必要提早解決記錄中的字段。你能夠在系統運行時隨意的添加或移除字段。這是一個驚人的效率提高，特別是在大型部 署上。
真正的可擴展性 ：Cassandra是純粹意義上的水平擴展。爲給集羣添加更多容量，能夠指向另外一臺電腦。你沒必要重啓任何進程，改變應用查詢，或手動遷移任何數據。
多數據中心識別 ：你能夠調整你的節點佈局來避免某一個數據中心起火，一個備用的數據中心將至少有每條記錄的徹底複製。

一些使Cassandra提升競爭力的其餘功能：

範圍查詢 ：若是你不喜歡所有的鍵值查詢，則能夠設置鍵的範圍來查詢

列表數據結構 ：在混合模式能夠將超級列添加到5維。對於每一個用戶的索引，這是很是方便的

分佈式寫操做 ：有能夠在任何地方任什麼時候間集中讀或寫任何數據。而且不會有任何單點失敗

Tokyo Cabinet/Tokyo Tyant

Tokyo Cabinet（TC）和Tokyo Tyrant（TT）的開發者是日本人Mikio Hirabayashi，主要用於日本最大的SNS網站mixi.jp。TC出現的時間最先，如今已是一個很是成熟的項目，也是Key-Value數據庫領域最大的熱點，如今普遍應用於網站。TC是一個高性能的存儲引擎，而TT提供了多線程高併發服務器，性能也很是出色，每秒能夠處理4萬~5萬次讀寫操做。

TC除了支持Key-Value存儲以外，還支持Hashtable數據類型，所以很像一個簡單的數據庫表，而且還支持基於Column的條件查詢、分頁查詢和排序功能，基本上至關於支持單表的基礎查詢功能，因此能夠簡單地替代關係數據庫的不少操做，這也是TC受到你們歡迎的主要緣由之一。有一個Ruby項目miyazakiresistance將TT的Hashtable的操做封裝成和ActiveRecord同樣的操做，用起來很是高效

TC/TT在Mixi的實際應用當中，存儲了2000萬條以上的數據，同時支撐了上萬個併發鏈接，是一個久經考驗的項目。TC在保證了極高的併發讀寫性能的同時，還具備可靠的數據持久化機制，同時還支持相似關係數據庫表結構的Hashtable以及簡單的條件、分頁和排序操做，是一個很優越的NoSQL數據庫。

TC的主要缺點是，在數據量達到上億級別之後，併發寫數據性能會大幅度降低，開發人員發如今TC裏面插入1.6億條2KB~20KB數據的時候，寫入性能開始急劇降低。即當數據量達到上億條的時候，TC性能便開始大幅度降低，從TC做者本身提供的Mixi數據來看，至少上千萬條數據量的時候尚未遇到這麼明顯的寫入性能瓶頸

Flare

TC是日本第一大SNS網站mixi.jp開發的，而Flare是日本第二大SNS網站green.jp開發的。簡單地說，Flare就是給TC添加了scale（可擴展）功能。它替換了TT部分，本身另外給TC寫了網絡服務器。Flare的主要特色就是支持scale能力，它在網絡服務端以前添加了一個Node Server，用來管理後端的多個服務器節點，所以能夠動態添加數據庫服務節點、刪除服務器節點，也支持Failover。若是你的使用場景必須讓TC能夠scale，那麼能夠考慮Flare。

flare惟一的缺點就是他只支持memcached協議，所以當你使用flare的時候，就不能使用TC的table數據結構了，只能使用TC的key-value數據結構存儲。

Berkeley DB

Berkeley DB (DB)是一個高性能的，嵌入數據庫編程庫，和C語言，C++，Java，Perl，Python，PHP，Tcl以及其餘不少語言都有綁定。Berkeley DB能夠保存任意類型的鍵/值對，並且能夠爲一個鍵保存多個數據。Berkeley DB能夠支持數千的併發線程同時操做數據庫，支持最大256TB的數據，普遍 用於各類操做系統包括大多數Unix類操做系統和Windows操做系統以及實時操做系統。

Berkeley DB最初開發的目的是以新的HASH訪問算法來代替舊的hsearch函數和大量的dbm實現（如AT&T的dbm，Berkeley的 ndbm，GNU項目的gdbm），Berkeley DB的第一個發行版在1991年出現，當時還包含了B+樹數據訪問算法。在1992年，BSD UNIX第4.4發行版中包含了Berkeley DB1.85版。基本上認爲這是Berkeley DB的第一個正式版。在1996年中期，Sleepycat軟件公司成立，提供對Berkeley DB的商業支持。在這之後，Berkeley DB獲得了普遍的應用，成爲一款獨樹一幟的嵌入式數據庫系統。2006年Sleepycat公司被Oracle 公司收購，Berkeley DB成爲Oracle數據庫家族的一員，Sleepycat原有開發者繼續在Oracle開發Berkeley DB，Oracle繼續原來的受權方式而且加大了對Berkeley DB的開發力度，繼續提高了Berkeley DB在軟件行業的聲譽。Berkeley DB的當前最新發行版本是4.7.25。

Memlink

Memlink 是天涯社區開發的一個高性能、持久化、分佈式的Key-list/queue數據引擎。正如名稱中的memlink所示，全部數據都建構在內存中，保證了 系統的高性能 (大約是redis幾倍)，同時使用了redo-log技術保證數據的持久化。Memlink還支持主從複製、讀寫分離、List過濾操做等功能。

與Memcached不一樣的是，它的value是一個list/queue。而且提供了諸如持久化，分佈式的功能。聽起來有點像Redis，但它號稱比Redis更好，在不少Redis作得還很差的地方進行了改進和完善。提供的客戶端開發包包括 c,python,php,java 四種語言

特色：

內存數據引擎，性能極爲高效
List塊鏈結構，精簡內存，優化查找效率
Node數據項可定義，支持多種過濾操做
支持redo-log，數據持久化，非Cache模式
分佈式，主從同步

db4o

「利用表格存儲對象，就像是將汽車開回家，而後拆成零件放進車庫裏，早晨能夠再把汽車裝配起來。可是人們不由要問，這是否是泊車的最有效的方法呢。」 – Esther Dyson 　　db4o 是一個開源的純面向對象數據庫引擎，對於 Java 與 .NET 開發者來講都是一個簡單易用的對象持久化工具，使用簡單。同時，db4o 已經被第三方驗證爲具備優秀性能的面向對象數據庫， 下面的基準測試圖對 db4o 和一些傳統的持久方案進行了比較。db4o 在此次比較中排名第二，僅僅落後於JDBC。經過圖 1 的基準測試結果，值得咱們細細品味的是採用 Hibernate/HSQLDB 的方案和 JDBC/HSQLDB 的方案在性能方面有着顯著差距，這也證明了業界對 Hibernate 的擔心。而 db4o 的優異性能，讓咱們相信： 更 OO 並不必定會犧牲性能。

同時，db4o 的一個特色就是無需 DBA 的管理，佔用資源很小，這很適合嵌入式應用以及 Cache 應用， 因此自從 db4o 發佈以來，迅速吸引了大批用戶將 db4o 用於各類各樣的嵌入式系統，包括流動軟件、醫療設備和實時控制系統。 　　db4o 由來自加州硅谷的開源數據庫公司 db4objects 開發並負責商業運營和支持。db4o 是基於 GPL 協議。db4objects 於 2004 年在 CEO Christof Wittig 的領導下組成，資金背景包括 Mark Leslie 、 Veritas 軟件公司 CEO 、 Vinod Khosla （ Sun 公司創始人之一）、 Sun 公司 CEO 在內的硅谷高層投資人組成。毫無疑問，今天 db4objects 公司是硅谷煊赫一時的技術創新者之一

db4o 的目標是提供一個功能強大的，適合嵌入的數據庫引擎，能夠工做在設備，移動產品，桌面以及服務器等各類平臺。主要特性以下：開源模式。與其餘 ODBMS 不一樣，db4o 爲開源軟件，經過開源社區的力量驅動開發 db4o 產品。原生數據庫。db4o 是 100% 原生的面向對象數據庫，直接使用編程語言來操做數據庫。程序員無需進行 OR 映射來存儲對象，大大節省了程序員在存儲數據的開發時間。高性能。 下圖爲 db4o 官方公佈的基準測試數據，db4o 比採用 Hibernate/MySQL 方案在某些測試線路上速度高出 44 倍之多！而且安裝簡單，僅僅須要 400Kb 左右的 .jar 或 .dll 庫文件。在接下來的系列文章中，咱們將只關注在 Java 平臺的應用，可是實際上 db4o 毫無疑問會很好地在 .NET平臺工做

易嵌入，使用 db4o 僅需引入 400 多 k 的 jar 文件或是 dll 文件，內存消耗極小。零管理。使用 db4o 無需 DBA，實現零管理。支持多種平臺。db4o 支持從 Java 1.1 到 Java 5.0，此外還支持 .NET 、 CompactFramework 、 Mono 等 .NET 平臺，也能夠運行在 CDC 、 PersonalProfile 、 Symbian 、 Savaje 以及 Zaurus 這種支持反射的 J2ME 方言環境中，還能夠運行在 CLDC 、 MIDP 、 RIM/Blackberry 、 Palm OS 這種不支持反射的 J2ME 環境中。 或許開發者會問，若是現有的應用環境已經有了關係型數據庫怎麼辦？不要緊，db4o 的 dRS（db4o Replication System）可實現 db4o 與關係型數據庫的雙向同步（複製），如圖 3 。 dRS 是基於 Hibernate 開發，目前的版本是 1.0 ，並運行在 Java 1.2 或更高版本平臺上，基於 dRS 可實現 db4o 到 Hibernate/RDBMS 、 db4o 到 db4o 以及 Hibernate/RDBMS 到 Hibernate/RDBMS 的雙向複製。dRS 模型如圖

Versant

Versant Object Database (V/OD) 提供強大的數據管理，面向 C++, Java or .NET 的對象模型，支持大併發和大規模數據集合。

Versant對象數據庫是一個對象數據庫管理系統(ODBMS：Object Database Management System)。它主要被用在複雜的、分佈式的和異構的環境中，用來減小開發量和提升性能。尤爲當程序是使用Java和（或）C＋＋語言編寫的時候，尤爲有用。

它是一個完整的，電子基礎設施軟件，簡化了事務的構建和部署的分佈式應用程序。

做爲一個卓越的數據庫產品，Versant ODBMS在設計時的目標就是爲了知足客戶在異類處理平臺和企業級信息系統中對於高性能、可量測性、可靠性和兼容性方面的需求。

Versant對象數據庫已經在爲企業業務應用提供可靠性、完整性和高性能方面得到了建樹，Versant ODBMS所表現出的高效的多線程架構、internal parallelism 、平穩的Client－Server結構和高效的查詢優化，都體現了其很是卓越的性能和可擴展性。

Versant對象數據庫包括Versant ODBMS，C++和Java語言接口，XML工具包和異步複製框架

Versant Object Database8.0，適用於應用環境中包含複雜對象模型的數據庫，其設計目標是可以處理這些應用常常須要的導航式訪問，無縫的數據分發，和企業級的規模。

對於不少應用程序而言，最具挑戰性的方面是控制業務模型自己的內在複雜性。 電信基礎設施，交通運輸網絡，仿真，金融工具以及其它領域的複雜性必須獲得支持， 並且這種支持複雜性的方式還要可以隨着環境和需求變化而不斷地改進應用程序。 這些應用程序的重點是領域和這些領域的邏輯。 複雜的設計應當以對象模型爲基礎。將技術需求例如持久性（和SQL）與領域模型混合在一塊兒的架構會帶來災難性的後果。

Versant對象數據庫使您可使用那些只含有域行爲信息的對象，而不用考慮持久性。同時，Versant對象數據庫還能提供跨多個數據庫的無縫的數據分發，高併發性，細粒度鎖，頂級性能， 以及經過複製和其它技術提供的高可用性。現代Java中的對象關係映射工具已經簡化了不少映射的問題， 可是它們還不能提供Versant所能提供的無縫數據分發的功能和高性能

主要特性

C++、Java及.NET 的透明對象持久

支持對象持久標準，如JDO

跨多數據庫的無縫數據分發

企業級的高可用性選項

動態模式更新

管理工做量少（或不須要）

端到端的對象支持架構

細粒度併發控制

多線程，多會話

支持國際字符集

高速數據採集

Neo4j

Neo4j是一個嵌入式，基於磁盤的，支持完整事務的Java持久化引擎，它在圖像中而不是表中存儲數據。Neo4j提供了大規模可擴展性，在一臺機器上能夠處理數十億節點/關係/屬性的圖像，能夠擴展到多臺機器並行運行。相對於關係數據庫來講，圖形數據庫善於處理大量複雜、互鏈接、低結構化的數據，這些數據變化迅速，須要頻繁的查詢——在關係數據庫中，這些查詢會致使大量的錶鏈接，所以會產生性能上的問題。Neo4j重點解決了擁有大量鏈接的傳統RDBMS在查詢時出現的性能衰退問題。經過圍繞圖形進行數據建模，Neo4j會以相同的速度遍歷節點與邊，其遍歷速度與構成圖形的數據量沒有任何關係。此外，Neo4j還提供了很是快的圖形算法、推薦系統和OLAP風格的分析，而這一切在目前的RDBMS系統中都是沒法實現的。

Neo是一個網絡——面向網絡的數據庫——也就是說，它是一個嵌入式的、基於磁盤的、具有徹底的事務特性的Java持久化引擎，可是它將結構化數據存儲在網絡上而不是表中。網絡（從數學角度叫作圖）是一個靈活的數據結構，能夠應用更加敏捷和快速的開發模式。

你能夠把Neo看做是一個高性能的圖引擎，該引擎具備成熟和健壯的數據庫的全部特性。程序員工做在一個面向對象的、靈活的網絡結構下而不是嚴格、靜態的表中——可是他們能夠享受到具有徹底的事務特性、企業級的數據庫的全部好處。

因爲使用了「面向網絡的數據庫」，人們對Neo充滿了好奇。在該模型中，以「節點空間」來表達領域數據——相對於傳統的模型表、行和列來講，節點空間是不少節點、關係和屬性（鍵值對）構成的網絡。關係是第一級對象，能夠由屬性來註解，而屬性則代表了節點交互的上下文。網絡模型完美的匹配了本質上就是繼承關係的問題域，例如語義Web應用。Neo的建立者發現繼承和結構化數據並不適合傳統的關係數據庫模型：

1.對象關係的不匹配使得把面向對象的「圓的對象」擠到面向關係的「方的表」中是那麼的困難和費勁，而這一切是能夠避免的。

2.關係模型靜態、剛性、不靈活的本質使得改變schemas以知足不斷變化的業務需求是很是困難的。因爲一樣的緣由，當開發小組想應用敏捷軟件開發時，數據庫常常拖後腿。

3.關係模型很不適合表達半結構化的數據——而業界的分析家和研究者都認爲半結構化數據是信息管理中的下一個重頭戲。

4.網絡是一種很是高效的數據存儲結構。人腦是一個巨大的網絡，萬維網也一樣構形成網狀，這些都不是巧合。關係模型能夠表達面向網絡的數據，可是在遍歷網絡並抽取信息的能力上關係模型是很是弱的。

雖然Neo是一個比較新的開源項目，但它已經在具備1億多個節點、關係和屬性的產品中獲得了應用，而且能知足企業的健壯性和性能的需求：

徹底支持JTA和JTS、2PC分佈式ACID事務、可配置的隔離級別和大規模、可測試的事務恢復。這些不只僅是口頭上的承諾：Neo已經應用在高請求的24/7環境下超過3年了。它是成熟、健壯的，徹底達到了部署的門檻

Neo4j是一個用Java實現、徹底兼容ACID的圖形數據庫。數據以一種針對圖形網絡進行過優化的格式保存在磁盤上。Neo4j的內核是一種極快的圖形引擎，具備數據庫產品指望的全部特性，如恢復、兩階段提交、符合XA等。

Neo4j既可做爲無需任何管理開銷的內嵌數據庫使用；也能夠做爲單獨的服務器使用，在這種使用場景下，它提供了普遍使用的REST接口，可以方便地集成到基於PHP、.NET和JavaScript的環境裏。但本文的重點主要在於討論Neo4j的直接使用。

Neo4j的典型數據特徵：

數據結構不是必須的，甚至能夠徹底沒有，這能夠簡化模式變動和延遲數據遷移。

能夠方便建模常見的複雜領域數據集，如CMS裏的訪問控制可被建模成細粒度的訪問控制表，類對象數據庫的用例、TripleStores以及其餘例子。

典型使用的領域如語義網和RDF、LinkedData、GIS、基因分析、社交網絡數據建模、深度推薦算法以及其餘領域。

圍繞內核，Neo4j提供了一組可選的組件。其中有支持經過元模型構造圖形結構、SAIL – 一種SparQL兼容的RDF TripleStore實現或一組公共圖形算法的實現。

高性能？

要給出確切的性能基準數據很難，由於它們跟底層的硬件、使用的數據集和其餘因素關聯很大。自適應規模的Neo4j無需任何額外的工做即可以處理包含數十億節點、關係和屬性的圖。它的讀性能能夠很輕鬆地實現每毫秒（大約每秒1-2百萬遍歷步驟）遍歷2000關係，這徹底是事務性的，每一個線程都有熱緩存。使用最短路徑計算，Neo4j在處理包含數千個節點的小型圖時，甚至比MySQL快1000倍，隨着圖規模的增長，差距也愈來愈大。

這其中的緣由在於，在Neo4j裏，圖遍歷執行的速度是常數，跟圖的規模大小無關。不象在RDBMS裏常見的聯結操做那樣，這裏不涉及下降性能的集合操做。Neo4j以一種延遲風格遍歷圖 – 節點和關係只有在結果迭代器須要訪問它們的時候纔會被遍歷並返回，對於大規模深度遍歷而言，這極大地提升了性能。

寫速度跟文件系統的查找時間和硬件有很大關係。Ext3文件系統和SSD磁盤是不錯的組合，這會致使每秒大約100,000寫事務操做