質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
mBaaS

mBaaSとはモバイルアプリケーションでの利用に特化したBaaSです。スマートフォン向けのWebアプリケーションが必要とするサーバ側の様々な機能をインターネットを通じてサービスとして提供しています。

MongoDB

MongoDBはオープンソースのドキュメント指向データベースの1つです。高性能で、多くのリトルエンディアンシステムを利用することができます。

NoSQL

NoSQL(not only SQL)は、リレーショナルデータベース管理システムとは異なるデータベースシステムを指す言葉です。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

1回答

6506閲覧

NoSQLにおけるSNSの「フォロー/フォロワー」の仕組み

noramimiyuma

総合スコア25

mBaaS

mBaaSとはモバイルアプリケーションでの利用に特化したBaaSです。スマートフォン向けのWebアプリケーションが必要とするサーバ側の様々な機能をインターネットを通じてサービスとして提供しています。

MongoDB

MongoDBはオープンソースのドキュメント指向データベースの1つです。高性能で、多くのリトルエンディアンシステムを利用することができます。

NoSQL

NoSQL(not only SQL)は、リレーショナルデータベース管理システムとは異なるデータベースシステムを指す言葉です。

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

1クリップ

投稿2017/01/11 11:12

サーバサイドにmBaaSを使用して、SNSのようなスマートフォンアプリを作ろうと思っています。

使おうと思っているmBaaSのデータストア(DB)がmongoDBで実装されているため、NoSQLの特性を考慮してスキーマ設計を行う必要がある状況です。

本題ですが、
SNSにおけるフォロー、フォロワーのような関係をどのように実現するかで詰まってしまいました。

RDBのように中間テーブルを設ける場合も、ユーザーテーブルに配列形式でフォロー、フォロワーのカラムを設ける場合も、どちらも整合性の観点でトランザクション処理が必要になると思いますが、mongoDBにはトランザクション処理に対応していないはずです。

ユーザーテーブルに「フォロー」カラムのみ設けた場合、トランザクションは不要になりますが、この場合「フォロワー」に関する情報を扱うのが大変難しくなりそうだと思いました。(フォロワー数を調べるために全ユーザーのフォローカラムのレコードを調べる必要がある)

この問題をクリアする解決策はありますでしょうか。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

たとえば、次のようなスキーマが考えられると思います。

{ "followee": 1024, "follower": 1025, "start": ISODate("2017-01-11T11:12:00") }

ここでfolloweeは被フォローユーザ、followerはフォローしているユーザのIDです。つまり、フォロー-被フォロー関係のひとつひとつにドキュメントを作ります。そして、各ユーザ固有の情報についてはユーザ毎に別のドキュメントを作ります。

個々のユーザのドキュメントに配列で全てのフォロー情報を持たせるようなことをすると、要素数が多くなったときにメモリ使用や速度の効率が悪くなります。それにご質問でおっしゃっているように、フォロー情報は簡単に取れても被フォローの情報を取るのは難しくなります。一般的に言って、少数の情報だけを含む小さなドキュメントをたくさん作ることは有用です。

ところで、RDBではトランザクションによって更新の同時性を保証しようとしますが、多くのNoSQLにはそのような仕組みがありません。さらにシャーディングやレプリケーションを行っていれば、更新が反映されるまでのタイムラグはノード毎に変動します。同時性が揺らぐわけで、データの厳密な整合性は保証されないとも言えます。

上で述べた方法はRDBでのリンクテーブルに似ていますが、トランザクションがない以上、整合性は保証されません (たとえば、あるユーザが退会した瞬間に別のユーザがフォロワ一覧を取得すると、不完全なユーザ情報が取れるかもしれません)。そういうことは気にしないようにアプリを作る必要があります (たとえば、不完全な情報は無視するなど)。SNSなどのアプリでは、多少の不整合は許されることが多いかもしれません。

逆に言うと、トランザクションを必要とするような厳密な整合性を要求するシステムでは、RDBを使うべきです。

投稿2017/01/14 11:19

編集2017/01/14 11:44
ikedas

総合スコア4227

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

noramimiyuma

2017/01/17 22:44 編集

たいへん丁寧なご回答をいただきましてありがとうございました。 1つのフォロー情報のみ保有するドキュメントを毎回生成する方法で納得しました。 mongoDBはおろかNoSQLでシステムを開発しようとすること自体が今回初めてだったので、概念的な話もしていただいて自分の中で理解度が高まりました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問