update.はじめにOrientDBを使用していてよかったところとイマイチなところが結構見えてきたので、イイところ悪いところをつらつら書きますイイところJavaでできているJavaでできているので、基本的にはプラットフォームに依存せずに環境を構築できる。使用するメモリサイズなどもVMで調整ができる。Luceneが使える文字列の検索のための索引を、Luceneで作ったアナライザで作ることができ、検索もLuceneベースで行える。グラフDBとして使え、ドキュメントDBのように柔軟グラフ理論に基づく検索が可能。テーブル定義を決め切らなくてもデータの挿入が可能。データ操作するためのAPIが豊富http://orientdb.com/docs/3.0.x/apis-and-drivers/JavaでできているのでJavaAPIとの親和性は高いと思われます。Gremlinに対応しているので、ほかのグラフDBと同じインターフェースを使って実装が可能。メモリモードがあるメモリモードでDBを作成すると、DBインスタンスを突発的に作成することができる。DockerがあるDockerが用意されているので、Javaのバージョンとかを気にせずに環境構築が簡単にできる。単体テストに使用しやすい!マスターシステムではTravisCIで単体テストをする際に、Dockerで起動し、メモリモードのDBを作ってテストしています。内容http://orientdb.com/download-previous/↑のページを見てわかる通り、月に2,3回バージョンが上がります。バグが治っているのはいいことですが、追従していくにはかなりつらいと思います。Insertできない。あと、Studioで大量のレコードを検索するSQLを実行して、OutOfMemoryが発生すると、レスポンスが返ってこず、操作できなくなる。VMのヒープ領域の指定は起動スクリプト(server.batやserver.sh)内にありますが、2GBが初期値で入っているので、調整するにもここを修正する必要がある。Bのサービスを起動するの手順でバックアップをリストアしたときに、バックアップに含まれるインデックスが壊れ、Insertなどをしようとすると、例外が発生してデータの操作ができなくなる。INDEXすると解消するが、これも環境次第では結構時間がかかるので嫌ですね。JavaAPIで書き込んでコミットしたはずがデータが登録されていないことがあるバージョン3.0.8内容MDMの書き込みAPIで発生しますが、POSTして、登録されたはずのデータが、GETしても取得できない時があり、DBにSELECT文を投げてみても取得できないことがある。DB起動して最初のリクエストで起きやすいような感触です。JavaのランタイムはJAVA_HOMEを見ているバージョン3.0.8内容Javaなので当たり前といえば当たり前ですが、JAVA_HOME環境変数をみて実行されます。開発しているアプリケーションがJava10だったりすると、同一マシン上でOrientDBを動かしたりしたい場合には少し面倒。違うバージョンのJavaで起動してしまうと、インデックスのリビルドをするときにエラーになったりする。起動スクリプト内でJAVA_HOMEを参照して実行しているので、使用したいJavaのディレクトリに書き換えるなどするとよいかもしれません。検索がまあまあ遅いバージョン3.0.8内容Luceneクエリなどを使って検索をすると、まあまあ時間がかかります。例はMDMのAPIのItemSourceのSearchです。UPDATEみたいな機能は実装されていない(TODOにはなっている)。悲観ロックできないので、トランザクション単位でのロックが難しく、処理フローなどを考慮しておかないと不整合が起きやすいかもしれないです。upLoginユーザーは見つかりませんでした。