MySQLにデータをJSONとして保存する

これはn00bのことだと思いました。そして、だから、私はそれをやったことがない。次に、FriendFeedがこれを実行し、実際にDBのスケールが向上し、レイテンシが減少したことを確認しました。私がこれをやるべきかどうか知りたいです。そして、もしそうなら、それを行う正しい方法は何ですか？

基本的に、すべてをMySQLにCouchDBの一種のDBとして保存する方法を学ぶのに適した場所はどこですか？すべてをJSONとして保存する方が簡単で迅速なように思えます（構築する必要がなく、レイテンシが少なくなります）。

また、DBにJSONとして保存されているものの編集、削除などは簡単ですか？

CouchDBとMySQLは2つの非常に異なる獣です。JSONは、CouchDBにデータを保存するネイティブな方法です。MySQLでは、JSONデータを単一のフィールドにテキストとして保存するのが最善の方法です。これは、RDBMSに格納する目的を完全に無効にし、すべてのデータベーストランザクションを非常に複雑にします。

しないでください。

そうは言っても、FriendFeed はMySQLに加えて非常にカスタムなスキーマを使用しているようです。それは本当に何を保存したいかに依存します。データベースシステムを悪用する方法について明確な答えはほとんどないので、それはあなたにとって理にかなっています。記事が非常に古く、MongoとCouchに対する彼らの主な理由が未熟だったので、MySQLがあなたのためにそれをカットしなかった場合、私はこれら2つを再評価します。彼らは今までに大きく成長しているはずです。

みんなのコメントは間違った角度から来ているようです、JSONコードをPHP経由でリレーショナルDBに保存しても問題ありません。実際、このような複雑なデータをロードして表示する方が高速ですが、次のような設計上の考慮事項があります。検索、インデックス作成など

これを行う最良の方法は、ハイブリッドデータを使用することです。たとえば、日付に基づいて検索する必要がある場合、MySQL（パフォーマンスチューニング）はPHPよりもはるかに高速で、会場の距離の検索などの場合、MySQLも多くなります。より高速です（検索にアクセスできないことに注意してください）。検索する必要のないデータは、JSON、BLOB、または本当に必要と思われるその他の形式で保存できます。

アクセスする必要のあるデータは、たとえば基本的なケースごとの請求書システムなど、JSONとして非常に簡単に格納されます。それらはRDBMSからはあまりメリットがなく、正しいHTMLフォーム構造があればjson_encoding（$ _ POST ['entires']）だけでJSONに格納できます。

MongoDBの使用に満足してうれしく思います。MongoDBが引き続き使用できることを願っていますが、MySQLが常にレーダーから外れるとは思わないでください。一部の機能と特徴（たとえアーカイブされたデータやビジネスレポートを廃止するだけの場合でも）

MySQL 5.7は、MongoDBおよび他のスキーマレスドキュメントデータストアに類似したネイティブJSONデータタイプをサポートするようになりました。

JSONサポート

MySQL 5.7.8以降、MySQLはネイティブJSONタイプをサポートしています。JSON値は文字列として保存されず、代わりにドキュメント要素への迅速な読み取りアクセスを可能にする内部バイナリ形式を使用します。JSON列に格納されたJSONドキュメントは、挿入または更新されるたびに自動的に検証され、無効なドキュメントがエラーを生成します。JSONドキュメントは作成時に正規化され、=、<、<=、>、> =、<>、！=、<=>などのほとんどの比較演算子を使用して比較できます。サポートされている演算子と、JSON値を比較するときにMySQLが従う優先順位とその他のルールについては、JSON値の比較と順序付けをご覧ください。

MySQL 5.7.8には、JSON値を操作するための多数の関数も導入されています。これらの関数には、以下にリストされているものが含まれます。

1. JSON値を作成する関数：JSON_ARRAY（）、JSON_MERGE（）、JSON_OBJECT（）。セクション12.16.2「JSON値を作成する関数」を参照してください。
2. JSON値を検索する関数：JSON_CONTAINS（）、JSON_CONTAINS_PATH（）、JSON_EXTRACT（）、JSON_KEYS（）、JSON_SEARCH（）。セクション12.16.3「JSON値を検索する関数」を参照してください。
3. JSON値を変更する関数：JSON_APPEND（）、JSON_ARRAY_APPEND（）、JSON_ARRAY_INSERT（）、JSON_INSERT（）、JSON_QUOTE（）、JSON_REMOVE（）、JSON_REPLACE（）、JSON_SET（）、JSON_UNQUOTE（）。セクション12.16.4「JSON値を変更する関数」を参照してください。
4. JSON値に関する情報を提供する関数：JSON_DEPTH（）、JSON_LENGTH（）、JSON_TYPE（）、JSON_VALID（）。セクション12.16.5「JSON値属性を返す関数」を参照してください。

MySQL 5.7.9以降では、JSON_EXTRACT（column、path）の省略形としてcolumn-> pathを使用できます。これは、WHERE、ORDER BY、GROUP BY句など、SQLステートメントで列識別子が発生する可能性がある場合は、列のエイリアスとして機能します。これには、SELECT、UPDATE、DELETE、CREATE TABLE、およびその他のSQLステートメントが含まれます。左側はJSONカラムの識別子でなければなりません（エイリアスではありません）。右側は引用符で囲まれたJSONパス式で、列値として返されるJSONドキュメントに対して評価されます。

->およびJSON_EXTRACT（）の詳細については、セクション12.16.3「JSON値を検索する関数」を参照してください。MySQL 5.7でのJSONパスのサポートについては、JSON値の検索と変更をご覧ください。セカンダリインデックスと仮想生成列も参照してください。

より詳しい情報：

https://dev.mysql.com/doc/refman/5.7/en/json.html

jsonの文字は、ストレージなどの特別なものではありません。

{、}、[、]、'、a-z、0-9 ....本当に何も特別で、テキストとして保存することができます。

あなたがしようとする最初の問題はこれです

{profile_id：22、ユーザー名： 'Robert'、パスワード： 'skhgeeht893htgn34ythg9er'}

データベースに格納されているものは、独自の手順を実行してmysqlのjsondecodeを開発しない限り、更新するのはそれほど簡単ではありません。

UPDATE users SET JSON(user_data,'username') = 'New User';

そのため、最初にjsonを選択し、デコードし、変更し、更新する必要があるので、理論的には、適切なデータベース構造の構築により多くの時間を費やすことになるでしょう。

私はjsonを使用してデータを保存しますが、メタデータのみ、頻繁に更新されないデータで、ユーザー固有のものとは関係ありません。次に、json形式のつまみのURLを使用します。

クエリを使用してJSONデータを取得するのがいかに難しいかを示すために、これを処理するために作成したクエリを共有します。

配列やその他のオブジェクトは考慮されず、基本的なデータ型のみが考慮されます。列の4つのインスタンスをJSONを格納する列名に変更し、myfieldの4つのインスタンスをアクセスするJSONフィールドに変更する必要があります。

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

それは本当にあなたのユースケースに依存します。レポートにまったく価値がなく、他のテーブルとのJOINを介してクエリされない情報を保存している場合、JSONとしてエンコードされた単一のテキストフィールドにデータを保存することは理にかなっています。

これにより、データモデルが大幅に簡略化されます。ただし、RobertPittによって言及されているように、このデータを正規化された他のデータと組み合わせることができると期待しないでください。

これは古い質問ですが、Googleの検索結果の上部に表示されているので、質問されてから4年後に新しい回答を追加することには意味があると思います。

まず第一に、JSONをRDBMSに格納する際のサポートが向上しています。PostgreSQLへの切り替えを検討することもできます（MySQLはv5.7.7以降JSONをサポートしています）。PostgreSQLは、より多くの機能をサポートすることを除いて、MySQLと非常によく似たSQLコマンドを使用します。追加された機能の1つは、JSONデータ型を提供し、保存されているJSONをクエリできるようになったことです。（これに関するいくつかの参照）たとえば、phpでPDOを使用したり、Laravelでeloquentを使用したりして、プログラムで直接クエリを作成していない場合は、サーバーにPostgreSQLをインストールしてデータベース接続設定を変更するだけです。コードを変更する必要すらありません。

他の回答が示唆しているように、ほとんどの場合、RDBMSにデータをJSONとして直接保存することはお勧めできません。ただし、いくつかの例外があります。考えられる状況の1つは、リンクされたエントリの数が可変のフィールドです。

たとえば、ブログ投稿のタグを保存するには、通常、ブログ投稿のテーブル、タグのテーブル、および一致するテーブルが必要です。したがって、ユーザーが投稿を編集する必要があり、その投稿に関連するタグを表示する必要がある場合は、3つのテーブルをクエリする必要があります。これは、一致するテーブル/タグテーブルが長い場合、パフォーマンスに大きな影響を与えます。

タグをJSONとしてブログ投稿テーブルに保存すると、同じアクションで必要なのは単一のテーブル検索だけです。これにより、ユーザーはブログの投稿をすばやく編集できるようになりますが、タグにリンクされている投稿に関するレポートを作成したり、タグで検索したりすると、パフォーマンスが低下します。

データベースの非正規化を試みることもできます。データを複製し、両方の方法でデータを保存することにより、両方の方法のメリットを享受できます。データとより多くのストレージスペースを格納するために少し時間が必要になります（これは、より高い計算能力のコストと比較すると安価です）。

これを検討する理由は2つだけです。

• 正規化されたアプローチではパフォーマンスは十分ではありません
• 特に流動的/柔軟/変化するデータを簡単にモデル化できない

ここに自分のアプローチについて少し書きました：

NoSQLデータストアを使用してどのようなスケーラビリティの問題が発生しましたか？

（トップの回答を参照）

JSONでも十分に高速ではなかったため、カスタムテキスト形式のアプローチを使用しました。働いた/私たちのためにうまく働き続けます。

MongoDBのようなものを使用していない理由はありますか？（MySQLが「必須」である可能性があります。好奇心旺盛です）

この質問に答える誰もが@decezeを除いて1つの重要な問題を見逃しているようです- 仕事に適したツールを使用してください。リレーショナルデータベースにほとんどすべての種類のデータを保存させ、Mongoにリレーショナルデータを処理させることができますが、どのようなコストがかかりますか？スキーマ設計からアプリケーションコードまで、開発と保守のすべてのレベルで複雑さを導入することになります。パフォーマンスへの影響は言うまでもありません。

2014年には、特定のタイプのデータを非常にうまく処理する多くのデータベースサーバーにアクセスできます。

• Mongo（ドキュメントストレージ）
• Redis（Key-Valueデータストレージ）
• MySQL / Maria / PostgreSQL / Oracle / etc（リレーショナルデータ）
• CouchDB（JSON）

私はRabbirMQやCassandraのようないくつかを逃したと確信しています。私のポイントは、保存する必要があるデータに適切なツールを使用することです。

アプリケーションでさまざまなデータの保存と取得が本当に必要な場合は、非常に高速で（そして誰もそうではありません）、アプリケーションで複数のデータソースを使用することをためらわないでください。最も人気のあるWebフレームワークは、複数のデータソース（Rails、Django、Grails、Cake、Zendなど）をサポートしています。この戦略は、複雑さをアプリケーションの特定の領域、ORM、またはアプリケーションのデータソースインターフェイスに制限します。

以下は、JSON配列のキーを列に保存/更新する関数と、JSON値を取得する別の関数です。この関数は、JSON配列を格納する列の名前がjsonであると想定して作成されます。PDOを使用しています。

保存/更新機能

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

ここで、$ uidはユーザーのID、$ key-更新するJSONキーであり、その値は$ valと記載されています。

値取得関数

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

どこ $キーがの鍵となるJSONの我々は値を必要とし、そこから配列。

MySQLにJSONを格納するための初期サポートがMySQL 5.7.7 JSONラボリリース（linuxバイナリ、ソース）に追加されました！このリリースは、2013年に公開された一連のJSON関連のユーザー定義関数から成長したようです。

この初期のネイティブJSONサポートは、INSERTでのJSON検証、プリアンブル内のルックアップテーブルを含む最適化されたバイナリストレージ形式、JSN_EXTRACT関数がすべてのアクセスで解析するのではなくバイナリルックアップを実行できるようにする最適化されたバイナリストレージ形式など、非常にポジティブな方向に向かっているようです。また、特定のJSONデータ型を処理およびクエリするための新しい関数が多数あります。

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

私見、上記はこの新しい機能の優れた使用例です。多くのSQLデータベースにはすでにユーザーテーブルがあり、進化する一連のユーザー設定に対応するために無限のスキーマ変更を行うのではなく、1つのJSON列を1つJOIN離れた場所に置くのが最適です。特に、個々のアイテムに対してクエリが必要になる可能性は低いためです。

まだ始まったばかりですが、MySQLサーバーチームはブログで変更を伝えるという素晴らしい仕事をし て います。

JSONをmysqlデータベースに格納すると、実際にはRDBMSの使用目的が損なわれると考えられています。ある時点で操作されたり、報告されたりするデータには使用しません。複雑さを増すだけでなく、使用方法によってはパフォーマンスに簡単に影響する可能性があるからです。

しかし、実際にこれを行う理由の可能性を他の誰かが考えているかどうか、私は興味を持っていました。ロギングの目的で例外を設けることを考えていました。私の場合、可変量のパラメーターとエラーを含む要求をログに記録したいと思います。この状況では、リクエストのタイプ、および取得されたさまざまな値のJSON文字列を含むリクエスト自体のテーブルを使用したいと思います。

上記の状況では、リクエストはログに記録され、JSON文字列フィールド内で操作またはインデックス付けされることはありません。ただし、より複雑な環境では、このタイプのデータに対してより意図的なものを使用して、そのシステムに格納しようとするでしょう。他の人が言ったように、それは本当にあなたが達成しようとしていることに依存しますが、標準に従うことは常に長寿と信頼性を助けます！

JSONはPostgreSQLデータベースでも有効なデータ型です。ただし、MySQLデータベースはまだ正式にJSONをサポートしていません。しかし、それは焼けています：http : //mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

また、一部のデータをデータベース内の文字列にシリアル化した方がよい多くの有効なケースがあることにも同意します。主な理由は、定期的に照会されない場合や、独自のスキーマが変更される可能性がある場合です。それに対応するデータベーススキーマを変更したくない場合があります。2番目の理由は、シリアル化された文字列が直接外部ソースからのものである場合、それらをすべて解析し、使用するまでコストをかけずにデータベースにフィードしたくない場合があります。そのため、新しいMySQLリリースがJSONをサポートするのを待っています。これは、異なるデータベース間の切り替えが簡単になるためです。

私はプロジェクトのあらゆるものを記録するためにjsonを使用していますが、実際には3つのテーブルを使用しています！1つはjsonのデータ用、もう1つはjson構造の各メタデータのインデックス用（各メタは一意のIDによってエンコードされます）、もう1つはセッションユーザー用です。ベンチマークはコードのこの初期状態では定量化できませんが、たとえば、ユーザービュー（インデックスとの内部結合）でカテゴリ（またはユーザーとして何でも）を取得しましたが、非常に低速でした（非常に低速） 、mysqlで使用されるビューは良い方法ではありません）。この構造の検索モジュールは、私がやりたいことは何でもできますが、この完全なjsonデータレコードの概念では、mongodbの方が効率的だと思います。私の例では、カテゴリツリーとパンくずリストを作成するためにビューを使用しています。行うには非常に多くのクエリ！アパッチ自体がなくなった！実際、この小さなWebサイトでは、ツリーとブレッドクラムを生成するphpを使用しています。データの抽出は検索モジュール（インデックスのみを使用）によって行われ、データテーブルは更新のみに使用されます。必要に応じて、すべてのインデックスを破棄し、データごとに再生成し、逆の作業を実行して、すべてのデータ（json）を破棄し、インデックステーブルのみを使用して再生成できます。私のプロジェクトは若く、phpとmysqlの下で実行されていますが、ノードjsとmongodbを使用すると、このプロジェクトの効率が上がることがあります。

できると思うなら、jsonを使用してください。そして、それが間違いだったら忘れてください。良い選択か悪い選択かを試してみてください。

低

フランスのユーザー

私はこれが本当に遅いことを知っていますが、テーブルをあるポイントまで正規化するRDBMS標準を維持し、データをJSONにそのポイントを超えるテキスト値として格納するハイブリッドアプローチを使用した同様の状況がありました。したがって、たとえば、正規化のRDBMSルールに従って、4つのテーブルにデータを格納します。ただし、動的スキーマに対応する4番目の表では、データをJSON形式で格納しています。データを取得するたびに、JSONデータを取得して解析し、Javaで表示します。これはこれまでのところ機能しており、ETLを使用して正規化された方法で、テーブル内のjsonデータに変換するフィールドにインデックスを付けることができます。これにより、ユーザーがアプリケーションで作業しているときに最小限のラグに直面し、フィールドがデータ分析などのためにRDBMSフレンドリーな形式に変換されることが保証されます。

この要旨を使用できます：https : //gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

サーバーにインストールした後（スーパーではなくroot権限が必要）、次のようなことができます：

select extract_json_value('{"a":["a","2"]}','(/a)')

これをa 2 使用すると、JSON内で何でも返す ことができます。良い点は、MySQL 5.1、5.2、5.6をサポートしていることです。また、サーバーにバイナリをインストールする必要はありません。

古いプロジェクトcommon-schemaに基づいていますが、今日でも機能してい ますhttps://code.google.com/archive/p/common-schema/