MongoDB とは何か？

Scrapeless Web Unlocker は、収集サービスが MongoDB ドキュメントとして検証・保存できる公開 Web コンテンツを取得します。

MongoDB は、フィールドと値の集合としてレコードを保存するドキュメントデータベースです。1 つのドキュメントはネストされたオブジェクトや配列を含むことができ、その構造はアプリケーションコードで使われるオブジェクトに近づけることができます。これにより、MongoDB は、商品、記事、あるいはソース観測などのエンティティを中心に自然にレコードがグループ化される場合に有用な選択肢となります。

ドキュメントモデルは変化を許容しますが、信頼できるデータには依然として契約が必要です。あるレコードが価格をテキストとして保存し、別のレコードが通貨なしの金額として保存しているコレクションは、投入は容易でも正しくクエリすることが難しくなります。スキーマに関する決定は、消えてなくなるのではなく、アプリケーションおよびデータベース設計の中へと移動します。

ドキュメントとコレクションがデータを整理する

MongoDB のコレクションは、すべてのドキュメントが同一のフィールドを含むことを要求せずに、ドキュメントをグループ化します。 MongoDB ドキュメントアーキテクチャ はネストされた値、クエリ、およびトランザクション操作をサポートします。このモデルにより、アプリケーションが読み書きの仕方に合致する場合、関連情報を 1 つの場所にまとめて配置できます。

MongoDB は保存されるドキュメントに BSON を使用します。BSON は通常の JSON よりも広い型の集合をサポートするため、日付や識別子はドライバーとアプリケーションの境界を越えても意図した型を保持できます。JSON に似た便利な表示形式があるからといって、すべての値が単に JSON の文字列や数値であることの証明にはなりません。

一方で JSON 交換形式 は、ドキュメントが API やエクスポート経由で到着する場合にも有用です。ドキュメントを JSON に変換するには、より豊かなデータベース型について明示的な判断が必要になることがあります。その判断をエクスポート契約の一部とすることで、別の利用者が意図した意味を再構成できるようにします。

コレクション名も、そのレコード単位を表すべきです。商品、ソースページ、観測結果は、それぞれが商品タイトルを含んでいたとしても、異なる単位です。識別子なしにそれらを結合すると、ドキュメントが永続的なエンティティを表しているのか、そのエンティティに関するある一時点の証拠を表しているのかが曖昧になります。

柔軟なスキーマには安定した意味が必要

柔軟なスキーマは進化するレコードを支え、安定したフィールドの意味はそれらのレコードを有用なものに保ちます。ソース観測は、新しい任意フィールドを追加しても、すべての過去ドキュメントにそれを含める必要はありません。それでも利用者は、そのフィールドが欠如しているのが「利用不能」「収集されなかった」「適用不能」のどれを意味するのかを知る必要があります。

必須の識別およびタイミングに関するフィールドは早い段階で定義しましょう。公開商品の観測には、ソース識別子、商品識別、観測時刻、および抽出バージョンが必要かもしれません。任意属性は、その後であっても多様に変化できますが、レコードを生成したソースイベントへと遡れる能力は失われません。

生の入力と受け入れたフィールドを分離しましょう。ソースレスポンスを保持しておくことは抽出処理の説明に役立ちますが、生ペイロードを自動的にアプリケーションの信頼済みレコードにすべきではありません。受け入れられたドキュメントは、どのフィールドがバリデーションを通過し、どの任意値が依然として不明なのかを識別すべきです。

埋め込みと参照はアクセスパターンに従う

埋め込みは関連情報を 1 つのドキュメント内に保存し、参照は他所の情報へのリレーションシップを保存します。どちらを選ぶかは、どのデータが一緒に読み出されるか、どのように変化するか、ネストされた集合が有用な上限なしに成長し得るかに基づいて決定します。

商品レコードは、その商品ページで常に一緒に表示される小さな集合の現在属性を埋め込むことがあるでしょう。一方で、履歴価格観測は継続的に増え、自身の保持ポリシーを持つことができるため、別の観測コレクションに分けることでライフサイクルを明確にできるかもしれません。これはこのアプリケーションに基づいたモデリング上の判断であり、あらゆる商品データベースに通用する普遍的な規則ではありません。

重複には更新ポリシーが必要です。カテゴリラベルが多数のドキュメントにコピーされている場合、カテゴリを変更するとコレクション全体に異なるバージョンが残る可能性があります。それが望ましい履歴的文脈となることもあれば、偶然生じた不整合となることもあります。埋め込まれた値がスナップショットなのか、現在のリレーションシップなのかを決めておきましょう。

リレーショナル設計を機械的にドキュメントへ変換したり、ネストが可能だからといってあらゆるリレーションシップを埋め込んだりすることは避けてください。まずは実際のクエリや更新操作から始めましょう。書き込みには便利でも、読み出しのたびにアプリケーション側で繰り返し組み立てを行わなければならないレコードは、その初期形態が示唆するほどワークロードに適合していないかもしれません。

インデックスはクエリを支援し、書き込みの仕事を増やす

インデックスは、MongoDB が毎回コレクション全体を走査することなくドキュメントを特定できるようにします。インデックスは、重要なアプリケーションリクエストで使用されるフィールドと並び順に対応しているべきです。利用可能なすべてのフィールドにインデックスを貼ることは、それらのリクエストを理解する代わりにはなりません。

1 つのソースに対して最近の受け入れ済み観測を表示するコレクターを考えます。そのクエリは、ソース識別と観測時刻、そして有効性条件を組み合わせます。そのアクセスパターンを中心に関連するクエリプランを設計・検証すべきであり、ドキュメント内に現れるというだけの理由で無関係なインデックスを作成すべきではありません。

インデックスはストレージを消費し、書き込み時に維持されなければなりません。そのため、あらゆる観測を記録するコレクションは、ほとんど読み取り専用のカタログとは異なるインデックス予算を持つ可能性があります。現実的なドキュメントサイズ、更新頻度、およびクエリパターンでワークロードを計測してから、パフォーマンスに関する約束を行いましょう。

一意性ルールはビジネス上の意味も表現します。受け入れられた観測値が、あるソースと収集間隔の中で一意であるなら、そのアイデンティティを意図的に定義してください。新たに生成されたデータベース識別子だけでは、同じビジネス観測が異なる識別子の下で複数回挿入されることを防げません。

公開プロダクト観測のモデリング

プロダクト観測ドキュメントでは、ソースとなるエンティティと、それを観測する行為を区別する必要があります。プロダクトのアイデンティティは連続する観測を結び付け、観測のアイデンティティは別個の収集イベントを区別します。これにより、アプリケーションは、すべてのダウンロードが新しいプロダクトを記述していると見なすことなく、変更を比較できます。

表示価格と正規化された金額を区別できるように維持してください。正規化された金額には、意図された通貨と関連する解釈ルールを付随させるべきです。ページが価格の範囲や会員価格を提示している場合は、都合のよい数値を選び通常のプロダクト価格とラベル付けするのではなく、そのカテゴリを明示的に記録してください。

価格が存在しない場合も、アプリケーションが説明できる観測結果として残すべきです。それは、フィールドが利用できないこと、レスポンスが却下されたこと、あるいはソースページが価格を公開していないことを反映しているかもしれません。これらの条件は履歴トレンドに対して異なる意味を持つため、すべてを数値のゼロにしてはいけません。

更新、トランザクション、および同時書き込み

MongoDB は 1 ドキュメントに対するアトミックな操作をサポートし、適したワークロード向けにマルチドキュメント・トランザクションを提供します。それでもアプリケーション側では、自身の一貫性要件に合った更新境界を選ぶ必要があります。機能が利用可能であることは、すべてのコレクターがそれをどのように使うべきかを決定するものではありません。

現行プロダクトビューでは、複数のワーカーが異なる時刻に同じプロダクトを観測することがあります。順序付けルールがなければ、より遅く完了した古い観測が、新しい値を上書きしてしまう可能性があります。観測コンテキストと明示的な更新ポリシーを使用し、処理順が暗黙のうちに「鮮度」の定義にならないようにしてください。

履歴観測コレクションでは、受け入れられた観測値を個別に保持することで、一部の上書きのあいまいさを回避できます。そのうえで、現行ビューは、文書化されたルールに基づいて受け入れ済み履歴から導出できます。これはモデリング上の責任を増やしますが、表示されている値がどのように選ばれたかを説明しやすくします。

「 distributed collection architecture 」の議論は、収集とストレージをサービス間で分散するための文脈を提供します。引き継ぎに責任を持たせてください。ワーカーは、ページのダウンロードやローカル変換が終わっただけではなく、意図した受け入れドキュメントが宛先に到達した後にはじめて完了を報告すべきです。

レプリケーション、シャーディング、保持には異なる役割がある

レプリケーションは可用性のためにデータベース状態のコピーを維持し、シャーディングはデプロイ全体にデータを分散させます。どちらも、ドキュメントのアイデンティティ、クエリアクセス、保持を設計する必要性を取り除くものではありません。あいまいなデータモデルにインフラを追加すると、その不整合を調査しにくくなることがあります。

シャードキーは、データがどのように分散・アクセスされるかに影響します。一見一意に見えるという理由だけでフィールドを選ぶのではなく、実際のクエリと書き込みパターンに照らして評価してください。分散に関する決定には、コレクションの成長の仕方や、一般的な操作が多くのパーティションに接触する必要があるかどうかも含めるべきです。

バックアップとリストアは、ライブのレプリケーションとは別物です。望ましくない更新はレプリカへ広がり得るため、履歴リカバリには独自の手順が必要です。どれだけの受け入れ済み履歴を保持すべきか、それをどのように復元できるか、そして復元によってアプリケーションで利用可能なレコードが得られることをチームがどのように検証するかを定義してください。

生データと受け入れられた観測値では、保持期間が異なる場合があります。アプリケーションが必要とする証拠だけを保持し、適切に保護し、期限切れの診断用資料は意図的に削除してください。収集需要と Scrapeless pricing を運用計画に含め、新しい作業をスケジュールする前に、ソースカバレッジの拡大にどの程度のコストがかかるかを把握しておきましょう。

まとめ

MongoDB は、柔軟なフィールドと明示的なアクセスパターンを持つドキュメントを中心にアプリケーションデータを構成します。信頼できる収集データには、安定したアイデンティティ、バリデーション、およびソースエンティティと観測を明確に区別することが必要です。まずはプロダクトがサポートしなければならないクエリと更新から出発し、それに合わせて埋め込み、リファレンス、インデックスを選択してください。元のページが変更された後でも、各受け入れドキュメントを説明できるだけのソースコンテキストを保持しましょう。