問題タブ [bigtable]

重複

• リレーショナル データベースの代わりにドキュメント ベースのデータベースを使用する必要があるのはなぜですか?
• ドキュメント ベースのデータベースとリレーショナル データベースの長所と短所

Google の Bigtable についてはよくわかりませんが、Google の Bigtable と MySQL などのリレーショナル データベースの違いは何なのか疑問に思っています。両方の制限は何ですか？

GAE には、既存のエンティティを含む Foo というモデルがあり、 memcachedという新しいプロパティを Foo に追加しようとしています。このプロパティは、この値が最後に memcache に設定された日時の値を取得します。このプロパティをクエリして並べ替えたり、memcachedの値を持たないエンティティをフィルタリングしたりしようとすると、このプロパティの値がまだ設定されていないエンティティは返されません。ここに欠けているものはありますか、または別の方法として、特定のモデルのすべてのエンティティに新しいプロパティの値を設定する簡単な方法はありますか?

次のモデルのエンティティを多数作成しました。

次に、このモデルにプロパティを追加します。

クエリで並べ替えまたはフィルター処理を行う場合、新しいプロパティの既定値は考慮されません。

従来のリレーショナル データベースには、次のテーブルがあります。

このテーブルを Google App Engine テーブルに変換しようとしています。私の問題は、フィールド MotherId と FatherId にあります。以下のコードを試しましたが、チャンスはありませんでした。Python は、オブジェクト タイプ Person を知らないと言っています。

Google App Engine テーブルで再帰関係をモデル化する方法を知っている人はいますか? App Engine の制限を回避するにはどうすればよいですか?

更新 問題を少し拡大したい... 子のコレクションを追加したい場合はどうすればよいですか?

私はこれを試しましたが、うまくいきません。私が間違っていることは何ですか？

ありがとう！

私は基本的に古典的な多対多のモデルを持っています。ユーザー、アワード、およびユーザーとアワード間の「多対多」テーブルマッピング。

各ユーザーには約400の賞があり、各賞は約1/2のユーザーに与えられます。

ユーザーのすべてのアワードを繰り返して、ポイントを合計したいと思います。SQLでは、多対多間のテーブル結合になり、各行をウォークスルーします。MySQLインスタンスを備えたまともなマシンでは、400行はまったく大したことではないはずです。

App Engineでは、合計を行うのに約10秒かかります。ほとんどの時間はGoogleのデータストアで費やされています。これがcProfileの最初の数行です

私のデータモデルは間違っていますか？ルックアップを間違って行っていますか？これは、キャッシングとバルク更新に対処しなければならない欠点ですか（これはお尻の王室の痛みになります）。

MySQL テーブルのすべての行のすべての列へのすべての変更のタイムスタンプ付きレコードを保持する方法はありますか? このようにして、データを失うことはなく、遷移の履歴を保持します。行の削除は、「削除された」列を true に設定するだけである可能性がありますが、回復可能です。

Google のBigTableのオープン ソース実装であるHyperTableを見ていましたが、この機能には本当に驚きました。私のアプリは、HyperTable の展開を正当化するほどの膨大な量のデータを処理しないため、MySQL にそれを含めることができれば素晴らしいことです。この仕組みの詳細については、こちらをご覧ください。

この 1 つの機能だけを MySQL に追加する構成、プラグイン、フォークなどはありますか?

私はリレーショナル データベース設計の理論と実践に精通しています。

何が機能し、何が機能しないか、何がパフォーマンスが高く、何が保守可能かを知っています (ほとんどの場合、実際のデータを取得し始めると、微調整する場所が常にあります)。

Google の Bigtable (Google アプリ エンジン用のアプリを作成するため) などの分散型スケーラブル データベースに関する実質的な知識を見つけることができないようです。何が機能し、何が機能しないか、何が拡張され、なぜ拡張されないのか?

確かに、いくつかのブログ投稿や記事はありますが、bigtable や同様のデータベース パラダイム用のデータベースの設計に関する本や学術研究論文はありますか?

少し前に、数百万人のユーザーを抱える当社の Web サイトで、顧客のユーザー アクションをログに記録して報告するための新しい統計システムを検討しました。

データベースの設計は非常に単純で、foreignId (200,000 の異なる ID)、datetime フィールド、actionId (30 の異なる ID)、いくつかのメタ情報 (smallints のみ) を含む 2 つのフィールドを含む 1 つのテーブルを含みます。他のテーブルへの制約はありません。さらに、小さいインデックスを使用するとユーザーがタイムアウトになるため、削除できない 4 つのフィールドをそれぞれ含む 2 つのインデックスがあります。すべてのクエリにこのフィールドが含まれているため、foreignId は最も重要なフィールドです。

SQL サーバーの使用を選択しましたが、実装後はリレーショナル データベースが最適とは思えません。1 日に 3,000 万件のレコードを挿入することはできません (挿入のみであり、更新は行いません)。データベースを読み取ります。インデックスを十分に高速に更新できないためです。エルゴ: 私たちは大きな問題を抱えています :-) 問題は一時的に解決しましたが、まだ

リレーショナル データベースは、この問題には適していないようです。

BigTable のようなデータベースはより良い選択でしょうか? またその理由は? または、この種の問題に対処する際に、他により良い選択肢はありますか?

注意。この時点で、4 GB メモリと Win 2003 32 ビットを備えた単一の 8 コア Xeon システムを使用しています。私の知る限り、RAID10 SCSI。インデックス サイズは、テーブル サイズの約 1.5 倍です。

多くの「BAW」（big ass-websites）は、インデックス付きの巨大なテーブルに依存するデータストレージおよび取得技術を使用しており、クエリでJOINを使用しない/使用できないクエリ（BigTable、HQLなど）を使用しています。スケーラビリティとシャーディングデータベースを処理します。非常に関連性の高いデータがたくさんある場合、それはどのように機能しますか？

この結合の多くはアプリケーション側で行わなければならないと推測することしかできませんが、それは高価になり始めませんか？コンパイルする情報を取得するために、いくつかの異なるテーブルに対していくつかのクエリを実行する必要がある場合はどうなりますか？そもそも結合を使用するよりも、データベースに何度もアクセスする方がコストがかかり始めていませんか？どれだけのデータがあるかによると思いますか？

また、一般的に利用可能なORMの場合、結合を使用できないことにどのように対処する傾向がありますか？今日頻繁に使用されているORMでこれをサポートしていますか？または、このレベルのデータにアプローチする必要があるほとんどのプロジェクトは、とにかく独自にロールする傾向がありますか？

したがって、これは私が行っている現在のプロジェクトには当てはまりませんが、「ベストプラクティス」とは何かについてしか推測できないようになったため、数か月前から頭に浮かびました。必要な規模に達したことがないため、どのプロジェクトでもこれに対処する必要はありませんでした。うまくいけば、この質問は他の人にも役立つでしょう。

誰かが以下に言ったように、ORMは参加なしでは「機能しません」。このレベルのデータを扱う開発者がすでに利用できる他のデータアクセスレイヤーはありますか？

編集： いくつかの明確化のために、VinkoVrsalovicは言った：

「スニッカーは、トランザクションデータが非正規化されてHadoop、BigTable、またはCassandraスキームで使用されるNO-SQLについて話したいと思っています。」

これは確かに私が話していることです。

xkcdリファレンスをキャッチした人のためのボーナスポイント。

私は、bigtable、hbase、cassandraなどのこれらの新しいデータストアが実際に何であるかを正確に把握しようとしています。

私は大量の株式市場データ、毎日数百ギガバイトを追加できる数十億行の価格/見積もりデータを処理します（ただし、これらのテキストファイルは少なくとも1桁圧縮されることがよくあります）。このデータは基本的に、少数の数値、2つまたは3つの短い文字列、およびタイムスタンプ（通常はミリ秒レベル）です。行ごとに一意の識別子を選択する必要がある場合は、行全体を選択する必要があります（交換により、同じミリ秒で同じシンボルに対して複数の値が生成される可能性があるため）。

このデータをbigtable（その派生物を含む）にマッピングする最も簡単な方法は、シンボル名と日付（非常に大きな時系列を返す可能性があり、100万を超えるデータポイントは前代未聞ではありません）によるものだと思います。説明を読むと、これらのシステムでは複数のキーを使用できるようです。また、10進数はキーの候補としては適切ではないと思います。

これらのシステムの一部（たとえば、Cassandra）は、範囲クエリを実行できると主張しています。たとえば、特定の日の午前11時から午後1時30分までのMSFTのすべての値を効率的にクエリできますか？

特定の日のすべてのシンボルを検索し、価格が$ 10〜 $ 10.25のすべてのシンボルを要求したい場合はどうなりますか（値を検索し、結果としてキーを返したい場合）？

2つの時系列を取得し、一方を他方から減算し、2つの時系列とその結果を返したい場合、自分のプログラムで彼のロジックを実行する必要がありますか？

関連する論文を読むと、これらのシステムは大規模な時系列システムにはあまり適していないことがわかります。しかし、グーグルマップのようなシステムがそれらに基づいているなら、時系列もうまくいくはずだと思います。たとえば、時間をx軸、価格をy軸、シンボルを名前付きの場所と考えてください。突然、bigtableが時系列の理想的なストアになるはずです（地球全体を保存、取得できる場合） 、ズームおよび注釈付きの株式市場データは些細なものである必要があります）。

専門家が私を正しい方向に向けたり、誤解を解いたりできますか。

ありがとう