11

現在、Android ベースのプロジェクトに取り組んでいます。多くの詳細には触れませんが、ソフトウェアは特注のデバイスで実行されます。ハードウェアは決して変わらず、常に同じです。それは間違いなくプラスです:)

そうは言っても、このプロジェクトでは、デバイスにデータのロードとロードを保存する必要があります-一部のテーブルでは3m行以上。SQLite は、この数の行のスキャンを問題なく処理しますが、必要なすべての関連データを取得するために複雑な結合を開始すると、問題が発生します。データベースを非正規化することを検討しましたが、データベースが使用可能な範囲外に押し出されるのではないかと懸念しています。

db4o や NeoDatis などのオブジェクト指向データベースの使用を検討しています。私たちの希望は、オブジェクトを保存することで、行レベルで関係を取り除き、それらをオブジェクトに保存できることです (OOP のように)。問題は、Android で実行および使用されているこれらの ODB のパフォーマンス関連のベンチマーク (少なくとも最近のものではない) を見つけることができなかったことです。

Android で OODB を使用したり、この大量のデータを保存してアクセスしたりした経験のある人はいますか? もしそうなら、あなたが提供できるアドバイスは大歓迎です。

- 編集

これが私たちが直面している問題の例です。これは私たちのアプリとは関係ありません (私の NDA によれば、具体的な投稿はできません) が、この例は問題をよく表しています。

ニュージャージーの高速道路を走行するすべての車両を常に監視するアプリケーションを構築しているとします。特定の車について、車のメーカーとモデル、車に乗っている人数、車に乗っている人の人口統計を追跡する必要があります。したがって、基本的には、次のようなデータになります-

車

ID | 色 | make_id | in_toll_lane | モデル ID

作る

ID | 名前

モデル

ID | 名前 | make_id

車の人

ID | 年齢 | セックス | is_driver | car_id

toll_lanes

ID | car_in_line | Ideal_cars_in_line | 理想的な居住者

このデータは頻繁に変更されます。いつでも多くの人が NJ パイクを下っていることに疑いの余地はないので、それはかなり巨大になるでしょう。

このデータを使用して、高速道路を運転している人のスナップ ショットをオンデマンドで取得できるようにする必要があります。また、運転しているすべての男性、またはターンパイクにいるすべての女性のスナップショットを撮影できる必要があります。また、年齢、性別、メーカー、モデルなどで検索できる必要があります。

ここで、車内の人数、理想的な乗員数、すでに並んでいる車の数、列に並ぶべき理想的な車の数に基づいて、各車がどの料金所レーンに入る必要があるかを把握する必要があるとします。 .

これは非常に単純な例ですが、私たちの問題をよく表しています。

-- 編集終了

前もって感謝します！

4

4 に答える 4

3

データ アクセスのニーズやデータのロードアウトについてはあまり語っていません。

3M のメイン行があり、さらに小さなリーフ テーブルがたくさんある場合は、すべてのリーフ テーブルを RAM にキャッシュし、それらに手動で「結合」するだけでうまくいくかもしれません。多くのシステムには非常に小さいリーフ テーブル (特にメイン データと比較して) があるため、それらを RAM にロードし、行をロードするときにそれらを検索するだけで大​​きな効果が得られます。

明らかに、主要な親子関係でこれを行うことはありませんが、リーフ結合を排除できれば、読み取りは、親、子、およびリーフ テーブルへの半ダースではなく、親と子の間の 1 つの結合になります。 .

これがすべてのリーフ テーブルで機能しない場合でも、大部分のテーブルで機能する場合は、こぶを乗り越えるのに十分である可能性があります。

于 2010-12-01T02:07:28.680 に答える
3

db4o について言えば、Android は db4o にとって非常に重要なプラットフォームになると考えているため、すべての回帰テストを Android で実行しています。

db4o は、300 万個のオブジェクトのオーダーに対して非常にうまく機能します。

http://www.polepos.org/で他のデータベースに対してベンチマーク テストを行っており、SqlLite に対しても複雑なセットアップを実行するベンチマークの新しいバージョンをまもなくリリースする予定です。ベンチマークを Android に移植することも検討事項です。

結合によってパフォーマンスが低下し、非常に異種のデータがある場合、db4o はリレーショナル データベースよりもうまく機能する可能性があります。

あなたのアプリは面白そうですね。db4o の評価についてサポートが必要な場合は、声をかけてください。

于 2010-12-01T19:00:55.617 に答える
3

ここにいくつかの観察結果がありますが、直接的には役に立たないと思います.

主な質問は次のとおりだと思います:イベントがデータを生成または変更するときに、アプリケーションのランタイム ロジックを介して複雑な関係を検出するか、それとも単にデータをストアにダンプし、クエリを介して予期しない関係を検出する必要があるか?

ビジネス ロジックがモデルに入力する場合、データ モデルのさまざまなスライスのモデル ベースのビューを簡単に作成できます。たとえば、男性/女性のドライバーがいるすべての車を認識するコレクションなどです。この場合、基本的に、関係は半静的であり、めったに変化しません (一方、それらの関係の反対側のデータ値はおそらく大きく変化します)。この場合、データをデータベース テクノロジに格納しようとすると、常にリレーションを再計算 (JOIN) する必要があります。これは単なる CPU の浪費であり、モデルが複雑になるにつれてパフォーマンスが低下する理由です。したがって、これらの質問に答えると、ODB と RDB のどちらが最適かが明確になります。

ここで問題になるのは、何が Android で動作し、膨大なデータを処理するのかということです。ここはどうしようもないと思うところです。私は (db4o と Versant) ODB を持っている Versant で働いています。これで db4o は Android で実行されますが、実際には巨大なデータに適した選択でしょうか?状況。もう 1 つのデータベースである Versant は、膨大なデータをほぼリアルタイムで処理することを意図していませんが、クライアントのみが 100% Java であり、サーバーは C で記述されているため、Android では実行されません。

Android で膨大なデータを処理できる ODB を持っているのは誰なのか、調査する必要があると思います。

ベスト、-ロバート

于 2010-12-01T16:57:25.940 に答える
2

Jason: db4o メンバーに到達するには、次のパターンを使用する必要があります: firstname @ db4o.com ベスト!

于 2010-12-02T00:33:30.360 に答える