Android用の9つのORMのベンチマーク

インターネットには、Android向けの特定のORMに関する断片的な情報がたくさんあります。 これまでのところ、私は主要なORMの定性的な比較に出くわしていません。 既存の記事は、いずれかのシステムのPRを叩き、テストを誤って設定したり、意図的に誤った設定を使用したり、テストに強力な敵を含めないことにより、競合他社を不利にします。



このテストは、むしろ私自身の興味のために実施されました。 なぜなら 多くのORMがあり、それらはすべて異なっています。既存のシステムについて客観的な見方をしたいと思います。



基本はAndroidDatabaseLibraryComparisonリポジトリです。 オリジナル記事はこちらです。 ご覧のとおり、著者は最初にGreenDaoをレビューに含めないようにしました。何度か尋ねられたとき、彼はまったく間違った設定でそれをオンにしました。



それとは別に、ほとんどのORMはまだ本格的ではなく、アノテーションや個別のサブクエリを使用せずにネストされたコレクションを持つオブジェクトの書き込みと読み取りをサポートするライブラリはほとんどありません。

テスト方法

2つのモデルがテストされました。 シンプル、いわゆる ポジョ ：





単純型、線形構造。 このオブジェクトは10,000コピーで作成され、コピーはコレクションに配置され、コレクションはORMを使用してデータベースに保存されました。 それは6回繰り返されました。



読み取り段階では、コレクションが読み取られ、読み取りフィールドが調整されて、最初にデータの書き込みと読み取りが制御され、2番目にトリッキーな遅延読み取りが回避されました。 読み取りごとに、アプリケーションはタスクマネージャーによって閉じられ、再び起動されました。 実際、Realm、DBFlow、GreenDaoなどの一部のORMには独自のキャッシュがあります。 また、記録直後、または連続して2回カウントすると、キャッシュで読み取りがほぼ瞬時に発生し、全体の結果がゆがめられます。 はい、これは利点と見なすことができ、ORMを選択するときに考慮する必要があります。



洗練されたモデル。 ネストされたリストを持つオブジェクト：





オブジェクトは50コピーで作成されました。 ネストされた各コレクションも50コピーで埋められました。 記録済み。 読み取り時に、データの正確性がチェックされました。



また、各テストは6回実行されました。 結果のグラフでは、列の数はランタイムの平均値です。

結果

たくさんの写真があるので、ネタバレの下で：

テスト参加者

1. レルム

本当に速い。 確かに、場合によっては純粋なSQLiteよりも高速です（SQLは単純なフラットアルゴリズムを使用していることに注意する必要があります。考えてみると、LEFT JOINを使用してデータベースへの呼び出し回数を減らすことができますが、それについて考える必要があります。ご希望の場合-ようこそ）。 強調すべきことは実装が非常に簡単です。 直感的。 大きな利点は、レルムが本格的なORMであることです。 つまり オブジェクトを保存する/オブジェクトを読む：内部コレクション、それらの関係について考える必要はありません。クレイジーな「Foreign ...」、「One-to-many ...」キーなどのツイストを注釈する必要はありません。 すべてがボックスで機能します。



しかし、欠点もあります。 それでも、コンソールにアセンブラースタックがあると奇妙なクラッシュが発生します。 はい、それらは非常にまれですが、あります。 すべてのフィールドはプライベートでなければならず、各フィールドには空のコンストラクターとゲッター+セッターが必要です。 もちろん、Lombokのサポートは最新バージョンに登場しましたが、これはまだ+1ライブラリであり、プロジェクトへの+1プラグインです。 もちろん、Lombokを使用しない場合、これはAndroid Studioの3つのショートカットで行われますが、これはプロジェクトのボイラープレートコードの束です。 サイズといえば、Realmを接続するためだけにAPKに+5メガバイト。



プロジェクトを初めてアセンブルする前に、存在しないコンパイル時のクラスも考慮する必要があります。 Parcelerの難しさ、RealmResultとRealmObjectの違い、realm.close（）の後にオブジェクトを読み取ることができない。 RealmList / RealmResultコレクションは、Listから継承されますが、addAll、indexOf、toArrayなどの多くの基本的なメソッドをサポートしません。 これはすべて追加の問題を追加します。 もちろん解決できますが、プロジェクトの複雑さが増しているため、これも考慮に入れる必要があります。



一般に、Realmでの作業は素晴らしいことです。 さらに、優れたドキュメント、ほぼすべての問題は公式Webサイトを読むことで解決できます。

2. OrmLite

非常に古く確立されたORM。 1つの問題：最後のリリースは3年前でした。 時代遅れの多く。 アプローチ自体は古くなっています。 2016年にコンパイル時の注釈を使用したコード生成？ これに真剣に参加したいですか？ 一般的に、それは通常の平均として表示されます。 どこか5-6mの場所ではありません。 唯一の便利な機能：親を読み取るときに、ネストされたコレクションを自動的に読み取る。 レルムのように。 遅いだけです。 しかし、他のORMはそうではありません。

3. GreenDao

SQLite用の超高速Android ORM。 これは公式ウェブサイトに記載されています。 そして彼は本当に超高速です。 時にはレルムよりも高速です。 しかし、再び、コード生成。 追加のコマンドを使用して、別のプロジェクトでデータベースを作成し、それをコンパイルする必要があります。そうして初めて、作業できるクラスができます。 生成されたクラスは変更できますが、特別なコメントを含めない場合、再生成中に新しい方法ですべて作成されることに注意してください。 ライブラリ自体は高速で小さいです。 そのため、プラスとマイナスがあります。 使用するかどうか-あなたが決める。

4. DBFlow

もう1つのお気に入りは速度です（ただし、便宜上ではありません）。 著者が主張するように、非常に高速-最速のAndroid ORMデータベースライブラリーですが、そうではありません。 注釈処理、つまり コンパイル中のコード生成。 その結果、たとえば、save（）は最高のパフォーマンスを提供するsql compileStatementコマンドに変わります。 もちろん、工場や反射で速度が低下します。速度がなければ速度は低下します。 結果のキャッシュをサポートしているため、キャッシュからデータをほぼ瞬時に取得できます。



しかし、欠点もあります。ライブラリが開発中であり、現在のリリースでは、3番目のベータバージョンは2番目と互換性がありません。 2番目のいくつかの例の公式文書の半分は、公式文書が不完全であり、場合によってはエラーもあります。 グリッチは、最も予期しない場所で発生します。 たとえば、クラスが大文字で配置されているpakageという名前を付けた場合、プロジェクトはコンパイルされません。 そして、あなたはその理由すら知らないでしょう。 通常のテキストエラーはありません。 移行の問題。 たぶん、あなたがもっと長く座っていれば、何かがうまくいくかもしれませんが、例によってすべてをしましたが、私の移行はうまくいきませんでした。 通常、このライブラリを通常どおり使用するには、多くの工数を費やす必要があります。 しかし、どこまで行くかという例はありますが、著者自身はこのテストに例を持っていませんでした。

5. 食器棚

シンプルで、それほど遅くはなく、時には高速です。 注釈がなくても機能します！ しかし、当然のことながら、あらゆる種類の@IgnoreやIndexさえあります 。 唯一の問題は、オブジェクトからではなく、データベースから機能することです。 つまり オブジェクトを記録するには、次の操作を行う必要があります。

 CupboardDatabase database = new CupboardDatabase(context); SQLiteDatabase db = database.getWritableDatabase(); DatabaseCompartment dbc = cupboard().withDatabase(db); dbc.put(addresses);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは必ずしも便利ではありません。 さらに、オブジェクトごとにLong _idフィールドが必要です。

6. 振りかける

ライブラリは私によってレビューに追加されませんでしたが、欠落しているテストを完了しました。 ライブラリはひどいです。 ひどい。 グラフを見てください。 理由を知っていますか？ 著者はデータベースのすべてのレコードに対して「SELECT * FROM％s WHERE％s LIMIT 1」を実行するためです！ はい、はい。 これらの作成者は、「INSERT OR REPLACE」をエミュレートします。 そして、あなたには選択肢がありません。 Save（）のみがあり、それで終わりです。 読み取りは、sqlに対する単純なラッパーです：Query.many（AddressItem.class、 "select * from AddressItem where addressBook =？"、String.valueOf（id））。Get（）。AsList（）。 ORMですか？ そう？ ベースを作成するメカニズムはまったくありません。 「CREATE TABLE」を手動で作成します。

7. ActiveAndroid

まあ、私は何を言うことができます。 メリットのない単なるORM。 速度も同じです。

8. Ollie

別のコンパイル時ORM。 全体的にかなり機敏です。 利点/欠点については何も言えません うまくいきませんでした。

9. シュガーORM

シンプルで手頃な価格ですが、非常に遅いです。 注釈の実行時の読み取りによる反射の反映により、作業が非常に遅くなります。 最近まで、彼はデータベースの各エントリに「Log.i（SUGAR、object.getClass（）。GetSimpleName（）+」saved： "+ id）;"と書いていました。 この行を削除すると、書き込み速度が2倍になることがあります！ 著者は、単純化のためにパフォーマンスを心配していないようです。 しかし、単純さで、すべてが整然としています：最小限の注釈、単純な保存（）、検索（）、しかし誰があなたを驚かせますか？

10. SQLlite。

ここでは、最高速度を目指した純粋なSQLについて説明しています。 これらは、「compileStatement」とbindString（i、value）、はい、はい、名前ではなくインデックスです。 ContentValuesもありません。 私のシフトではありません！



SQLlistは確かに、ほとんど常にリーダーである最も純粋な形式です。 唯一の例外は複雑な読み取り操作の領域であり、おそらくnosqlデータベース構造に通知します。 しかし、前述したように、これは最適化できると確信しています。



誰かが最初のグラフの「SQLite 50x」列の意味を尋ねますか？ データベースへの各挿入が50個のオブジェクトによって行われる場合、これは複数行のレコードです。



INSERT INTO table VALUES（？1 ,? 2 ,? 3）、VALUES（？4 ,? 5 ,? 6）、VALUES（？7 ,? 8 ,? 9）...



これはコードを非常に複雑にするため、単純なテストのために作成しました。 githubプロジェクトでは、このコードはコメント化されています。

純粋なSQLでは、インデックスの効果も特に顕著であり、インデックス付きテーブルへの書き込みがどのように遅くなり、読み取りがどのように加速されるかがわかります。 まあ、これらは一般的な真実であり、誰もがタスクのインデックスの使用を選択する必要があります。

おわりに

もちろん、テストは完全ではありません。 確かに、ランダム読み取りの速度は考慮されません。 ORMの初期化速度のテストもありません。 ORMラッパー自体を作成してから、データベースを使用する準備が整うまでの時間。 Snappy-DBのようなNoSQLがあり、実際の動作を見ると興味深いでしょう。 requeryのような新しいORMがありますが、これらについてはほとんど知られていませんが、それらのステートメントは相変わらず大音量です（RxJavaサポート、無反射など）。



これには時間がかかります。必要に応じて、プロジェクトコードを開いてください： github.com/Rexee/AndroidDatabaseLibraryComparison