私の小さなデータベースを最適化する必要があります。遅すぎるため、別の解決策が見つかるかもしれません。データベース構造を構築する別の方法
まず、データベースに格納されているデータについて説明します。 2つのがありますオブジェクト：usersはとのはmessages
ユーザー
を言わせているようなものがあります：
+----+---------+-------+-----+
| id | user_id | login | etc |
+----+---------+-------+-----+
| 1 | 100001 | A | ....|
| 2 | 100002 | B | ....|
| 3 | 100003 | C | ....|
|... | ...... | ... | ....|
+----+---------+-------+-----+
このテーブル内部には問題はありません。 （user_idは、別のアプリケーションで使用される。idとuser_idを恐れていないのですか、それはここにする必要があります。）
メッセージ
そして、2番目の表は、いくつかの問題を抱えています。
+----+---------+------+----+
| id | user_id | from | to |
+----+---------+------+----+
| 1 | 1 | aab | bbc|
| 2 | 2 | vfd | gfg|
| 3 | 1 | aab | bbc|
| 4 | 1 | fge | gfg|
| 5 | 3 | aab | gdf|
|... | ...... | ... | ...|
+----+---------+------+----+
editメッセージへの必要はありませんが、ユーザのためのメッセージの更新リストに機会があるはずです：各ユーザーは、このような例のためのメッセージを持っています。たとえば、外部サービスはすべてのユーザーのメッセージをdbに送信し、リストを更新する必要があります。 そして最も重要なことは、約30人のユーザーがおり、平均的なユーザーが500以上のメッセージを持っているということです。もう一つの問題は、フィールドfromを検索して一致数を計算しなければならないことです。私は結合で簡単なSQLクエリを設計しましたが、データを取得するには時間がかかります。
これは非常に大量のデータです。私はRDS（私はPostgreSQLを使用）を使わないことに決め、Clickhouseのようなデータベースに移動することに決めました。
しかし、私は例えばClickhouseがUPDATEをサポートしていないという問題に直面しました。
この問題を解決するために、メッセージを1つの行として保存することに決めました。だから、テーブルMessagesは次のようにする必要があります：
Here I'd like to store messages in JSON format
{"from":"aaa", "to":bbe"}
{"from":"ret", "to":fdd"}
{"from":"gfd", "to":dgf"}
||
\/
+----+---------+----------+------+ And there I'd like to store the
| id | user_id | messages | hash | <= hash of the messages.
+----+---------+----------+------+
私はmessages塔内全文検索がようにいくつかの時間資源を節約し、と思います。
ご意見はありますか？ :)
あなたの質問は非常に幅広いと言わなければなりません。まず第一に、どのタイプが由来し、それもカラムですか？第二に、PostgreSQLの使用時にどのようにインデックスを使用しましたか？パーティションを調べましたか？ –
'from'と' to'はvarchar（255）ですが、私はパーティションを見ていません...あなたはチュートリアルを提供できますか？ – Ascelhem