簡介

圖資料庫源起尤拉和圖理論，也可稱為面向/基於圖的資料庫，對應的英文是Graph Database。

圖資料庫的基本含義是以“圖”這種資料結構儲存和查詢資料，而不是儲存圖片的資料庫。它的資料模型主要是以節點和關係（邊）來體現，也可處理鍵值對。它的優點是快速解決複雜的關係問題。
圖將實體表現為節點，實體與其他實體連線的方式表現為聯絡。我們可以用這個通用的、富有表現力的結構來建模各種場景，從宇宙火箭的建造到道路系統，從食物的供應鏈及原產地追蹤到人們的病歷，甚至更多其他的場景。
圖形資料庫是NoSQL資料庫的一種型別，它應用圖形理論儲存實體之間的關係資訊。最常見的例子，就是社會網路中人與人之間的關係。關係型資料庫用於儲存關係型資料的效果並不好，其查詢複雜、緩慢、超出預期，而圖形資料庫的獨特設計恰恰彌補了這個缺陷。
目前主流的圖資料庫有：Neo4j，FlockDB，GraphDB，InfiniteGraph，Titan，JanusGraph，Pregel等。下面說一下JanusGraph
官網上：

JanusGraph is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster. JanusGraph is a transactional database that can support thousands of concurrent users executing complex graph traversals in real time.

JanusGraph是一個可擴充套件的圖形資料庫，專門用於儲存和查詢分析分佈在多機叢集中的數千億個頂點和關係邊的圖形。
JanusGraph是一個事務資料庫，可以支援數千個併發使用者實時執行復雜的圖遍歷。

歷史

• JanusGraph是2016年12月27日從Titan fork出來的一個分支，之後TiTan的開發團隊在2017年陸續發了0.1.0rc1、0.1.0rc2、0.1.1、0.2.0等四個版本，最新的版本是2017年10月12日。
• titan是從2012年開始開發，到2016年停止維護的一個分散式圖資料庫。最初在2012年啟動titan專案的公司是Aurelius，2015年此公司被 DataStax（DataStax是開發apache Cassandra 的公司）收購，DataStax公司吸收了TiTan的圖儲存能力，形成了自己的商業產品DataStax Enterprise Graph。
• TiTan開發者們希望把TitTan放到Apache Software Foundation下，不過，DataStax不願意這樣做（可能考慮到要保護自己的商業產品DataStax Enterprise Graph的技術優勢吧，其實這點優勢是從Titan來的），而且自從2015年9月DataStax收購了Titan的母公司後，TiTan一直處於停滯狀態（應該是DataStax收購之後，忙於推出自己的商業產品DataStax Enterprise Graph，忙於整合Titan進自己的商業產品吧，可是Titan本身沒有得到發展）。鑑於此，2016年6月，TiTan的開發者們fork了一個TiTan的分支（因為Titan已經屬於DataStax了，所以他們必須另外弄一個商標），重新命名為JanusGraph，並將其置於Linux Software Foundation下。
• 2017年4月6日釋出了第一個版本0.1.0-rc1，目前最新版本是2017年10月12日釋出的0.2.0版。

JanusGraph專案啟動的初衷是“通過為其增加新功能、改善效能和擴充套件性、增加後端儲存系統來增強分散式圖系統的功能，從而振興分散式圖系統的開發”，JanusGraph從Apahce TinkerPop中吸收了對屬性圖模型（Property Graph Model）的支援和對屬性圖模型進行遍歷的Gremlin遍歷語言。

基本概念

同大多數圖資料庫一樣，JanusGraph採用 屬性圖 進行建模。基於屬性圖的模型，JanusGraph有如下基本概念：

1. Vertex Label：節點的型別，用於表示現實世界中的實體型別，比如"人”，“車”。在JanusGraph中，每一個節點有且只有一個Vertex Label。當不顯式指定Vertex Label時，採用預設的Vertex Label。
2. Vertex：節點/頂點，用於表示現實世界中的實體物件。
3. Edge Label：邊的型別，用於表示現實世界中的關係型別，比如“通話關係”，“轉賬關係”，“微博關注關係”等；
4. Edge: 邊，用於表示一個個具體的聯絡。JanusGraph的邊都是單向邊。如果需要雙向邊，則通過兩條相反方向的單向邊組成。JanusGraph不存在無向邊。
5. Property Key：屬性的型別，比如“姓名”，“年齡”，“時間”等。Property Key有Cardinality的概念。Cardinality有SINGLE、LIST和SET三種選項。這三種選項分別用於表示一個Property中，對於同一個Property Key是隻允許有一個值、允許多個可重複的值，還是多個不可重複的值。
6. Property：屬性，用於表示一個個具體的附加資訊，採用Key-Value結構。Key就是Property Key，Value就是具體的值。

關鍵點（來自官網）

• 彈性和線性可擴充套件性，適用於不斷增長的資料和使用者群。
• 用於效能和容錯的資料分發和複製。
• 多資料中心高可用性和熱備份。
• 支援ACID和 最終的一致性。
• 支援各種儲存後端：
  • Apache Cassandra
  • Apache HBase
  • Google Cloud Bigtable
  • Oracle BerkeleyDB
• 通過與大資料平臺整合，支援全域性圖形資料分析，報告和ETL：
  • Apache Spark
  • Apache Giraph
  • ApacheHadoop
• 支援以下方式進行geo、資料範圍搜尋和全文搜尋：
  • ElasticSearch
  • Apache Solr
  • Apache Lucene
• 與Apache TinkerPop圖形堆疊本機整合：
  • Gremlin圖查詢語言
  • Gremlin圖伺服器
  • Gremlin應用程式
• Apache 2許可下的開源
• 工具視覺化儲存在JanusGraph中的圖形：
  • Cytoscape
  • Apache TinkerPop 的 Gephi外掛
  • Graphexp
  • Cambridge Intelligence 的 KeyLines
  • Linkurious

整體架構（來自官網）

JanusGraph是一個圖形資料庫引擎。JanusGraph本身專注於緊湊圖形序列化，豐富的圖形資料建模和高效的查詢。
JanusGraph利用Hadoop進行圖形分析和批處理圖處理。
JanusGraph為資料永續性、資料索引和客戶端訪問實現了強大的模組化介面。JanusGraph的模組化架構使其能夠與各種儲存、索引和客戶端技術進行互操作; 模組化架構還簡化了JanusGraph簡化了支援新的一個 模組的流程。

如何使用：

作為一個資料庫系統，它是要用來為應用程式儲存資料用的，那麼應用程式應該如何使用JanusGraph來為自己儲存資料呢？　　
一般來說，應用程式可以通過兩種不同的方式來使用JanusGraph：

1. 第一種方式：可以把JanusGraph嵌入到應用程式中去，JanusGraph和應用程式處在同一個JVM中。應用程式中的客戶程式碼（相對JanusGraph來說是客戶）直接呼叫Gremlin去查詢JanusGraph中儲存的圖，這種情況下外部儲存系統可以是本地的，也可以處在遠端
2. 第二種方式：應用程式和Janus Graph處在兩個不同JVM中，應用通過給JanusGraph提交Gremlin查詢給GremlinServer，來使用JanusGraph，因為JanusGraph原生是支援Gremlin Server的。

Gremlin Server是Apache Tinkerpop中的一個元件

JanusGraph叢集包含一個、或者多個JanusGraph例項。每次啟動一個JanusGraph例項的時候，都必須指定JanusGraph的配置。在配置中，可以指定JanusGraph要用的元件，可以控制JanusGraph執行的各個方面，還可以指定一些JanusGraph叢集的調優選項。

• 最小的JanusGraph配置只需要指定一下JanusGraph的後端儲存系統，也就是它的持久化引擎。
• 如果要JanusGraph支援高階的圖查詢，就需要為JanusGraph指定一個索引後端。
• 若果要提升JanusGraph的查詢效能，就必須為JanusGraph指定快取，指定效能調優的選項。

以上提到的後端儲存系統、索引後端、快取、調優選項等都可以在JanusGraph的配置檔案中進行指定。預設情況下它的配置檔案存放在JanusGraph_home/conf目錄下。

storage.backend=cassandra
storage.hostname=localhost

index.search.backend=elasticsearch
index.search.hostname=100.100.101.1, 100.100.101.2
index.search.elasticsearch.client-only=true

也可以在寫測試用例時程式碼控制：

/**
* 建立一個JanusGraph例項
* @return JanusGraph的一個例項
*/
private static JanusGraph create() {
    try {
        return JanusGraphFactory.build()
                .set("storage.backend", "hbase")
                .set("storage.hostname", "100.900.140.610,100.90.105.140,100.90.140.110")
                .set("storage.port", "10000")
                .set("storage.hbase.table", "hdp:Network")
                .set("cache.db-cache", "true")
                .set("cache.db-cache-clean-wait", "20")
                .set("cache.db-cache-time", "180000")
                .set("cache.db-cache-size", "0.5")
                .set("index.relationalNetwork.backend", "elasticsearch")
                .set("index.relationalNetwork.hostname", "100.148.90.140,100.148.90.150,100.148.90.106")
                .set("index.relationalNetwork.port", 9000)
                .open();
    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }
}

其他：

ETL

ETL，是英文 Extract-Transform-Load 的縮寫，用來描述將資料從來源端經過抽取（extract）、互動轉換（transform）、載入（load）至目的端的過程。
目的是將企業中的分散、零亂、標準不統一的資料整合到一起，為企業的決策提供分析依據。
ETL的設計分三部分：資料抽取、資料的清洗轉換、資料的載入。在設計ETL的時候我們也是從這三部分出發。資料的抽取是從各個不同的資料來源抽取到ODS(Operational Data Store，操作型資料儲存)中——這個過程也可以做一些資料的清洗和轉換)，在抽取的過程中需要挑選不同的抽取方法，儘可能的提高ETL的執行效率。ETL三個部分中，花費時間最長的是“T”(Transform，清洗、轉換)的部分，一般情況下這部分工作量是整個ETL的2/3。資料的載入一般在資料清洗完了之後直接寫入DW(Data Warehousing，資料倉儲)中去.
詳情：https://www.cnblogs.com/yjd_hycf_space/p/7772722.html

OLTP與OLAP

• 用於聯機事務圖的持久化技術（通常直接實時地從應用程式中訪問）。這類技術被稱為圖資料庫，它們和“通常的”關係型資料庫世界中的聯機事務處理（Online Transactional Processing，OLTP）資料庫是一樣的。
• 用於離線圖分析的技術（通常都是按照一系列步驟執行）。這類技術被稱為圖計算引擎。它們可以和其他大資料分析技術看做一類，如資料探勘和聯機分析處理（Online Analytical Processing，OLAP）。

refer:
http://www.cnblogs.com/zhangzl419/p/9100498.html
http://www.itboth.com/d/NBVZjy/hbase