「Learning Neo4j」Chapter3 Getting Started with Neo4j（Neo4j入門）翻訳してみた Part1（主要な概念と特性、ユースケース、ライセンス）

「Learning Neo4j」（Packet Publishing出版で、現時点で電子書籍はNeo4j公式サイトから無料でダウンロードできる）のChapter3 Getting Started with Neo4j、翻訳してみた。
「Learning Neo4j」に関しての概要は下記記事等参照。


 http://techinfo4dog.blogspot.com/2015/09/learning-neo4jneo4jneo4j.html

Neo4j入門

本章では、 世界有数のグラフ型データベースNeo4jについて学ぶという、この本の主題にぐっと近づきます。本章では、 次の章から実世界のモデルやユースケースでNeo4jを使い始められるよう、Neo4jのデータベースマネージメントシステムに慣れていきましょう。
本章では、次のトピックについて説明します。

• Neo4jの主要な概念と特性
• Neo4jに最適なユースケース
• Neo4jののライセンスモデル
• Neo4jのインストール
• クラウド上でのNeo4jの利用

それでは、最初の話題から始めましょう。 

Neo4j　-　主要な概念と特徴

Neo4jの詳細について語る前に、 特にグラフ型データベースマネージメントシステムとしてのNeo4jの主要な特徴についてみていきましょう。強みの一部を理解する助けになるでしょう。

 新規のグラフ型システム構築

多くのオープンソースプロジェクトや、オープンソースのNoSQL系データベースマネージメントシステムと同様に、Neo4jも非常に具体的な理由があり、存在しています。悩みの解決、と呼ばれるものです。この問題を解決しようとして古典的な技術を積み重ねて苦労している開発者は、急進的な新しい方法を試してみることにしました。それはNeo4jの創設者が21世紀初頭に行ったことで、とあるメディア企業のために、メディアの資産をよりよく管理するための問題を解決できる何かを構築しました。
初期には、Neo4jはグラフ型データベースマネージメントシステムとしては不十分でした。
Neo4は、接続されたデータ構造をより簡単な方法でコード内で取り扱うことができるグラフ型ライブラリのようなものでした。MySQL（や、他の）リレーショナルデータベースマネージメントシステムの上で動作させ、グラフ型の抽象的なレイヤーを作ることに特化していました。
明らかに、これでは十分ではありませんでした。しばらくして、オープンソースプロジェクトは、MySQLのインフラストラクチャから離れ、新たにグラフを保存できるシステムを構築することを決めました。
ここで重要なことは、まったく新たに構築した、ということです。インフラストラクチャ全体では、グラフ型データベースのストアファイルのバイナリーファイルレイアウトといった低いレベルのコンポーネントを含み、グラフ型のデータを扱うために最適化されました。スピードやその他多くの改善を行い、Neo4jがほかのデータベースマネージメントシステムと競えるようにする基盤になるという意味で、様々な点で重要なことです。
この本では、基盤となるファイル構造の詳細な理解を必要としません。あえて言うなら、特定のワークロードに合わせて調整されるネイティブ、グラフ指向のストレージフォーマットである、と理解してください。つまり、読者にとっては大きな違いというわけです。

トランザクション、ACID特性準拠のデータベース

Neo4jは、ACID特性に準拠したデータベースです。その特性を説明するために、ACID特性がそもそも何を意味するのかを説明しましょう。基本的には、 ACID特性の各頭文字（A、C、I、D）は、多くのデータベース管理システムが目標とする、もっとも古い４つの到達点を意味します。

• A（Atomicity：原子性） ：データベースへの変更は、すべて行われるか全く行われないかのどちらかになります。もしトランザクションの一部が失敗した場合、トランザクション全体がロールバックされる場合、トランザクションは「原子性がある」と言われます。
• C（Consistency：一貫性） ： 一貫性があるか、有効なデータのみデータベースに挿入できることを意味します。具体的には、多くの場合にデータベースのスキーマは常時適用され、維持されなければならないことを意味します。Neo4jで一貫性に関する要求としては、グラフ型の関連性は、スタートノードとエンドノードを持つ必要があることです。関係性は、ぶら下げることができません。（訳注：ノードがネットワークのように関連して上下を指定できないということ？？？）これは別として、Neo4jは「オプショナルスキーマ」（訳注：任意スキーマ？　どう訳す？）のコンセプトを持ち、Neo4jの一貫性ルールははるかにゆるいものとなります。Neo4jの「オプショナルスキーマ」は非常に興味深いものです。開発サイクルが始まったばかりの時点で、スキーマフリーのデータベースが実際に信じられないほど便利であることに気が付くでしょう。ドメインや要求について知識に磨きをかければかけるほど、イテレーション上に必要とされるスキーマが増え、データモデルは成長し続けるでしょう。（訳注：このハイフンのつながり方が良く分からない）しかしながら、製品に近づけば近づくほど、一貫性のあるスキーマは確かに便利になっていきます。その時点で、システム管理者や企業の経営者は、データの品質に置いてよりチェックされバランスが取れたものを同様にほしがり、ACID特性の中でCが特に重要なものとなります。Neo4jは現在のアジャイル開発手法で大いに有用である両方のアプローチを完全にサポートしています。
•   I（Isolation：独立性）：同じデータベースインスタンスに並列に実行される複数のトランザクションがお互いに影響を与えないことが求められます。トランザクションは、システムで同時刻に何が起こっているかに関係なく、順を追って実施される必要があります。このことが特に重要だとされる一礼としては、一つのトランザクションがデータベースに書き込んでいる最中に、別のトランザクションがデータベースを読んでいる状況です。独立性があるデータベースでは、読みこみのトランザクションは、書き込みの処理が完全に終わってコミットされるまで、次に発生する書き込みトランザクションについて知ることはできません。書き込み処理がコミットされない限り、読み込み処理は、古い（訳注：書き込みによって更新される前の）データを読むことになります。
• D（Durability：耐久性）：基本的には、コミットされた処理は消えたり失われたりしないことを意味します。Neo4jを含むほとんどのデータベースでは、永続ストレージとトランザクションコミットログは、正しいデータ構造がまだアップデートされていなくても、ディスクに強制的に書きこまれることが保障されています。

これらのすべての概要は、Neo4jが、本当に、真の多目的データベーススタイルソリューションを目指して新たに設計されたことを意味します。 密に接続されたユースケースに適用した根本的に異なるデータモデルを使っていますが、現在知られている伝統的な関係データベースマネージメントシステムと品質面ではたくさんの部分を共用しています。

オンライントランザクション処理のために作られました

上記の特徴は、オンラインシステム環境からデータベースマネージメントシステムを介してデータを返す必要がある場合に、助けとなります。
データベースマネージメントシステムに問い合わせたクエリは、WebリクエストとWebレスポンスの間のタイムスパンで返す必要があることを意味しています。つまり、何秒、何分放置してから返す、ではなく、ミリ秒単位で結果を帰すということです。
この特徴は、すべてのデータベースマネージメントシステムに要求されるものではありません。多くのシステムでは、最初にリクエストを投げてから何時間も経ってから結果を返せばよいのです。リレーショナルデータベースの世界では、こういったシステムを分析システムと呼びます。2つのタイプのシステムの違いについては、オンライントランザクション処理（Online Transaction Processing。OLTP）、オンライン分析処理（Online Analytical Processing。OLAP）の違いを参照してください。これらの２つは、技術的な面、コンセプトの面から、大きな差があります。それでは 、 次の表でその二つを比較してみましょう。




当記事の執筆時点で、Neo4jはOLAP側のデータベースシステムであることが明らかです。それは、分析のタスクにNeo4jを利用できないという意味ではありません。
実際に、リレーショナルデータベースの世界では、グラフ型データベースの上で非常に効率的に分析タスクが実行されています（スウィートスポットクエリーの章をご参照ください）が、最適化されてはいません。
Neo4jで推奨される典型的な実装では、生産向けOLTPクエリに影響を与えないよう、分析のワークロード用の別のNeo4jインスタンスを置くことを推奨しています。　将来的には、 ネオテクノロジー社は、Neo4jがOLAPタスクに更に適用性が良くなるような機能強化を計画しています。

 スケーラビリティ設計

OLTPのワークロードに対処するために、Neo4jは拡張性、高可用性、フォールトトレランスの要求をサポートする必要があることは明らかです。一般的に、この問題を解決する前に、目的を達成するためのデータベースサーバインスタンスのクラスタが作られます。Neo4jのエンタープライズ版では、挑戦的なワークロードをサポートできるクラスタリングソリューションを提供しています。

Neo4jの高可用性アーキテクチャ

上図からわかるように、Neo4jのクラスタリングソリューションは、 マスター・スレーブ型です。特定のクラスタでは、クラスタの各サーバインスタンスは、以下の順で実行されます。

• データベースのデータセット全体を保持します。すべてのサーバーが同じデータを保持する ため、すべてのクエリ要求に応答することができます。
• マスター・スレーブの一貫性スキーマに準拠します。これは、データベースに潜在的に競合するデータがあった場合、保持し、継続するデータはどれなのかはマスターサーバインスタンスが決定することを意味します。
• もしクラスタはマスターを失った場合、残ったクラスタのメンバーインスタンスは、マスター選択アルゴリズムに基づき（Neo4jの場合、Paxosアルゴリズム（訳注：https://ja.wikipedia.org/wiki/Paxos%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0）　に基づいています）、新しいマスターをすぐに選択します。
• サーバは、クラスタでヒットした特定のクエリサブセットを取り扱うのに最適化されている必要があります。例えば、ロードバランサは、特定のタイプのクエリ（例えば、書くクエリと読み取りクエリが競合した場合、特定の地域に対するクエリ、特定のアプリケーションからのクエリ）が特定のクラスタメンバーに向けられるよう、構成されます。そのように校正される利点としては、Neo4jはキャッシュの最適化が許可されており、「共有キャッシュ」と呼ばれる概念を利用できるということです。これは、クラスタのメンバーがデータベースストアファイル内に同じデータセットを持つことができ、メモリやキャッシュの中では、グラフの違う部分を持つことを意味します。他のデータベースマネージメントシステムと同様に、クエリーはキャッシュを使うことでさらに高速化されます。クラスターの最適化を試みます。

もし運命のねじれでクエリが正しいインスタンスで終了しない場合でも、アプリケーションが機能を停止することはありません。キャッシュから応答しないため、応答が少し遅くなるだけです。
Neo4jのクラスタリングソリューションを使用すると、以下の機能が利用できます。

• 水平方向のスケーラビリティ ：クラスタにマシンを追加し、クラスタメンバ間で負荷を分散することができます。
• 垂直方向のスケーラビリティ ：クラスタのメンバーであるマシンにもっと馬力（CPU、メモリ、ディスクなど）を追加することができます。

ネオテクノロジー社曰く、99%のユースケースをカバーします。

宣言型クエリ言語　サイファー

現在、Neo4jのグラフ型データベース製品を決定づける特徴の一つとして、サイファーと呼ばれる素晴らしいクエリ言語があります。サイファーは宣言的で、グラフ型データベースマネージメントシステムを形作るパターンマッチングクエリ言語で、技術的な理解が少なくとも、あらゆるデータベースユーザにとって理解でき実行可能なものです。
私の意見としては、サイファーの主要な特徴として、これまで存在してきたほかの命令型クエリ言語と違って、宣言的な言語であるということです。  これがなぜ重要なのですか？　答えを以下に示します。 

• 宣言型の言語は、探しているものを宣言し、検索したいパターンについて述べ、データの検索方法についてはデータベースが考えます。
• 命令型（クエリ）言語では、 何のデータを取得するか、取得するために何を行うか、データベースに指示する必要があります。

• 宣言型の言語は、問題について述べる部分と解決する部分を分離します。その結果、書いたクエリを非常に読みやすくなります。人々にとっては、クエリを書くよりも読むほうが多い傾向があるので、重要なことです。それゆえに、ソフトウェアの一部は読みやすく、他人とシェアしやすくなり、読みやすいクエリをが使われていると、ソフトウェアの長期メンテナンスがより簡単になります。
• 宣言型の言語では、質問にもっと効率的に返答するため、データの性質や構造について保持された情報を使えます。基本的に、必要不可欠な方法だと知りも思いもしなかったクエリ最適化が利用できます。  それゆえに、少なくとも、時間が経ち、最適化アルゴリズムが成熟するにつれ、宣言的な言語は早くなり得ます。
• 宣言型言語は、複雑なソフトウェアルーチンを記述することなく、データベースでアドホッククエリ（訳注：https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%9B%E3%83%83%E3%82%AF）　を実行するのに最適です。

私がサイファーをNeo4jの重要な一部分と感じる理由は、我々は宣言型言語が、特にデータベースマネージメントシステムの世界では広く採用されていることを知っているからです。大半のアプリケーション開発者は、自分のデータをどのように最適に処理するかについて心配する必要がありません。アプリケーション開発者は、ビジネスロジックや、データがほしいときにほしいようにあることに焦点を当てたいと考えています。これは、リレーショナルデータベースが70年代にどのように進化したかを参照してください。（Chapter2　グラフ型データベースオーバビュー　参照。）
グラフ型データベースマネージメントシステムの世界でも、かなり似た進化がなされるでしょう。サイファーは、それゆえに、ユニークな位置にあり、データベースを扱う仕事をより簡単にします。サイファーは現在既に　驚くべきツールとして存在しており、今後より良くなる一方でしょう。

Neo4jのスイートスポットのユースケース（訳注：Neo4jを利用するのに最適なユースケース）

多くのソフトウェア・エンジニアリング・ツールと同様に、Neo4jも、プロセスに輝きを与え、たくさんの価値を上乗せできる特定のタイプのスイートスポットのユースケースを持っています。
多くのツールはいろいろなことができ、Neo4jも同様ですが、特定のツールを使うことでより良いことができるユースケースがあります。前の章で、これらユースケースの一部については既に言及しています。しかし、Neo4jのソフトウェアパッケージについて特に要約すると、2つのユースケースタイプ、特に2つのタイプのデータベースクエリに特に効果があると思っています。

 複雑で、JOINを内包するクエリ

前の章で、リレーショナルデータベースマネージメントシステムには、非常に複雑なデータモデルを取り扱う際に重大な欠点があることについて言及しました。
クエリを含むフルインデックスが付けられたテーブルで集合のデカルト積（訳注：直積集合。https://ja.wikipedia.org/wiki/%E7%9B%B4%E7%A9%8D%E9%9B%86%E5%90%88）　を計算するようなリレーショナルデータベースを考えてみてください。その計算は、大きなデータセットや、二つ以上のテーブルを含むデータセットでは非常に時間がかかります。
グラフ型データベースマネージメントシステムでは、これらの問題に苦しむことはありません。JOIN処理は、接続されたノードの関係を元に、効率的に事前に計算され、永続化されます。  そのため、データのJOINは、一つのノードから別のノードにポインタを使って飛ぶくらい単純です。リレーショナルデータベースの世界では難しかった複雑なクエリは、グラフ構造の元では効率化、かつ高速に処理できます。

パス発見クエリ

Neo4jのたくさんのユーザは、ネットワークの違ったノード間を通る最適なパスを見つけるのにグラフ構造を使います。このフレーズが有用なのは、処理の世界で、ネットワーク上の特定のパスを探しているときです。

• パスが実際に存在するかどうか確認します。２つのデータ要素の間に接続関係があるかどうか、そして存在する場合、どのようにつながっているか。
• 最適なパスを探します。二つのデータ要素を結ぶパスで最も「コスト」が低いパスはどれか。
• パスの特定の部分が変わった場合に、変化した部分を探します。ノードのプロパティや関係性が変わった場合に、パスに何が起きるか？

これらのスイートスポットのユースケースの両方に、重要な特性の組み合わせがあります。

• 「グラフの内部」（訳注：？）であり、グラフ型データベースのエンジンが開始できる、１つあるいは複数の特定の開始ポイントか、「アンカー」を持ちます。
•  「クリックストリーム」（訳注：http://e-words.jp/w/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0.html　　？？）で行われ、ほぼリアルタイムのデータに対して実行されます。

それでは、グラフ型データベースマネージメントシステムとしてNeo4jが成功した他の重要な要素を見ていきましょう。オープンソースソリューションであること、です。

 オープンソースへのコミット

エンタープライズ向け情報技術でこれまで何が起こったかを見てきた中で重要なこととしては、ビジネスのクリティカルアプリケーションへのオープンソーステクノロジーの大規模な採用があります。
Webサーバ（かつてはWebサーバは静的なWebページを提供していた）といった周辺システムから始まり、少なくとも直近10年は進化し続けており、ミッションクリティカルな業務システム、コンテンツ管理アプリケーション、CRMシステム（訳注：顧客管理システム。https://ja.wikipedia.org/wiki/%E9%A1%A7%E5%AE%A2%E9%96%A2%E4%BF%82%E7%AE%A1%E7%90%86）、Neo4jといったデータベースへと徐々に進化しています。
オープンソースソフトウェアには、たくさんの興味深い面があります。頻繁に引用されるいくつかを以下に記載します。

• ベンダーロックインから解放します。 ソースコードが容易に利用可能であるため、ソフトウェアのユーザは自分でコードを読み、どのように動作するか（、拡張するか、修正するか、検査するか）を理解することができるため、特定のベンダーに支配されることはなくなります。
• セキュリティが向上します。 ソースコードが聴衆にさらされており、開発者が「セキュリティに関して明確ではない部分」（たとえば、誰も知らなかったりリバースエンジニアリングする必要があったりする部分）を含むことはできないため、オープンソースソフトウェアは本質的に安全です。
• サポートやトラブルシューティングが簡単です。 ：ベンダーと顧客の両方がソースコードにアクセスできるため、詳細についてや運用中のシステムのデバッグレベルの情報のやり取りが簡単で、問題を特定するのが簡単です。
• 拡張性がありより革新的 ソースコードを公開することで、たくさんの人々が、オリジナルの開発者が知ることなく、ソフトウェアをいろいろな方向で使い始めます。彼ら「コミュニティ貢献者」はソフトウェアで発生する問題を解決したり、彼ら自身のユースケースで活用したりするため、製品のより速い革新や拡張につながることになります。
• （基本および応用）研究支援 ：オープンソース・ソリューションは、Neo4jのようにエンタープライズ向けの商用の機能をがあるものも含め、研究者は大抵無料で利用することが許可されています。研究者達は、自分たちの研究成果もオープンソースとして世に出しました。双方向になっています。
• 安価 ：オープンソースソフトウェアは、「フェア」ライセンスモデルを使う傾向があります。ソフトウェアから価値を得たのに、そのコードを提供できない場合のみ、支払が生じます。（訳注：オープンソースを使って何かを作る場合、成果物はオープンソースとして公開する必要があるが、有料のエンタープライズ版等を使うことで公開しなくても良くなるものがある。Neo4jもその一つ。）開始時点で安く済ませられるということだけではなく、エンタープライズ用途でも限られた投資でスタートし、利用拡大に伴い徐々に成長させることができることを意味します。

 私はすべての項目がNeo4j運用において正しいことだと信じています。では、ライセンスモデルを決定するための異なるパラメータ軸についてみていきましょう。
続く章で説明されている3つのパラメータはどれも重要なものです。

特徴

Neo4jは、グラフ型データベースマネージメントシステムに関して、エディションごとに異なる機能セットを持たせて提供しています。

• コミュニティ版 ：基本的なもので、完全に動作する高性能なグラフ型データベースです。
• エンタープライズ版：コミュニティ版に、いくつかのエンタープライズ用の特定の機能を乗せたものです。クラスタリング（高可用性、ロードバランシング）、高度なモニタリング機能、高度なキャッシング機能、オンラインバックアップです。ネオテクノロジー社はエンタープライズ版のロードマップとして、追加機能を準備しています。

Neo4jのユーザの大半はコミュニティ版で始め、エンタープライズ版にデプロイ（訳注：乗せ換え）します。

サポート

Neo4jのエディションによって、サポートチャンネルが異なります。

• コミュニティ版には、「コミュニティサポート」を提供しています。パブリックフォーラムに対して質問を投げたり検索したりすることです。Google Group、Stack Overflow、Twitter、その他のチャンネルがあります。ただし、 以下の点に注意してください。
• 応答（訳注：コミュニティサポートに投げた質問・回答）は公開する必要があり、秘密にはできません。
• 応答があることや、応答が返ってくるまでの時間は保障されていません。
• ネオテクノロジー社はコミュニティユーザをサポートするために一流のエンジニアをつけてはいますが、一日のサポート数に制限があります。
• エンタープライズ版には 、24時間365日利用可能 であるプロ級のサポートチームを提供しています。応答保障時間がつき、優先順位が異なるサポートがあります。執筆時点で、ネオテクノロジー社は、顧客が直接情報を得られるよう、Neo4j開発エンジニアへの直接アクセスを提供しています。

 Neo4jのサポートプログラムは、一般的にはプロセスの開始時（開発チームが新しい技術を使い始めた時）に最も必要とされるものですが、しばしば開発サイクルの最後にも求められます。

ライセンス条項

少しだけ複雑な案件にも対応できるよう、ネオテクノロジー社は、Neo4jに対して、少しだけ複雑に見えますが、以下について確実な目的をサポートする、明確ななライセンス期間を設けています。

• オープンソースソフトウェアの推進
• Neo4jのコミュニティ開発の推進
• 収入源があることで、Neo4jのプロジェクトの長期的な実行可能性を保証（訳注：収入源がないと突然サポート打ち切りになるとかリスクがあったりするってことですね）

これは、以下の方法で実現されています。

• コミュニティ版は、ライセンス条項としてGNU Public License Version3（GPLv3）を採用しています。これは、ソースファイルの変更日時の軌跡をたどる限りソフトウェアのコピー、配布、修正することができ、GPUの元で修正され続けることを意味します。開発したアプリケーションをGPLの元で商用配布することができますが、ソースコードを提供する必要があります。従って、ウィルスのように広がるライセンスで、開発したコードをオープンソースにすることが求められます。ただし、開発したコードがJava APIを介して直接つながっている場合に限ります。もしREST APIを使っている場合、ほとんど、あるいはまったく影響しません。
• エンタープライズ版は、いわゆるデュアルライセンスモデルを使用しています。これは Neo4jのエンタープライズ版のユーザーは2つのオプションから選択することができることを意味します。
• どちらも、「Web用GPL」と呼ばれる、Affero GNU Public License Version 3（AGP Lv3）に準拠しています。 

AGPLライセンスは、 ネットワークソフトウェアのために作られたという点で、他のGNUライセンスとは異なります。AGPLは、GPLと同じようなものですが、GPUよりさらにウィルス的で、Neo4jのJava APIを介してコードを同じマシンからリンクさせるだけではなく、Neo4jのREST APIを介してネットワーク越しのマシンに接続する場合にも適用されます。つまり、エンタープライズ版を無料で使っている場合、開発したコードをオープンソースにする必要があります。

• ネオテクノロジー社の商用ライセンス（NTCL）を取得します。このライセンスは、典型的な商用サブスクリプションライセンス条項で、一定期間、一定数のマシン、インスタンスにNeo4jのエンタープライズ版を使用する権利が与えられます。

上記のすべての点は、以下の図に要約されています。

Neo4jのライセンス概要

前図に示した通り、ネオテクノロジー社はいくつかの商用サブスクリプションオプションを提供しています。展開するインスタンスの数、会社のタイプ（ベンチャー、中小企業、大企業）、法的な合意要件、サポート契約によって決まります。定期的に変更されているこれらの情報について確認したい場合には、sales@neotechnology.com　に連絡してください。
Neo4jを異なるプラットフォーム上で動かすために手を汚さずにすみます。

訳注：Neo4j公式サイト上でのライセンスの説明については、以前以下で公開。（2015年8月時点の情報。）


http://techinfo4dog.blogspot.com/2015/08/neo4jneo4j.html



Intalling Neo4j以下は、Part2で公開予定。



＊＊＊＊＊＊＊＊＊以下、翻訳時点での原文コピー。最新情報については原本（Learning Neo4j）を参照してください。＊＊＊＊＊＊＊＊＊＊＊

Getting Started with Neo4j

In this chapter, we will be taking a much closer look at the real subject of this book, that is, learning Neo4j—the world's leading graph database. In this chapter, we will be going through and familiarizing ourselves with the database management system so that we can start using it in the following chapters with real-world models and use cases.

We will discuss the following topics in this chapter:

• Key concepts and characteristics of Neo4j
• Neo4j's sweet spot use cases
• Neo4j's licensing model
• Installing Neo4j
• Using Neo4j in the cloud

Let's start with the first topic straightaway.

Neo4j – key concepts and characteristics

Before we dive into the details of Neo4j, let's take a look at some of the key characteristics of Neo4j specifically as a graph database management system. Hopefully, this will immediately point out and help you get to grips with some of the key strengths as well.

Built for graphs, from the ground up

Like many open source projects and many open source NoSQL database management systems, Neo4j too came into existence for very specific reasons. Scratching the itch, as this is sometimes called. Grassroots developers who want to solve a problem and are struggling to do so with traditional technology stacks, decide to take a radical, new- found approach. That's what the Neo4j founders did early on in the 21st century—they built something to solve a problem for a particular media company in order to better manage media assets.

In the early days, Neo4j was not a full-on graph database management system

—it was more like a graph library that people could use in their code to deal with connected data structures in an easier way. It was sitting on top of traditional, MySQL (and other) relational database management systems and was much more focused on creating a graph abstraction layer for developers than anything else.

Clearly, this was not enough. After a while, the open source project took a radical decision to move away from the MySQL infrastructure and to build a graph

store from the ground up. The key thing here is from the ground up. The entire infrastructure, including low-level components such as the binary file layout of the graph database store files, is optimized for dealing with graph data. This is important in many ways, as it will be the basis for many of the speed and other

improvements that Neo4j will display versus other database management systems.

We don't need to understand the details of this file structure for the basis of this book—but suffice to say that it is a native, graph-oriented storage format that is tuned for this particular workload. That, dear reader, makes a big difference.

Transactional, ACID-compliant database

Neo4j prides itself in being an ACID-compliant database. To explain this further, it's probably useful to go back to what ACID really means. Basically, the acronym is one of the oldest summaries of four goals that many database management systems strive for, and they are shown in the following figure:

• Atomicity: This means that changes in the database must follow an all or nothing rule. Transactions are said to be "atomic" if one part of the

transaction fails, then the consequence would be that the entire transaction is rolled back.

• Consistency: This means that only consistent or "valid" data will be allowed to be entered into the database. In relational terminology, this often means that the schema of the database has to be applied and maintained at all times. The main consistency requirement in Neo4j is actually that the graph relationships must have a start and an end node. Relationships cannot be dangling. Aside from this, however, the consistency rules in Neo4j will obviously be much looser, as Neo4j implements the concept of an "optional" schema.

The optional schema of Neo4j is really interesting: the idea being that it is actually incredibly useful to have a schema-free database when you are still at the beginning of your development cycles. As you are refining your knowledge about the domain and its requirements, your data model will just grow with you—free of any requirements to pre-impose a schema on your iterations. However, as you move closer to production, schema—and therefore consistency—can be really useful. At that point, system administrators and business owners alike will want to have

more checks and balances around data quality, and the C in ACID will become more important. Neo4j fully supports both approaches, which is tremendously useful in today's agile development methodologies.

• Isolation: This requires that multiple transactions that are executed in parallel on the same database instance would not impact each other. The transactions need to take their due course, irrespective of what is happening in the system at the same time. One of the important ways that this is used is in the example where one transaction is writing to the database and another is reading from it. In an isolated database, the read transaction cannot know about the write that is occurring "next to" it until the transaction of the write operation is complete and fully committed. As long as the write operation is not committed, the read operation will have to work with the "old" data.
• Durability: This basically means that committed transactions cannot just disappear and be lost. Persisted storage and transaction commit logs that are forced to be written to disk—even when the actual data structures have not been updated yet—ensure this quality in most database systems and also in Neo4j.

The summary of all this is probably that Neo4j, really, has been designed from the ground up to be a true multipurpose database-style solution. It shares many of the qualities of a traditional relational database management system that we know today—it just uses a radically different data model that is well suited for densely connected use cases.

Made for Online Transaction Processing

The mentioned characteristics help with systems where you really need to

be returning data from the database management system in an online system environment. This means that the queries that you want to ask the database management system would need to be answered in the timespan between a web request and a web response. In other words, in milliseconds—not seconds, let alone minutes.

This characteristic is not required of every database management system. Many systems actually only need to reply to requests that are first fired off and then require an answer many hours later. In the world of relational database systems, we call these analytical systems. We refer to the difference between the two types of systems as the difference between Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP). There's a significant difference between the two—from a conceptual as well as from a technical perspective. So let's compare the two in the following table:

	Online Transaction Processing (Operational System)	Online Analytical Processing (Analytical System, also known as the data warehouse)
Source of data	Operational data; OLTPs are the original source of the data	Consolidation data; OLAP data comes from the various OLTP databases
Purpose of data	To control and run fundamental business tasks	To help with planning, problem solving, and decision support
What the data provides	Reveals a snapshot of ongoing business processes	Multidimensional views of various kinds of business activities
Inserts and updates	Short and fast inserts and updates initiated by end users	Periodic long-running batch jobs refresh the data
Queries	Relatively standardized and simple queries returning relatively few records	Often complex queries involving aggregations
Processing speed	Typically very fast	Depends on the amount of data involved; batch data refreshes and complex queries may take many hours
Space requirements	Can be relatively small if historical data is archived	Larger due to the existence of aggregation structures and history data; requires more indexes than OLTP
Database design	Highly normalized with many tables	Typically de-normalized with fewer tables; use of star and/or snowflake schemas
Backup and recovery	Backs up religiously; operational data is critical to run the business, data loss is likely to entail significant monetary loss and legal liability	Instead of regular backups, some environments may consider simply reloading the OLTP data as a recovery method

At the time of writing this, Neo4j is clearly in the OLTP side of the database ecosystem. That does not mean that you cannot do any analytical tasks with Neo4j.

In fact, some analytical tasks in the relational world are far more efficiently run on a graph database (see the sweet spot query section that follows later), but it is not optimized for it. Typical Neo4j implementation recommendations would also

suggest that you put aside a separate Neo4j instance for these analytical workloads so that it would not impact your production OLTP queries. In the future, Neo Technology plans to make further enhancements to Neo4j that make it even more suited for OLAP tasks.

Designed for scalability

In order to deal with the OLTP workload, Neo4j obviously needs to be able to support critical scalability, high availability, and fault-tolerance requirements. Creating clusters of database server instances that work together to achieve the goals stated before typically solves this problem. Neo4j's Enterprise Edition, therefore, features a clustering solution that has been proven to support even the most challenging workloads.

As you can see from the preceding diagram, the Neo4j clustering solution is a master-slave clustering solution. In a particular cluster, each server instance of the cluster will perform the following steps:

• Hold the entire dataset of the database. All servers hold the same data and therefore can respond to all query requests.
• Comply with a master-slave consistency scheme. This means that, in case of potential conflicting data in the database, the Master server instance will decide what would be right data to keep and persist. If at some point, the

cluster would lose its master, the remaining cluster member instances would run a master election algorithm (in Neo4j's case, based on Paxos) that allows them to quickly choose a new master.

• The server should be optimized to deal with a particular subset of the queries that hit the cluster. For example, the load balancer would be configured in such a way that specific types of queries (for example, write queries versus read queries, queries for a specific region/continent, and queries from a specific application) would be directed to a specific cluster member. The advantage of doing so is that this will allow Neo4j to optimize its caching content and use a concept that we sometimes refer to as a "sharded cache". This means that the cluster members may in fact be holding the same dataset in their database store files, but in memory, in the cache, they will hold very different parts of the graph. Similar to any database management system, queries served up from a cache will be much faster. So, we want to try and optimize the cluster for this. If by some twist of fate the queries don't end

up on the right instance, then that does not mean that the application will stop functioning. It will just not respond from cache, and therefore respond a bit slower.

Neo4j's clustering solution allows you to provide the following features:

• Horizontal scalability: This is provided by adding more machines to the cluster and distributing the load over the cluster members
• Vertical scalability: This is provided by adding more horsepower (CPU, memory, disks, and so on) to the machines that are the cluster members

This covers 99 percent of all use cases—the references of Neo Technology speak for itself.

A declarative query language – Cypher

One of the defining features of the Neo4j graph database product today is its wonderful query language, called Cypher. Cypher is a declarative, pattern-matching query language that makes graph database management systems understandable and workable for any database user—even the less technical ones.

The key characteristic of Cypher is, in my opinion, that it is a declarative language, opposed to other imperative query languages that have existed for quite some time. Why is this so important? Here are your answers:

• Declarative languages allow you to state what you're looking for, declare the pattern that you would like to see retrieved, and then let the database worry about how to go about retrieving that data.

In an imperative (query) language, you would have to tell the database specifically what to do to get to the data and retrieve it.

• Declarative languages separate the concern of stating the problem, from solving it. This allows greater readability of the queries that you write, which is important as people tend to read their database queries more often than they write them. This piece of your software will therefore become more readable and shareable with others, and long term maintenance of that easy-to-read query becomes so much easier.
• Declarative languages will allow the database to use the information that it holds about the nature and structure of the data to answer your question more efficiently. Essentially, it allows query optimizations that you would

never have known of or thought about in an imperative approach. Therefore, declarative languages can be faster—at least over time as the optimization algorithms mature.

• Declarative languages are great for adhoc querying of your database, without you having to write complex software routines to do so.

Part of the reason why I feel that Cypher is such an important part of Neo4j is that we know that declarative languages, especially in the database management systems world, are critical to mass adoption. Most application developers do not want to be worrying about the nitty gritty of how to best interact with their data. They want to focus on the business logic and the data should just be there when I want it, as I want it. This is exactly how relational database systems evolved in the seventies (refer to

Chapter 2, Graph Databases – Overview). It is highly likely that we will be seeing a similar evolution in the graph database management system space. Cypher, therefore, is in a unique position and makes it so much easier to work with the database. It is already an incredible tool today, and it will only become better.

Sweet spot use cases of Neo4j

Like with many software engineering tools, Neo4j too has its sweet spot use cases

—specific types of uses that the tool really shines and adds a lot of value to your process. Many tools can do many things and so can Neo4j, but only a few things can be done really well by a certain tool. We have addressed some of this already in the previous chapter. However, to summarize specifically for the Neo4j software package, I believe that there are two particular types of cases—featuring two specific types of database queries—where the tool really excels.

Complex, join-intensive queries

We discussed in the previous chapter how relational database management systems suffer from significant drawbacks, as they have to deal with more and

more complex data models. Asking these kinds of questions of a relational database requires the database engine to calculate the Cartesian product of the full indices on the tables involved in the query. That computation can take a very long time

on larger datasets, or if more than two tables are involved.

Graph database management systems do not suffer from these problems. The join operations are effectively precalculated and explicitly persisted in the database based on the relationships that connect nodes together. Therefore, joining data becomes as simple as hopping from one node to another—effectively as simple as following a pointer. These complex questions that are so difficult to ask in a relational world

are extremely simple, efficient, and fast in a graph structure.

Path finding queries

Many users of Neo4j use the graph structure of their data to find out whether there are useful paths between different nodes on the network. Useful in this phrase is probably the operative word; they are looking for specific paths on the network to:

• See whether the path actually exists. Are there any connections between two data elements, and if so what does that connectivity look like?
• Look for the optimal path. Which path between two things has the lowest "cost?"
• Look for the variability of the path if a certain component of the path changes. What happens to the path if the properties of a node or relationship change?

Both of these sweet spot use cases share a couple of important characteristics:

• They are "graph local" and they have one or more fixed starting point(s), or "anchor", in the graph from where the graph database engine can start traversing out
• They are performed "in the clickstream", and therefore performed on near-real-time data

Let's now switch to another key element of Neo4j's success as a graph database management system: the fact that it is an open source solution.

Committed to open source

One of the key things that we have seen happening in Enterprise information technology, is the true and massive adoption of open source technologies for many

of its business-critical applications. This has been an evolution that has lasted a decade at least, starting with peripheral systems such as web servers (in the days when web servers were still considered to be serving static web pages), but gradually evolving

to mission critical operating systems, content management applications, CRM systems and databases such as Neo4j.

There are many interesting aspects to open source software, but some of the most often quoted are listed as follows:

• Lower chance of vendor lock-in: Since the code is readily available, the user of the software could also read the code themselves and potentially understand how to work with it (and extend it, or fix it, or audit it, and so on) independently of the vendor.
• Better security: As the code is undergoing public scrutiny and because there is no way for a developer to implement "security through obscurity" (for example by using a proprietary algorithm that no one knows and would have to reverse engineer), open source software systems should be intrinsically more secure.
• Easier support and troubleshooting: As both the vendor and the customer have access to the source code, it should be easier to exchange detailed, debug-level information about the running system and make it easier to pinpoint problems.
• More innovation through extensibility: By exposing source code, many people left and right will start playing with the software—even without the original author knowing that this is going on. This typically causes these "community contributors" to solve problems that they encounter with the product, in their specific use case, and it leads to faster innovation and extensibility of the solution.
• Supporting (fundamental and applied) research: Open source solutions

—even the ones equipped with enterprise commercial features such as Neo4j—usually allow researchers to use the software for free. Most researchers also published their work as open source code. So, it's a two-way street.

• Cheaper: open source software tends to use "fair" licensing models. You only need to pay if you derive value from the software and are not able to contribute your code. This not only allows cheaper evaluation of the

software in the start of the process—hopefully avoiding unused shelfware

—but also allows enterprises to start with limited investments and grow gradually as the use expands.

I believe that all is true for Neo4j. Let's look at the different parameter axes that determine the license model. Three parameters are important, which are explained in the following sections.

The features

Neo4j offers different feature sets for different editions of the graph database management system:

• Community Edition: This is the basic, fully functional, high-performance graph database.
• Enterprise Edition: This adds a number of typical Enterprise features to

the Community Edition: clustering (for high availability and load balancing), advanced monitoring, advanced caching, and online backups. Neo Technology has a number of additional features lined up on the Enterprise Edition roadmap.

Most users of Neo4j start off with the Community Edition, but then deploy into production on the Enterprise Edition.

The support

Different support channels exist for Neo4j's different editions:

• The Community Edition offers "community support". This means that you are welcome to ask questions and seek support on the public forums (Google group, Stack Overflow, Twitter, and other channels). However, note the following points:
  • The responses will always need to be publicized (cannot be private)
  • The response will not be guaranteed or timed

Neo Technology does sponsor a significant team of top-notch engineers to help the community users, but at the end of the day, this formula does have its limitations.

• The Enterprise Edition offers a professional grade support team that is available 24/7, follows the sun, and has different prioritization levels with guaranteed response times. At the time of writing this, Neo Technology also offers direct access to its engineers that write the product so that customers can literally get first-hand information and help from the people that build Neo4j themselves.

The support program for Neo4j is typically something that is most needed at the beginning of the process (as that is when the development teams have most questions about the new technology that they are using), but it is often only sought at the end of a development cycle.

The license conditions

For the slightly more complicated bit, Neo Technology has chosen very specific licensing terms for Neo4j, which may seem a tad complicated but actually really supports the following goals:

• Promoting open source software
• Promoting community development of Neo4j
• Assuring the long-term viability of the Neo4j project by providing for a revenue stream.

This is achieved in the following ways:

• The Community Edition uses the GNU Public License Version 3 (GPLv3)

as its licensing terms. This means that you may copy, distribute, and modify the software as long as you track changes/dates of in source files and keep modifications under GPL. You can distribute your application using a GPL library commercially, but you must also provide the source code. It is therefore a very viral license and requires you to open source your code—but only if your code directly interfaces with the Neo4j code through the Java API. If

you are using the REST API, then there are little or no contamination effects and you can just use Neo4j at will.

• The Enterprise Edition uses a so-called dual license model. This means that users of the Neo4j Enterprise Edition can choose one of two options:
  • Either they adhere to the Affero GNU Public License Version 3 (AGPLv3), which is sometimes also referred to as the "GPL for the web".

The AGPL license differs from the other GNU licenses in that it was built for network software. Similar conditions apply as to the GPL; however, it is even more "viral" in the sense that it requires you to open source your code not only when you link your code on the same machine (through Neo4j's Java API), but also if you interface with Neo4j over the network (through Neo4j's REST API). So, this means that if you use Neo4j's Enterprise Edition for free, you have to open source your code.

• Get a Neo Technology Commercial License (NTCL). This license is a typical commercial subscription license agreement, which gives you the right to use Neo4j Enterprise Edition for a certain period of time, on a certain number of machines/instances.

All of the mentioned points are summarized in the following figure:

As indicated in the preceding figure, Neo Technology offers a number of different annual commercial subscription options, depending on the number of instances that you will deploy, the type of company you are (startup, mid-sized corporation, or large corporation), the legal contract requirements of the agreement, and the support contract. For more information on the specifics of these bundles—which change regularly—you can contact sales@neotechnology.com.

With that, we have wrapped up this section and will now proceed to getting our hands dirty with Neo4j on the different platforms available.