mysql でキー/値ストアを実装しようとしています
グローバル ID 用とシリアル化されたデータ用の 2 つの列を持つユーザー テーブルがあります。
問題は、ユーザーのデータが少しでも変更されるたびに、シリアル化されたデータをデータベースから取得し、データを変更してから、再シリアル化してデータベースに戻す必要があることです。ユーザーのデータに非常に小さな変更がある場合でも、これらの手順を繰り返す必要があります (db 自体のセルを更新する方法がないため)。
基本的に、この問題に直面したときに人々が通常使用するソリューションを検討していますか?
おそらく、JSON データを前処理し、フィールドに分割された適切な MySQL 行としてデータを挿入する必要があります。
入力は JSON であるため、データを変換するためのさまざまな方法があります。
あなたの場合、多くの小さな変化が起こると述べました。それらはどこで発生しますか？それらはリストのメンバーで発生しますか? 上位属性？
更新が主に JSON データの一部のリスト メンバーで発生する場合、実際にはすべてのメンバーを別のテーブルで個別の行として表す必要があります。
属性で更新が発生した場合は、それをフィールドとして表します。
あなたの場合、前処理のコストは問題ないと思います。
キー/値ストアがある場合、シリアル化されたデータがJSONであると仮定すると、データベースを毎回更新するのではなく、memcacheを更新してからプッシュするため、memcachedが一緒にある場合にのみ有効です。それをバックグラウンドでデータベースに追加します。したがって、データベース内のアドレスのみのように、JSONデータの個々のフィールドではなく、値全体を更新する必要があります。memcachedからデータを高速に更新および取得できます。データベースには複雑な関係がないため、データベースからmemcacheへのデータのプッシュとプルが高速になります。
正直なところ、あなたのソリューションはデータベースを美化されたファイル システムとして使用しています。アプリケーションのコアであるアプリケーション データには、このアプローチをお勧めしません。
私の意見では、リレーショナル データベースを使用する最善の方法は、リレーショナル データ (テーブル、列、主キーと外部キー、データ型) を格納することです。これが機能しない状況があります。たとえば、データが実際にドキュメントである場合や、データ構造が事前にわかっていない場合です。このような状況では、リレーショナル モデルを拡張するか、ドキュメント データベースまたはオブジェクト データベースに移行することができます。
あなたの場合、シリアル化されたデータをリレーショナル データとしてモデル化できるかどうか、またデータベースが必要かどうかをまず確認します。その場合は、リレーショナル モデルに移行してください。データベースが必要であるが、データをリレーショナル セットとしてモデル化できない場合は、シリアル化されたデータを個々のキーと値のペアに抽出するキーと値のモデルを使用できます。これは少なくとも、ドキュメント全体を変更するのではなく、個々のデータ フィールドを更新/追加できることを意味します。キー/値は RDBMS に自然に適合するわけではありませんが、現在のアーキテクチャからはわずかなジャンプである可能性があります。
これが問題になると、人々はキー/値ストアを使用せず、正規化されたリレーショナル データベース スキーマを設計して、更新可能な個別の単一値列にデータを格納します。