MongoDBを使用したウェブサイト解析用のデータベース構造

Question

私は、私が取り組んでいるプロジェクトのためにMySQLでWebサイト分析システムを開発し始めましたが、スケーラビリティ、スピードなどの点で私のニーズには十分ではないとすぐに気付きました。かなりの研究をした後、MongoDBは優れた候補者として育ち続けていますが、唯一の問題は経験がなく、MySQL用の高性能/サイズのMongoDBデータベースのベストプラクティスを知らないことです。

ユーザーがウェブサイトにアクセスすると、標準情報（IP、ブラウザ情報、ウェブサイトID、URL、ユーザー名）を記録する必要があります。また、ユーザーが訪問するすべての後続ページ（現在のタイムスタンプ、URL）も記録する必要があります。ユーザーがウェブサイトを離れて10日後に戻った場合は、その訪問をログに記録し、返されたユーザー（ユーザー名で識別されるユーザー）であることも記録する必要があります。

複数のWebサイト（1秒間に500件のレコードが追加されていることがわかります）にログを記録するだけでなく、レポート機能も必要です。私はグラフなどを作成しても問題ないですが、データベースから効率的にデータを抽出する方法を知る必要があります。私は、15分ごとに活動を示すグラフを提供できるようにしたいと思いますが、実用的であれば1時間で十分でしょう。

将来的にリアルタイムのレポート作成が可能なのであれば、面白いかもしれませんが、それは現在のプロジェクトの範囲外です。

私はこの記事をhttp://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analyticsで読んだことがありますが、交通量の多いウェブサイトについては何も言及していません。私が知っているだけで数千ものレコードを扱うことができます。その投稿のコンセプトに沿って、そのコレクションから直接レポートを取り出すか、データを事前に分析して別のコレクションにアーカイブする方がよいでしょうか？

データの挿入、データベース構造、レポートに関するご意見は大変ありがとうございます。

Answer 1

（MySQLの）（スケーラビリティ、速度などの面で）私のニーズには十分であることを行っていない

うーん... Facebookは偉大な程度にMySQLを使用していますようです。 NoSQLについて言えば、それは必ずしもテクノロジーではなく、データ構造とアルゴリズムです。

---

あなたが直面しているのは、高い書き込みスループットの可能性がある状況です。あなたの問題にうまく適合する高い書き込みスループットへのアプローチの1つはshardingです。マシンの大きさとソフトウェアの効率性に関わらず、1台のマシンで処理できる書き込み数の制限があります。シャーディングは、複数のサーバーにデータを分割するため、異なるサーバーに書き込むことができます。たとえば、ユーザAMはサーバ1に書き込み、ユーザNZはサーバ2に書き込みます。

シャーディングは、分散が必要なため、すべてのシャードでの集約が難しく、複数の独立したデータベースを維持する必要があるため複雑になりますなど

これは技術的なことです：MongoDBのシャーディングは、あなたのためにほとんどの厄介なことをする自動シャーディングをサポートするので、かなりシンプルです。私はあなたが毎秒500インサートでそれを必要とは思わないが、それがそこにあることを知って良いです。

スキーマ設計では、shard keyについて考えることが重要です。これは、どのシャードがドキュメントを担当しているかを判断するために使用されます。これはトラフィックパターンによって異なる場合があります。あなたがフェアを運営するユーザーがいるとします。一年に一度、彼のウェブサイトは完全にナットですが、360日はそれがより低い交通サイトの一つです。今あなたのCustomerIdを破棄すれば、その特定のユーザーは問題につながる可能性があります。一方、VisitorIdを破棄した場合は、各シャードをヒットして簡単にcount()にする必要があります。

分析部分は、サポートしたいクエリに大きく依存します。実際の取引であるslice&diceは、特にリアルタイムに近い分析をサポートしたいと思うならば、私はこう言っています。はるかに簡単なアプローチは、ユーザーのオプションを制限し、わずかな操作しか提供しないことです。これらはキャッシュすることもできるため、毎回すべての集計を行う必要はありません。

一般に、リレーションシップを必要とする多くの機能があるため、分析が難しい場合があります。たとえば、コホート分析では、特定のユーザーグループによって生成されたログエントリのみを検討する必要があります。小文字のコホートについては$inのクエリでこのトリックが行われますが、何万人ものユーザーについて話していると、それはできません。統計的に十分なはずなので、ユーザーのランダムなサブセットのみを選択できますが、もちろんユーザーの特定の要件によって異なります。

大量のデータを分析するために、Map/Reduceはサーバー上で処理を行い、Map/Reduceは各シャードで個別に処理できるため、シャーディングの利点もあります。しかし、巨大な要因によっては、これらの仕事には時間がかかるでしょう。

blog of Boxed Iceにはこれに関する情報があります。 MongoDBを使って多くの分析データを処理したことは間違いありません。