問題タブ [schema-design]

私は MongoDB に比較的慣れていませんが、今のところ非常に感銘を受けています。ただし、ドキュメントストアをセットアップする最良の方法に苦労しています。Twitter データを使用して要約分析を実行しようとしていますが、ツイートをユーザー ドキュメントに入れるか、別のコレクションとして保持するかがわかりません。ツイートをユーザー モデル内に配置すると、すぐにサイズの限界に達してしまうようです。その場合、ユーザーのツイートのグループ全体で MapReduce を実行できるようにするための良い方法は何ですか?

漠然としすぎていないことを願っていますが、ドメイン モデルをセットアップする限り、具体的になりすぎたり、間違った道を進みすぎたりしたくありません。

皆さんはもう聞き飽きていると思いますが、私はスキーマを次のようにレイアウトする RDB ランドに慣れています。

Mongoの論理スキーマは次のようになります

しかし、ユーザー ドキュメントがすぐに容量を超えて肥大化することはありません。しかし、somegroupID が似ているユーザーのツイートを分析したいと考えています。上記のモデル レイアウトは概念的には理にかなっていますが、どの点があまりにも扱いにくいのでしょうか? そして、実行可能な代替手段は何ですか？

投資会社のデータベースがあります。

• B（ブローカー）
• O（ブローカーのオフィス）
• 私（投資家）
• S（ストック）
• Q（投資家の保有株式数）
• D（株式配当）

機能依存性

• S ⟶ D
• 私⟶B
• ⟶Q
• B⟶O

リレーション スキーム R=BOSQID の最小限のキーを見つけて、それを証明する必要があります。

この問題を解決する方法がわかりません。アイデアをいただけますか？

コレクション構造のみを作成したい。つまり、Say Products コレクションにはカテゴリのリストが含まれています。

この依存関係を作成してこのコンテナ構造を指定したいのですが、コレクション エントリを作成したくありません (データを一括アップロードするローダー プログラムがどこかにあるとします)。

RDBMS の最も近い類推は次のとおりです。DBA は、制約と依存関係を使用してスキーマ設計を作成します。アプリケーションまたは ETL ツールが実際のデータをロードします。

私が目にするほとんどの例では、単純にサンプル コレクションを作成してから、db.insert(document) OR db.save(document) を呼び出しています。

MongoDBでも可能ですか?

質問が明確でない場合は、お知らせください。

ありがとう

複数のバックエンド (現在は MySQL または XML) にフックできる PHP アプリがあり、MongoDB でも動作させようとしています。私が明らかに苦労している一見マイナーな問題の 1 つは、Mongo が '_id' を主キーの名前にすることを義務付けていることです。バックエンドは通常、アプリケーションによってかなりうまく抽象化されていますが、アプリケーションはかなり定期的に ID を操作する必要があるため、$result['id']今までうまく抽象化されていた のようなコードでアクセスします。

しかし今、「id」を主キーとして使用できない DB を (効率的に!) 処理しようとすることに直面しており、最適なオプションが何であるかわかりません。これまでに私が考えたことは次のとおりです。

1. Mongo の '_id' 値をそのままにして、アプリケーション変数$idをバックエンドに、"id"または"_id"バックエンドに応じて設定します。アプリケーションは$id、ハードコードされた ではなく、 を使用して ID フィールドにアクセスする必要があります"id"。他のすべてのフィールドは、$result['user']and などの文字列名でアクセスされるため、これはアプリケーションの標準に違反することに注意してください。

   長所: 可能な場合は MongoCursor オブジェクトを直接返すことができるため、メモリ使用量を最小限に抑え、データへの高速アクセスを保証します。

   短所: 下位互換性がなく、このアプリケーションを使用するコードの (かなり面倒な) リファクタリングが必要になります。

2. 返された MongoCursor オブジェクトを、適切に"_id"マップされた各項目を返す新しい反復子クラスにラップし"id"ます。アプリケーションは、Mongo と通信"id"するときにインバウンド コールを にマップします。"_id"

   長所: 1. のメモリ効率のほとんどを保持しながら、ほとんどの下位互換性の問題を回避します。

   短所：そのようなオブジェクトを実装する方法が完全にわからない、それがきれいにできると確信していない、または私が想像しているのと同じように実際にうまくいくと確信していない. 正しく行うには、他のバックエンドにも同様の反復子ラッパーを実装したいと思います。

3. iterator_to_array()で説明されているように結果をメモリにロードしMongoCollection.find()、適切な変換を行い、配列を返します。

   長所: 概念的には 2. より単純で、アプリの残りの部分とうまく連携します。

   短所: メモリの点で明らかに悪い選択です。アプリを考えると世界の終わりではありませんが、それでも理想的ではありません.

これらのオプションのいずれかが、この問題に対する特に合理的で堅牢な解決策として際立っていますか? バックエンドにとらわれない方法で主キーを処理するための他の代替案を誰かが提案できますか? 追加のバックエンドは将来的に可能性があるため、他のデータ ストレージ システムに関連する特定の方法の問題または利点も歓迎します。

私は現在2.に傾いていますが、あなたの考えを歓迎します。

リアルタイム分析にHBaseを使用することを検討しています。

HBaseの前は、ログファイルに対してHadoop Map Reduceジョブを実行してデータを集約し、細粒度の集計結果をHBaseに保存して、集計データのリアルタイム分析とクエリを可能にします。そのため、HBaseテーブルには事前に集計されたデータ（日付別）が含まれます。

私の質問は、HBaseデータベースのスキーマと主キーの設計を最適に設計して、高速で柔軟なクエリを可能にする方法です。

たとえば、次の行をデータベースに格納するとします。

そして、map-reduceジョブが3つの異なる出力フィールドを生成し、それぞれを個別の「テーブル」（HBase列ファミリー）に格納するとします。

• 日付、オペレーティングシステム、ブラウザ
• 日付、URL、リファラー
• 日付、URL、国

（私たちのmap-reduceジョブは、ユーザーエージェントとclient_ipデータからoperationing_system、browser、countryフィールドを取得します。）

私の質問は、HBaseスキーマを構造化して、これらのフィールドのいずれか、またはその組み合わせを高速でほぼリアルタイムで柔軟に検索できるようにするにはどうすればよいでしょうか。たとえば、ユーザーは次を指定できる必要があります。

• 日付別のoperationing_system（「この日付範囲のiPadユーザーは何人ですか？」）
• 国別および日付別のURL（「先月、この国からこのURLへのユーザー数は？」）

そして基本的に他のカスタムクエリはありますか？

次のようなキーを使用する必要があります。

• date_os_browser
• date_url_referrer
• date_url_country

もしそうなら、私たちは上で指定された種類のクエリを満たすことができますか？

私は 2 つのコレクションを持っています。買い物客 (特定の日に店にいる全員) とビーチに行く人 (特定の日にビーチにいる全員) です。毎日のエントリーがあり、ビーチにいる人、買い物をしている人、両方をしている人、またはどちらもしていない人がいます。ここでクエリを実行したい - 過去 7 日間にビーチに行かなかったすべての買い物客。

私は Mongo を初めて使用するので、私のスキーマ設計が nosql DB には適していない可能性があります。join に関して同様の質問を見ましたが、ほとんどの場合、非正規化が提案されました。したがって、私が考えることができる1つの解決策は、コレクションを作成することです-アクティビティ、日付のインデックス、ユーザーのアクションの埋め込み。だから何か

挿入の前にクエリを実行する必要があるため、挿入にはコストがかかります。

繰り返し発生するイベントのデータ保存方法について説明している論文をいくつか読んだことがありますが、特にMongoDBに関しては、ベストプラクティスに頭を悩ませようとしています。

私の主な関心事は、特定の時間枠内に発生するすべてのイベントを安価に取得することです。私の二次的な関心事は、イベントチェーン全体を破壊することなく、単一のオカレンスを変更および変更することです。

同様の質問をした他の人を見て、私は可能性を思いついた。私はそれに完全に売られているわけではなく、正しい方向へのいくつかのポインターが大好きです。

私のアイデア：各イベントドキュメント内に...

• iCal標準に厳密に一致する繰り返し文字列フィールド
• 特定のオカレンスの変更/編集（説明や開始時刻の変更、単一のオカレンスのキャンセルなど）を含む「オカレンス」埋め込みドキュメントまたは配列フィールド。
• 繰り返しルールの簡単に照会できる境界を定義するためのオカレンスの開始フィールドと終了フィールド

長所：

• 変更を保存し、他のイベントとの関連付けを維持できます
• 簡単に質問できますが、ビジネス側の私のモデルでは、各イベントを作成する必要があります。

短所/潜在的な問題：

• イベントを編集していて、ユーザーが変更を「すべてのイベント」に適用するものとしてマークすることを決定した場合-すでに過去のイベントが変更されないようにする方法

こんにちは（少なくともこのあたりでは）、

構築に問題がある多対多の関係スキーマがあります。主な問題は、私が主キーと外部キーのみを使用しており (物事を単純化するために varchar や enum を使用していない)、多対多の関係の数が予測できず、いつでも増加する可能性があることです。

さまざまな質問を見回しましたが、この問題に直接対処するものは見つかりませんでした。

問題を半分に分割したので、1 対多のスキーマが 2 つになりました。1つは解決されましたが、もう1つは私にフィットしています。

テーブル FOO が、単純な主キーを持つ標準的で退屈なテーブルであると仮定しましょう。それは一対多の関係にあるものです。

テーブル BAR は、FOO の複数のキーに関連付けることができます。関連するキーの数は事前にわかりません。

例：

1. クエリから FOO は ID 3、4、5 を返します。
2. BAR には、3、4、5 に関連する一意のキーが必要です (ただし、任意の数の ID が返される可能性があります)。

通常の結合テーブルは機能しません:

FOO は 3 つの一意のキーを返すため、ここで bar_id は foo_id と 1 対 1 の関係にあります。

foo_ids 3、4、5 を単一の bar_id にマップできないため、2 つの結合テーブルを使用しても機能しないようです。

私は何を間違っていますか？私は物事を実際よりも複雑にしていますか? 問題にどのようにアプローチすればよいですか？助けてくれてありがとう。

私のプロジェクトでは、3 つのモデルがあります。

1. 街
2. プラザ
3. 店

都市には広場と店舗があります。広場には店舗があります。

私の最初の設計は、関係に「外部キー」を使用することです。（私はmysqlから来て、jsutはmongodbを拾い始めました）

この設計は、SQL アプローチに非常に似ていると思います。

プロジェクトの範囲は次のとおりです。5 つの都市。各都市には 5 つの広場があります。プラザには200店舗あります。ストアには多数の製品があります (上記のコードではモデル化されていません)

都市または広場にあるすべての店舗にクエリを実行します。都市のすべての広場。

City コレクションにすべての店舗と広場を埋め込む必要がありますか? mongodb では参照を使用せず、代わりに埋め込みドキュメントを使用すると聞いています。私の特定のプロジェクトでは、どちらがより良いアプローチですか? 私にとっては、「外部キー」の設計には満足していますが、mongodb を利用しないことを恐れています。

次のようなスキーマ設計があります。

だから、それはテーブルの中のテーブルです。私の質問は、HBase シェルを使用してテーブルにテーブルを追加するにはどうすればよいですか? 特定の列ファミリーの列に値を追加する「put」コマンドを知っています。しかし、テーブルにテーブルを追加することはできません。誰もこれを行う方法を知っていますか?

ありがとう、リアンダー

6月25日更新、

ありがとうタリク！このように修正しました（あなたの答えに触発されました）