問題タブ [bigtable]

Google App Engine がデータストアの実装を BigTable から MegaStore に移行していることが注目されています。2つの違いは何ですか？

フェイスブックがビッグテーブルと呼ばれるものを使っていることを知りました。私が使用しているアプリケーションでこの「大きなテーブル」データベースを使用する方法はありますか?

データのインデックスを作成しています。これには、多くのトリプレットをフォームに格納する必要があります(document, term, weight)。このような行を最大数百万行保存します。現在、MySQL で単純なテーブルとしてこれを行っています。ドキュメントと用語の識別子を、他のテーブルへの外部キーよりも文字列値として保存しています。ソフトウェアを書き直し、データを保存するより良い方法を探しています。

HBase の仕組みを見ると、これはかなりスキーマに適合しているように見えます。多くのトリプレットを保存する代わりにdocument、{term => weight}.

私は単一ノードでこれを行っているので、分散ノードなどは気にしません。MySQL が機能するのでそのまま使用する必要がありますか、それとも HBase を試すのが賢明でしょうか? Lucene がこれをフルテキスト インデックス作成に使用していることがわかります (これは、私が行っていることと似ています)。私の質問は、単一の HBase ノードが単一の MySQL ノードとどのように比較されるかということです。私は Scala から来ているので、直接の Java API は、JDBC や MySQL の各クエリの解析などよりも優れているのでしょうか?

私の主な関心事は、以前はボトルネックだった挿入速度です。処理後、ライブ クエリのためにデータを MySQL に戻すことになるでしょう。

両方のプロトタイプを作成してみますが、コミュニティがこれに関する貴重な洞察を提供してくれると確信しています。

HBaseを、{document => {term => weight}}「用語Xを重みZでドキュメントYに挿入する」などの形式の数百万のエントリをプッシュできるストアとして使用し、「このドキュメントの上位1000の用語を選択する」または「各ドキュメントの上位1000の用語を選択してください。」これは私の現在のMySQL実装で機能しますが、おそらくドメインはHBaseに適しています。HBaseとBigTableは、同様の問題ドメインであるフルテキストインデックス作成に使用されていることに注意してください。

私はHBaseで数ページしか読んでいないことがわかりますが、私の質問の要点を理解していただければ幸いです。この質問に関連しています。

考えられる障壁には、HBaseがLIMIT句と同等のクエリを許可しないことが含まれる場合があります。重みでクエリを実行したい場合は、を関連付けたいと思います{weight => term}。これは、同じ重みを持つ2つの用語で問題が発生します（HBaseでは一意のキーのみが許可されると想定しています）。または、特定の重みの用語のコレクションを保存する必要がありますが、これにより、返される用語の数を正確に制限する能力が制限されます。

appengineでエンティティを別の種類に移動する方法はありますか？

ある種類の定義があり、その種類の削除されたエンティティの記録を保持したいとします。ただし、ライブオブジェクトとアーカイブオブジェクトのストレージを分離する必要があります。とにかく、種類は基本的にbigtableでシリアル化されたdictです。また、ライブデータと同じ方法でアーカイブにインデックスを付ける必要はないかもしれません。では、ある種類のエンティティを別の種類に移動またはコピーするにはどうすればよいでしょうか。

アプリエンジンデータベースに投稿するデータを含むテーブルビューがあります。テーブル内のエントリを削除するたびに、アプリ エンジン データベース内のアイテムも削除したいと考えています。削除するエントリを確認するにはどうすればよいですか?

私はこれを考えていました：

GAE ストアに保存するすべてのアイテムについて、iPhone 固有のデバイス ID を持つモデルを参照します。GAEストアに保存するすべてのアイテムに対して、iphone dbとapp engine dbのUUIDを挿入します。

したがって、私のクエリは次のようになります。

アプリ エンジンにログインしたくないので、一意のデバイス ID を使用しています。

私の唯一の懸念はパフォーマンスです.GAEはデバイスIDとUUIDを検索する必要があります.これが問題になるかどうかはわかりません.

最善の解決策は、db.Key() で削除できる場合ですが、その方法がわかりません。データを GAE に投稿するときに、生成されたキーがわからないためです。

誰かアドバイスをくれませんか？

BigTableデータストアでこれを処理する方法がわかりません。

次の例を想像してみてください（概念を説明するためだけです。この例は実際のデータモデルと一致しません）。

• データストア内のトランザクション数を追跡するCounterエンティティがあります。現在の「カウント」が100であるとしましょう。
• これで、2つのWebリクエストがこの値を同時に読み取ります。
• 両方のWebリクエストが新しいトランザクションを追加します
• そして最後に、両方ともカウンターを更新します（101に）。

カウンタ値が不正確になりました。102である必要があります。

この状況に対処する方法について何か提案はありますか？カウンターを「ロック」して、最初のWebリクエストが完了するまで2番目のWebリクエストがカウンターを読み取らないようにすることはできますか？

分散データベース システム Bigtable がオブジェクト指向であることを知りたいですか?

Bigtable と NOSQL に関する記事をいくつか読みました。JOIN 操作を回避することは非常に興味深いことです。

基本的な例として、Employee テーブルと Department テーブルを取り上げ、データが複数のテーブル/サーバーに分散していると仮定します。

データが複数のサーバーに分散している場合、どのように JOIN または UNION 操作を行うのでしょうか?

GoogleAppEngineのエンティティグループに頭を悩ませようとしています。一般的には理解していますが、オブジェクトが作成されると関係を変更できないようで、ビッグデータの移行が必要なため、最初から正しく設定するようにしたいと思います。

私は、メンバーが通常のメンバーとして、または少数の非多形エンティティの「タイプ」（Artist、Venue、Organization、ArtistRepresentativeなど）の1つとしてサインアップできるArtサイトを作成しています。たとえば、アーティストはアートワークを持つことができ、アートワークは他の関係（ギャラリー、メディアなど）を持つことができます。これらはすべて参照を介して接続されており、単に参照を行うためにエンティティグループは必要ないことを理解しています。ただし、いくつかの参照が存在する必要があるため、エンティティグループを調べています。

ドキュメントから：「エンティティグループの経験則として、1人のユーザーに相当するデータのサイズ以下にする必要があります。」

そうは言っても、はい/いいえの質問がいくつかあります。

質問0：トランザクションを実行するためだけにエンティティグループは必要ないようです。ただし、エンティティグループはBig Tableの同じ領域に保存されるため、一貫性の問題と競合状態を減らすのに役立ちます。これは、エンティティグループとトランザクションを一緒に公正に見ていますか？

質問1：子エンティティが保存されると、親オブジェクトは暗黙的にアクセス/保存されますか？つまり、パスMember / Artist / Artworkを使用してエンティティグループを設定した場合、Artworkオブジェクトを保存すると、MemberオブジェクトとArtistオブジェクトが更新/アクセスされますか？私はそうは思わないでしょうが、私はただ確認しているだけです。

質問2：質問1の答えが「はい」の場合、アクセス/更新はパスをたどるだけで、他の子供には影響しませんか。つまり、アートワークを更新しても、メンバーの他のアートワークの子は更新されません。

質問3：ユーザーがサインアップするときにメンバーとそれに関連するアカウントタイプのエンティティが存在し、ユーザーのみがそのメンバーと関連するアカウントタイプのエンティティを更新することが非常に重要であると仮定すると、これらをエンティティグループにまとめることは理にかなっていますか？ ？

すなわち、メンバー/アーティスト、メンバー/組織、メンバー/会場。

同様に、ユーザーだけがアートワークエンティティを更新できると仮定すると、それらも含めるのは理にかなっていますか？注：アートワークへの参照であるメディア/ギャラリーなどは、ユーザーが所有するものだけでなく、多くのアートワークに関連している可能性があります（つまり、多対多の関係）。

すべてのユーザーのビットがBigTableの同じ領域にあるため、私が思うように機能する場合（つまり、Q1 / Q2は「いいえ」）、エンティティグループにすべてのユーザーのビットを含めることは理にかなっています。ただし、アートワークをエンティティグループに追加すると、「小さく保つ」という原則に違反する可能性があり、正直なところ、ユーザーがアートワーク画像をアップロードするときに帯域幅/再試行を節約する以外に、トランザクションに含める必要がない場合があります。

何かご意見は？エンティティグループへのアプローチが間違っていますか？