問題タブ [bigtable]

フォロワー関係を構築するためのテーブルを設計しようとしています。

ユーザー、ハッシュタグ、その他のテキストを含む140文字のレコードのストリームがあるとします。

ユーザーは他のユーザーをフォローし、ハッシュタグをフォローすることもできます。

これを設計した方法の概要を以下に示しますが、設計には2つの制限があります。他の人が同じ目標を達成するためのより賢い方法を持っているかどうか疑問に思いました。

これに関する問題は

1. フォロワーのリストは、レコードごとにコピーされます
2. 新しいフォロワーが追加または削除された場合は、「すべての」レコードを更新する必要があります。

コード

これを行うためのよりスマートな方法はありますか？

簡単な方法で GET、PUT、DELETE HTTP メソッドを使用できるアプリケーションがあるかどうか知っていますか?

Google の BigTable に対して実行したい。

どうもありがとう。

Google アプリ エンジンには、データストアを読み取り専用モードにするかなりの量のダウンタイムがあるように見えることに気付きました。多くの場合、このダウンタイムは日中にあります。これは開発の初期段階でのみ発生するものですか、それとも常に発生すると予想できるものですか?

中小企業が業務を処理するのに役立つアプリケーションを開発しています。それが行うことの1つは予約を取ることであり、もう1つは電話のルーティングです。データストアが読み取り専用の場合の処理​​方法について、次のような提案をお願いします。

• クライアントが顧客と電話で予約を取り、データストアが読み取り専用になっている場合はどうなるでしょうか? 特に日中の場合は、保存するために後で戻ってくるようクライアントに依頼することは受け入れられません。
• 着信コールがあり、データベースの書き込みが利用できないために、アプリケーションがレコードを保存したり、コールを適切にルーティングしたりできない場合はどうなりますか?

この種の問題は通常どのように処理されますか?

次のいずれかを実行しているマシンのクラスターにマシンを追加すると、パフォーマンス (読み取りクエリ/秒) はどのような要因で向上しますか?

• Bigtable のようなデータベース
• MySQL?

Bigtable に関する Google の研究論文は、Bigtable で「ほぼ線形」のスケーリングを実現できることを示唆しています。MySQL のマーケティング用語を紹介するこのページでは、MySQL が直線的にスケーリングできることを示唆しています。

真実はどこにある？

LogParser を使用して IIS ログを SQL Server データベースにダンプするスクリプトをいくつか実行しました。

次に、これをクエリして、ヒット数や使用状況などに関する簡単な統計を取得できます。エラー ログ データベースやパフォーマンス カウンター データベースにリンクして、使用状況とエラーなどを比較する場合にも役立ちます。

これを 1 つのシステムに実装しただけで、過去 2 ～ 3 週間で、約 1,000 万件のレコードを含む 5 GB のデータベースが既にありました。

これにより、このデータベースへのクエリが非常に遅くなり、このままログを記録し続けると、ストレージの問題が発生することは間違いありません。

このようなログに対してより効率的な、このデータに使用できる代替データベースを提案できる人はいますか? Google の BigTable や Amazon の SimbleDB の経験に特に興味があります。

これらのいずれかがクエリのレポートに適していますか? COUNT、GROUP BY、PIVOT?

私はGoogleAppEngineを使用しており、低レベルのJavaAPIを使用してBigTableにアクセスしています。私は4つのレイヤーでSAASアプリケーションを構築しています：

• クライアントWebブラウザ
• RESTfulリソースレイヤー
• ビジネスレイヤー
• データアクセス層

私は自分のモバイルオートディテーリング会社（およびそのような他の会社）の管理に役立つアプリケーションを構築しています。私はこれらの4つの別々の概念を表現する必要がありますが、私の現在の計画が良いものであるかどうかはわかりません。

• 予定
• ラインアイテム
• 請求書
• 支払い

アポイントメント：「アポイントメント」とは、サービスを提供するために従業員が期待される場所と時間です。

広告申込情報：「広告申込情報」とは、サービス、料金、割引、およびそれに関連する情報です。予定に入る可能性のある広告申込情報の例：

請求書：「請求書」は、顧客が支払うことを約束した1つ以上の広告申込情報の記録です。

支払い：「支払い」は、どのような支払いが行われたかを記録したものです。

このアプリケーションの以前の実装では、作業はより単純であり、これらの4つの概念すべてをSQLデータベースの1つのテーブル「予定」として扱いました。1つの「予定」には、複数の広告申込情報、複数の支払い、および1つの請求書を含めることができます。請求書は、広告申込情報と顧客レコードから作成された単なる電子メールまたは印刷物でした。

10回のうち9回、これは正常に機能しました。1人の顧客が1台または数台の車両を1回予約し、自分で支払いをしたとき、すべてが壮大でした。しかし、このシステムは多くの条件下で機能しませんでした。例えば：

• 1人の顧客が1回の予約をしたが、途中で雨が降り、詳細担当者が翌日戻ってくる必要があった場合、2回の予約が必要でしたが、1つの広告申込情報、1つの請求書、1つの支払いのみでした。
• オフィスの顧客グループ全員が割引を受けるために同じ日に車を運転することに決めたとき、私は1つの予約が必要でしたが、複数の請求書と複数の支払いが必要でした。
• 1人の顧客が1回の小切手で2回の予約を支払った場合、2回の予約が必要でしたが、請求書と支払いは1回だけでした。

物事を少し混乱させることで、これらすべての外れ値を処理することができました。たとえば、詳細担当者が翌日に戻ってくる必要がある場合、2日目に「完了」という広告申込情報を使用して別の予定を立てると、費用は$0になります。または、1人の顧客が1回の小切手で2回の予約に対して支払いを行う場合、各予約に分割支払いレコードを入れます。これに伴う問題は、データの不一致の大きな機会を生み出すことです。データの不一致は、特に、顧客が1回の小切手で2回の予約を支払った、3番目の例などの財務情報が関係する場合に深刻な問題になる可能性があります。売掛金を適切に追跡するには、支払いを提供された商品やサービスと直接照合する必要があります。

提案された構造：

以下は、このデータを整理および保存するための正規化された構造です。おそらく私の経験不足のために、データの不一致エラーを回避するための優れた方法のように思われるため、データの正規化に重点を置いています。この構造により、他のテーブルの更新を気にすることなく、1回の操作でデータの変更を行うことができます。ただし、読み取りには、データのメモリ内編成と組み合わせた複数の読み取りが必要になる場合があります。後でわかりますが、パフォーマンスの問題がある場合は、「安全な」正規化された構造をそのままに保ちながら、クエリを高速化するために、いくつかの非正規化フィールドを「予定」に追加できます。非正規化により、書き込みが遅くなる可能性があります。

テーブル：

以下は、特定の予定のリストに対して4つのエンティティ（テーブル）すべてを結び付けるために必要な一連のクエリと操作です。これには、各アポイントメントにスケジュールされたサービス、各アポイントメントの合計コスト、および各アポイントメントに対して受け取った未払いの天気に関する情報が含まれます。これは、予定のスケジューリングのためにカレンダーをロードするとき、またはマネージャーが操作の全体像を取得するときの一般的なクエリです。

• 「start_time」フィールドが指定された範囲内にある「Appointments」のリストのQUERY。
  • 返された予定の各キーをリストに追加します。
• アポイントメント_キー_リストフィールドのすべての「Line_Items」のクエリには、返品アポイントメントのいずれかが含まれます
  • すべてのラインアイテムの各invoice_keyをSetコレクションに追加します。
• 請求書セット内のすべての「請求書」のクエリ（これは、App Engineを使用した1回の非同期操作で実行できます）
  • 返された請求書の各キーをリストに追加します
• invoice_key_listフィールドにあるすべての「支払い」のQUERYには、返された請求書のいずれかに一致するキーが含まれています
• 各予定が、予定されているline_items、合計価格、合計推定時間、および支払い済みかどうかを反映するように、メモリ内で再編成します。

...ご覧のとおり、この操作には4つのデータストアクエリとメモリ内の編成が必要です（メモリ内がかなり高速になることを願っています）

誰かがこのデザインについてコメントできますか？これは私が思いつくことができる最高のものですが、一般的に、または特にGAE（google app engine）の長所、短所、および機能の下で、より良いオプションまたは完全に異なるデザインがより適切に機能する可能性があると思います。 。

ありがとう！

使用法の明確化

ほとんどのアプリケーションは読み取りを多用し、一部のアプリケーションは書き込みを多用します。以下に、ユーザーが実行したい典型的なユースケースと内訳操作について説明します。

マネージャーは顧客から電話を受けます：

• 読み取り-マネージャーはカレンダーをロードし、利用可能な時間を探します
• 書き込み-マネージャーが顧客に情報を問い合わせます。これは、マネージャーが電話番号、名前、電子メール、住所などの各情報を入力するときの非同期読み取りの連続であると考えました。または、必要に応じて、おそらく1つクライアントアプリケーションがすべての情報を収集し、送信された後、最後に書き込みます。
• 書き込み-マネージャーは顧客のクレジットカード情報を削除し、別の操作として顧客のレコードに追加します
• 書き込み-マネージャーはクレジットカードに請求し、支払いが完了したことを確認します

マネージャーが電話をかけます。

• 読み取りマネージャーがカレンダーをロードします
• Read Managerは、電話をかけたい顧客の予定を読み込みます
• 書き込みマネージャーが[呼び出し]ボタンをクリックすると、呼び出しが開始され、新しいCallReacordエンティティが書き込まれます
• 読み取り呼び出しサーバーは呼び出し要求に応答し、CallRecordを読み取って呼び出しの処理方法を確認します
• Write Callサーバーは、更新された情報をCallRecordに書き込みます
• 呼び出しが閉じられたときに書き込み、呼び出しサーバーは、CallRecordリソースを更新するためにサーバーに別の要求を行います（注：この要求はタイムクリティカルではありません）

受け入れられた回答:: 上位2つの回答はどちらも非常に思慮深く、高く評価されました。私は、彼らの露出を可能な限り均等にするために、投票数の少ないものを受け入れました。

40 ～ 50 の範囲で番号付けされたプロパティを持つエンティティがいくつかあります。これらのプロパティはすべてインデックス付けされていません。これらのエンティティは、より大きなエンティティ グループ ツリー構造の一部であり、常にキーを使用して取得されます。どのプロパティ (キー プロパティを除く) もインデックス化されません。Objectify を使用して、BigTable のエンティティを操作しています。

BigTable との間で多数のプロパティを持つエンティティを読み書きする際に、パフォーマンスに影響があるかどうかを知りたいです。

これらの大きなエンティティはキーによってのみフェッチされ、クエリに参加することはないため、エンティティ pojo をシリアル化して blob として保存する必要があるかどうか疑問に思っていました。@Serialized アノテーションを使用して Objectify でこれを行うのは非常に簡単です。エンティティをシリアル化して BLOB として保存することで、BLOB を他のプログラムや Java 以外のコードに対して完全に不透明にすることを理解していますが、これは問題ではありません。

私はまだパフォーマンスの違いをベンチマークしていませんが、そうする前に、誰かが以前にこれを行ったことがあるかどうか、または共有するアドバイス/意見があるかどうかを知りたい.

バックグラウンド：：：：

Java 用の Google アプリ エンジン (GAE) を使用しています。大きなテーブルの長所と短所に対応するデータ モデルの設計に苦労しています。これらは以前の 2 つの関連記事です。

• データベース設計 - Google アプリ エンジン
• 予定と品目

ほとんどのクライアント要求が 1 つのクエリだけで処理できるように、非正規化されたプロパティがエンティティに追加された完全に正規化されたバックボーンを暫定的に決定しました。

私は、完全に正規化されたバックボーンは次のようになると考えています。

• 非正規化で間違いをコーディングした場合、データの整合性を維持するのに役立ちます
• クライアントの観点から 1 回の操作で書き込みを有効にする
• データに対するあらゆるタイプの予期しないクエリを許可します (待機する意思がある場合)。

非正規化されたデータは次のようになります。

• ほとんどのクライアント要求を非常に高速に処理できるようにする

基本的な非正規化手法:::

「ファンアウト」と呼ばれる手法を説明するアプリ エンジンのビデオを見ました。アイデアは、正規化されたデータへの迅速な書き込みを行い、タスク キューを使用して、クライアントを待たせることなく舞台裏で非正規化を完了することです。参照用にここにビデオを含めましたが、その長さは 1 時間であり、この質問を理解するために見る必要はありません: http://code.google.com/events/io/2010/sessions/high-throughput -data-pipelines-appengine.html

この「ファンアウト」手法を使用すると、クライアントが一部のデータを変更するたびに、アプリケーションは 1 回のクイック書き込みで正規化されたモデルを更新し、非正規化命令をタスク キューに送信するため、クライアントは待機する必要がなくなります。それらも完了する必要があります。

問題：：：

タスク キューを使用してデータの非正規化バージョンを更新する際の問題は、タスク キューがそのデータの非正規化を完了する前に、変更したばかりのデータに対してクライアントが読み取り要求を行う可能性があることです。これにより、最近の要求と一致しない古いデータがクライアントに提供され、クライアントが混乱し、アプリケーションにバグがあるように見えます。

解決策として、URLFetch を介してアプリケーション内の他の URL への非同期呼び出しを介して、非正規化操作を並行して展開することを提案します。http://code.google.com/appengine/docs/java/urlfetch/ アプリケーションは、すべてのクライアント要求に応答する前に、非同期呼び出しが完了していました。

たとえば、「予定」エンティティと「顧客」エンティティがあるとします。各予定には、誰が予定されているかについての顧客情報の非正規化されたコピーが含まれます。顧客が名前を変更した場合、アプリケーションは 30 回の非同期呼び出しを行います。影響を受ける各予定リソースに 1 つずつ、それぞれの顧客の名前のコピーを変更します。

理論的には、これはすべて並行して実行できます。この情報はすべて、データストアに 1 回または 2 回の書き込みを行うのにかかるおおよその時間で更新できます。非正規化が完了した後、タイムリーな応答をクライアントに行うことができ、クライアントが不適合なデータにさらされる可能性を排除できました。

これに関する最大の潜在的な問題は、アプリケーションが一度に 10 を超える非同期リクエスト呼び出しを実行できないことです (ここに文書化されています): http://code.google.com/appengine/docs/java/urlfetch/overview .html )。

提案された非正規化手法 (再帰的非同期ファンアウト):::

私が提案する解決策は、非正規化命令を別のリソースに送信して、命令を再帰的に同じサイズの小さなチャンクに分割し、各チャンク内の命令の数が完全に実行できるほど小さくなるまで、小さなチャンクをパラメーターとして自分自身を呼び出すことです。たとえば、30 件の予定が関連付けられている顧客が名前のスペルを変更したとします。非正規化リソースを呼び出して、30 件の予定すべてを更新するように指示します。次に、これらの命令を 3 つの命令の 10 セットに分割し、3 つの命令の各セットで独自の URL に対して 10 の非同期要求を作成します。命令セットが 10 未満になると、リソースは各命令に従って完全に非同期要求を作成します。

このアプローチに関する私の懸念は次のとおりです。

• アプリ エンジンのルールを回避しようとしていると解釈される可能性があり、問題が発生する可能性があります。（URLがそれ自体を呼び出すことさえ許可されていないため、実際には、相互に呼び出す再帰を処理する2つのURLリソースが必要です）
• これは複雑で、潜在的な障害点が複数あります。

このアプローチに関する意見をいただければ幸いです。

Java 用の低レベル API を使用して、定義済みのキーを持つエンティティのバッチを実行したいと考えています。

バッチ取得を行うことができます：

ただし、バッチはすべて独自のキーを割り当てたいようです。

ドキュメント ページ: http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/DatastoreService.html#put(java.lang.Iterable)

エンティティのコレクションをバッチで取得し、更新してから、バッチでデータストアに戻そうとしています。キーの値を変更せずにこれを行うことができるのは理にかなっていますね。

1. 'nosql'で、テーブル/エンティティを'非正規化'する必要があるbigtableのような制限があることを知っていますか？

2. コードを1回記述でき、Google App Engineのbigtableとnosqlに使用できるAPIラッパーはありますか？（ヒベラネートのようなもの）