ランダムな長い文字列（最大100文字）を格納するために大量のユーザーが使用するデータベースがあります。テーブルの列は、userid、stringid、および実際の長い文字列になります。
したがって、次のようになります。
Useridは一意になり、stringidはユーザーごとに一意になります。
このアプリは単純なtodoリストアプリのようなものなので、各ユーザーの平均todoは50になります。ユーザーがいつでも特定のタスクを削除できるようにするために、stringidを使用しています。
このtodoアプリは、3年間で700万のタスクが発生する可能性があり、MySQLを使用するのが怖いと思います。
だから私の質問は、これが長い文字列で大量のデータを処理する実際の推奨される方法であるかどうかです（すべての新しいタスクは新しい行を取得します）？そして、MySQLはこの種のプロジェクトに選択するのに適切なデータベースソリューションですか？
私はまだ大量のデータを経験したことがなく、遠い将来のために自分自身を救おうとしています。
これは「大量の」データの問題ではありません（mysqlは大量のデータを問題なく処理し、2 mio行はどのような場合でも「大量」ではありません）。
MySqlはリレーショナルデータベースです。したがって、正規化できるデータがあり、それがすべてのデータポイントが1回だけ保存されることを保証する多数のテーブルに分散されている場合は、MySql（またはMaria、またはその他のリレーショナルデータベース）を使用する必要があります。
スキーマのないデータがあり、NoSqlデータベースを使用できる/使用する必要があるよりも速度が一貫性よりも重要である場合。個人的には、ToDoリストがNoSqlからどのように利益を得るかわかりません（この場合は実際には問題ではありませんが、現在のところ、ほとんどのprogrammigフレームワークはNosqlよりもリレーショナルデータベースをより適切にサポートしていると思います）。
「大量のデータ」と見なすものに関係なく、最新のDBエンジンは大量のデータを処理するように設計されています。「リレーショナルかNoSQLか」という質問。どのオプションがより多くのデータをサポートできるかについてではありません。リレーショナルソリューションとNoSQLソリューションが異なれば、大量のデータを異なる方法で処理します。
MySQLは何百万ものレコードを処理できますが、SQLiteは処理できません（少なくともそれほど効果的ではありません）。Mongo（NoSQL）は、コレクションをメモリ（およびファイルシステム）に保持しようとするため、メモリが限られているサーバーでは100万レコード未満で失敗することがわかりましたが、シャーディングを提供することで、より効果的にスケーリングできます。
要点は次のとおりです。保存するレコードの数は、SQLとNoSQLの決定に反映されるべきではありません。その決定は、データの保存方法と取得方法に任されている必要があります。データはすでに正規化されているようです（例：UserID）。ユーザーを削除するときに一貫性が必要な場合（TODOアイテムも削除される）、SQLソリューションを使用することをお勧めします。
これは非常に単純なリレーショナルユースケースです。ここではNoSQLの必要性はわかりません。
あなたが提示する表はうまくいくはずですが、私はあなたがこれを提示するのと同じように、私は個人的に複合主キーの必要性に疑問を投げかけます。おそらく、すべてのレコードに一意性を適用するためだけに、stringidに主キーがあります。useridとstringidにまたがる複合主キーではなく。次に、ユーザーIDに通常のインデックスを付けます。
この理由は、stringidのみでクエリを実行する場合（つまり、削除または更新の場合）、インデックスを活用するために両方のフィールドで常にクエリを実行する必要があるわけではありません（または、stringidに個別のインデックスを追加する必要があります。各フィールドによるクエリを有効にするuserid。これは、インデックスによって占有されるメモリとディスクのスペースを意味します）。
MySQLが適切なソリューションであるかどうかに関しては、これは本当にあなたが判断することになるでしょう。MySQLは、2つの整数IDフィールドに200万行と2つのインデックスを持つテーブルを問題なく処理できるはずです。これは、これらのインデックスをメモリに保持するのに十分なメモリが割り当てられていることを前提としています。MySQLの操作に関して利用できる情報は確かにたくさんあるので、単に学習しようとしているのであれば、それはおそらく良い選択でしょう。
すべてのクエリが特定のユーザーIDを参照すると思います。また、stringidは、実際のタスクテキスト（ランダムな文字列）ではなく、内部で使用されるダミー値であると想定しています。
複合主キーがオンになっているInnoDBテーブルを使用すると{userid, stringid}、クラスター化インデックスの動作方法により、必要なすべてのパフォーマンスが得られます。