（投稿+返信）スレッドを保存するために選択するデータベーステクノロジー
私は新しいアプリケーションを設計しており、ディスカッションスレッド（投稿+返信、FacebookやStackOverflowの投稿と非常によく似ている）を管理するパフォーマンスに後で影響を受けたくありません。
スレッドを永続化するためにどの種類のデータストア/データ形式を選択するのかと思います。質問への回答を探しましたが、実際に見つけたのは、「この要件を処理するようにRDBMS設計を調整する方法」だけでした。
しかし、RDBMSは本当にこれに最適ですか？私が見つけた答えのほとんどは、何とか時代遅れだったり、レガシーシステムを調整したりしたもので、No-SQL DBを考慮していませんでした。
提案されたすべてのasnwer（たとえば here および here など）を使用して大量のリクエストを処理すると、ORDER BYが必要になるため、データのスケーリング時にパフォーマンスが低下すると思います条項。
高速な読み取りパフォーマンスのために、スレッド全体を1つのjsonとして格納することを考えました。しかし、スレッドコンポーネントにセキュリティロールを適用する必要があるため、更新、メンテナンス、およびトラフィックに特に問題が発生すると思います（一部のユーザーは一部の返信を表示でき、その他のユーザーは表示できません）。
実際、私はNo-SQL DBにはあまり興味がなく、hbaseとSOLRを少し使っただけで、ほとんどの経験はRDBMSでした。ドキュメントデータベースはブログの投稿に適していると思いますが、私はそれを実際に経験したことがありません。
どのようなデータベーステクノロジーがこのようなニーズに最適であるかについての推奨事項はありますか？
重要な注意：特定の製品に関する推奨は要求しませんまたはリソースですが、テクノロジーの選択に関する議論についてです（RDMBSとNo-SQL DB）。
編集：以下の回答のおかげで、私は要件をより詳細に再検討しました。それらは次のとおりです。
1-データは「問題」と「アクション」のネストされたセットであり、それぞれに任意の数のコメントを含めることができます（つまり、問題にはアクションがあり、アクションには問題があり、アクションと問題のそれぞれにコメントがあります）。
2-会話は5人を超えるユーザーを処理できません（変換は、「問題」と「アクション」のセット、およびそれらの相対的なコメントです。
3-ユーザーのセットごとに一度に1つの会話のみがアクティブです
4-会話のサブセットには、残りの会話以外のユーザーを含めることができます（ただし5人まで）
5-システムが配布されます（将来）
6- RDBMS以外の新しいテクノロジーを使用することは良いことです。
7-フロントエンドはモバイルアプリです
上記から、特にポイント5と6の場合、ドキュメントDBを選択する方が優れていると思います。また、データは（説明したように）リレーショナルではなく、階層データのモデリング+結合の強制はデータのスケーリング時に適切ではないためです。 。
技術の変更を含むあらゆる提案を支援し、開いてくれたすべての人に再び感謝します
NoSQLの支持者のほとんどは、スケーリング/パフォーマンスの問題を誇張しています。
これは明らかに単純化された見方ですが、NoSQLが普及している大きな理由の1つは、Googleが使用しているためです。グーグルがそれを使うなら、それは良いに違いない。しかし、Googleには膨大なデータ要件があります。インターネット検索にもかかわらず、彼らのソース管理リポジトリは非常に大きいため、独自のカスタムソース管理システムを作成する必要がありました。 この問題は発生しません。
データのサイズは、この決定において重要な要素となり、数百万のレコードではなく、10億または1兆のレコードで重要になります。何百万ものレコードスペースにある限り、適切に維持する限り（つまり、適切なインデックスと正規化されたテーブルデザインがある限り）、リレーショナルデータベースに問題が発生することはありません。
私が働いている場所では、最近、Apache Hiveを使用して概念実証プロジェクトを行いました。 Apache HiveはNoSQLデータベースです。私たちはまだ何百万ものレコードの領域にいましたが、完全にロールアウトすると、数十億のレコードになります。プロジェクトの目的は、特定のイベントに関する情報を得るためにテレメトリデータをマイニングすることです。 NoSQLがこれに適している理由は、データが比較的フラットであるためです。つまり、関係や結合がなく、データの性質上、データのインデックス作成の試みに抵抗します。 Hiveが具現化するMap/Reduce関数は、この状況に非常に適しています。
しかし、データが何らかの形で通常のビジネスオペレーションに関連している場合（説明したシナリオと同様）、リレーショナルデータベースはほとんどの場合、より賢明な選択です。データサイズは、FacebookスケールまたはGoogleスケールでのみ要素になります。そのスケーリングの問題が発生した場合、それは良い問題であり、解決するために必要な資金が手に入ります。
パフォーマンスの懸念を過大評価していると思います。リレーショナルデータベースは、ほとんどの状況で十分なパフォーマンスを提供する以上の能力を備えており、Apache Hiveのシナリオとは異なり、状況は目新しいものではありません。