序文として
約1年前、私たちのチームは1つの新しい英語テレビチャンネルのサイトで働く絶好の機会を得ました。 そのようなほとんどのプロジェクトと同様に、エンターテインメントおよび情報プログラム、ニュースに焦点を当て、ソーシャルネットワークを通じて訪問者と対話します。
顧客には2つの重要な要件がありましたが、プロジェクトの実装に使用するテクノロジーを選択する際に、これらの要件をガイドしました。
- データの一貫性が非常に重要です。
- このサイトは、十分な数の同時ユーザーと連携する必要があります。
データの整合性を保証するために、MS SQLでリレーショナル形式で保存し、サイトのユーザー部分の速度を確保するために、mongodbを使用しました。 各タイプのページについて、独自の非正規化されたドキュメントのコレクションが作成されています。 したがって、データは最初にMS SQLに保存され、そこから必要なすべてのmongo DBコレクションに公開されます。
そして、なぜmongaを使用するのですか？1つのSQLでできるなら、あなたは尋ねますか？ 選択を正当化するために、いくつかの例を検討してください。
最初の例
テレビ番組のエンティティ図の例から始めましょう。 番組の表、季節、エピソード、エピソードの放送日があります。
プログラムページには、プログラムの説明、プログラムシーズンのリスト、エピソードの簡単な説明を含むエピソードのリスト、エピソードのリリース日、およびそのページへのリンクが含まれています。 リレーショナルデータベースから必要なデータを取得するには、3つのオプションがあります。
- 結合に関する1つの大きな要求。 良い-ページごとに1つのリクエスト。 悪い-大量の重複データと、データベースサーバーの負荷の深刻な増加。
- ORMからの4つのクエリ、各テーブルに1つ。 良好-リクエストで追加情報が取得または返されることはありません。 悪い-実際には4つのクエリで、それぞれに対して作業単位を実行します。つまり、データベースに接続するコンテキストが4回作成および削除されます。 オプションは非常に伝統的であり、非常に優れています;短所はキャッシュをねじ込むことで解決されます;
- 4つのクエリを実行し、4つのデータセットを返すストアドプロシージャ。 良い-追加データなし、クライアントからデータベースへの1つのクエリ。 悪い-.netのORMを見つけるのは非常に困難です。このような機会は、何らかの種類の消化可能な形式で実装されています。
一般的に、すべてがかなり良いように見えますが、Mongでテレビ番組の非正規化されたコレクションを使用する場合、何も考える必要はありません-識別子によってデータを引き出す1つのリクエストを行うだけです-そしてそれだけです。
2番目の例
このサイトには、ニュース、プログラム、instagramとtwitterからの投稿、天気、広告、地下鉄の中断に関する情報など、最新情報を表示するページがいくつかあります。
構造が非常に細分化されているこのデータは共通の性質を持ち、同じページに表示されます-最新情報はメインページに表示され、それに関連するイベントのみが地域のページに表示され、記事のみがニュースページに表示されます。 SQLでは、タイルの構造が大きく異なるため、タイルの各タイプは個別のテーブルに保存されます。 リレーショナルデータベースからのこのようなサンプルは、小さなローカルの地獄に変わります。データベースに対するクエリの数は、タイルの各タイプが追加されるたびに増加します。これは、コードに直接そのようなサンプルを記述する複雑さを考慮していません。 生活を楽にするために、テーブルとメタデータを使用できます。データフィルタリングは簡素化されますが、それらをアプリケーション側のオブジェクトに接着する必要が追加されます。 そして、この状況では、mongaのようなnosqlリポジトリは問題の理想的な解決策になります。 Monga onHabréについての以前の記事で、スキームが存在しないことについて言及すると、「どうして？ 常にスキームがあります。」 このタイプの質問は完全に合理的ですが、それについて少し説明します。 このコンテキストにスキームが存在しないのは、異なるスキームでデータを保存する機能ですが、同じコレクション内では同じ性質です。 これらを使用して、インデックスを構築し、データをフィルタリングするだけでなく、アプリケーションで簡単に操作できる、適切で望ましいタイプのオブジェクトに簡単にデシリアライズできます。
お支払い方法
sqlとnosqlを組み合わせて使用すると、非常に魅力的で便利に見えます。 しかし、私たちが知っているように、利便性のために何かを支払う必要があります。 私たちの場合、これはsqlからmongodbにデータを公開するための機能を記述する必要があります。 私たちの意見では、これは手頃な価格です。
結論の代わりに
私は、アプリケーションが記述されている言語と、sqlおよびnosqlツールに執着しないようにしました。 mongaの代わりに、他の非リレーショナルストレージを代用できます。