イベント/アクティビティデータに対するリレーショナルデータベースとJSONオブジェクトの使用
私は、標準のSQLリレーショナルデータベースを使用するか、JSONオブジェクトを使用してイベントやアクティビティに関するデータを保存するかを決定しようとしているプロジェクトに取り組んでいます。
プロジェクトは複数のイベントタイプのデータを保存するため、この質問では1つのイベントタイプのみを説明することにしました。
ライブミュージックイベント（この質問の最後でJSONスキーマを使用して詳細に説明）は、イベントが発生する場所、イベントの日時、イベントの費用などのデータを格納するオブジェクトです。ライブミュージックイベントオブジェクトには、1対1（イベント->名前、イベント->説明）と1対多（イベント->会場、イベント->日付、イベント->チケットタイプ）の両方があります。 ）関係。さらに、イベントオブジェクトには、パフォーマーオブジェクトにリンクする1つ以上のパフォーマーIDを含めることができます。出演者オブジェクトは、ライブ音楽イベントで演奏しているミュージシャンに関するデータを格納します。
単純な（「x名でイベントを検索」）と複雑な（「xの音楽ジャンルと「y」のコストで現在のイベントから「z」の範囲内のコストでイベントを検索）の両方を使用して、ユーザーがデータをクエリします。場所」）クエリ。データは、ユーザーがWebフォームを使用して送信します。
おそらく定義されたJSONスキーマからわかるように、私はもともとJSONデータを使用してこのデータを格納しようとしていましたが、私のデータは純粋にリレーショナルであるため、古いメソッドに固執する必要があると言う人もいます。
私のニーズを踏まえて、各アプローチの長所と短所についての考えをいただければ幸いです。ご不明な点がございましたら、お気軽にお問い合わせください。
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
RDBMSと比較してNoSQLアプローチを使用する必要があるのはいつですか？JSONに早く着手しました（NoSQLのような決定） 、おそらくAjaxの消費者がいるからでしょう。
もちろん、NoSQLアプローチとRDBMSのどちらのアプローチをいつ使用するかに対する答えは、基本的には、どのタイプのデータを処理していて、どのようなコンシューマーが期待しているのかということです。データが本質的にリレーショナルであり（かなりフラットな階層、画像や音声などの奇妙なデータタイプではなく、キーで簡単に説明できるスキーマ間の予測可能な関係）、コンシューマーは最終的にビジネスインテリジェンスクエリを実行したい人を含むことが予想される（アドホッククエリ）、RDBMSを使用する方法です。クエリをJSON表現に変換するのはかなり簡単なので、Ajaxコンシューマーに大きな負担をかけることはありません。エンドポイント（REST/SOAP /その他）に小さな変換コーディングを追加するだけです。 逆に、データが非常に階層的（深いスキーマ）で、画像、オーディオ、ビデオなどの奇妙なデータ型が含まれている場合、エンティティ間にはほとんど関係がなく、エンドユーザーがBIを実行しない場合は、NoSQL/JSONの格納が適切な場合があります。
もちろん、これらの一般的なガイドラインでさえしっかりしているわけではありません。理由 Googleが開発したGoogleファイルシステム、MapReduce（Doug CutingがYahooでHadoopを構築するために使用した作業） 以降のBigQuery（大規模なデータを管理するNoSQL指向の[スキーマのない]方法）は、正確に理由アドホックBIリクエストが多く、管理しようとしていたテラ/ペタ/エクサ/ゼッタ/ヨッタスケールにスケールアップするためのリレーショナルアプローチを取得できなかったため。唯一の実用的なアプローチは、スケールアウトして、RDBMSが提供するアドホッククエリの使いやすさを犠牲にし、特定のクエリに対してかなり簡単にコーディングできる単純なアルゴリズム（MapReduce）に置き換えることでした。
上記のスキーマを考えると、私の質問は基本的に：なぜRDBMSを使用しないか（---）ないのでしょうか。私がそうしない理由の多くはわかりません。私たちの職業はファッション志向ではなく、エンジニアリング志向であることになっているので、私たちの本能は、機能する最も簡単なソリューションを選ぶことですよね？つまり、コンシューマーがAjaxyの場合、エンドポイントは少し変換を行う必要があるかもしれませんが、データは非常にフラットに見え、ビジネスユーザーは音楽イベントなどのあらゆる種類のアドホッククエリを実行する可能性が高いようです（イベントは、昨年の首都から50マイル以内に最も多く参加されましたか？）
'エルフの弁護士に行くな、彼らはノーとイエスの両方を言うからだ'-フロド
あなたが探していないかもしれない考慮事項がもっとあると思います。ここには2つの大きな懸念があります。
- ストレージ
- 検索と検索
ストレージ
データにno-sqlまたはRDBMSストアを使用する理由については多くの意見があります。私たちが有用だと思った最も重要な項目の1つは、jsonオブジェクトの完全な構造や異なるタイプのオブジェクト間の関係を定義することを心配する必要なく、jsonオブジェクトをストレージに簡単に定義して格納できることです。 NoSql dbを使用する他の理由のいくつかは、データの自動シャーディング、ロケーションベースの検索、および簡単なメンテナンスです。多くの優れたNoSqlデータベースが世の中にありますが、私の個人的な好みはMongoDBです。ただし、これまでにNoSqlデータベースを使用したことがない場合は、心を再配線する方法を学習するときに明確な学習曲線があります。私たちのほとんどは、しばらくの間RDBMSを使用しており、その習慣から抜け出すには意識的な努力が必要です。さらに、自分の努力に沿って進み、概念の理解を深めると、データモデルをやり直したくなるでしょう。リファクタリングまたはリモデリングする機能がプロジェクトのオプションではない場合、私はあなたがすでに最もよく知っているものに固執することをお勧めします。
探す
使用可能な検索を提供する場合は、専用のテキスト検索エンジン [〜＃〜] solr [〜＃〜] などを使用して検索を実行することを強くお勧めします。テキスト検索は遅く、複数の断片がある場合はさらに遅くなります。 SOLRは、重み付け検索パラメーター、位置ベースの検索など、非常に高速なテキスト検索をサポートしています。ただし、SOLRはデータのプライマリストアとしては適していません。つまり、イベントを追加または更新するときに、プライマリデータベースとSOLRレイヤーの両方にデュアル挿入と更新を行うメカニズムを作成する必要があります。さらに、古い/終了したイベントを削除して、SOLRを後で更新する必要があります。
これは多くの追加作業のように見えますが、後で全文検索エンジンを使用する先見性に感謝します。 NoSqlデータベースまたはRDBMSのいずれも、SOLR/Luceneのパフォーマンスと俊敏性に近づきません。
まず、Store JSONデータをNoSQLデータベースではなく任意のストレージに保存しようとしている場合は、JSONを使用しないことをお勧めします。その理由は、たとえば、データをJSONファイルとして保存すると、それを開いたり、解析したり、ループしたりするのが非常に遅くなるためです。
つまり、私はあなたの質問を次のように絞ることができます：NoSQLおよび[〜＃〜] rdbms [〜＃〜]の長所と短所は何ですか？そして、それはすでにネット上で何千回も回答されています。
プロジェクトを再グレードすると、もちろんNoSQLまたは[〜＃〜] rdbms [〜＃〜]を使用できます。ただし、一般的にお勧めできるのは、箱から出して考え、2つのオプションのどちらかを決定するのに役立つ他の目に見えない要因を探すことです。開発をスピードアップできるオプションを確認してみてください。他のチームメンバーに適しています-あなたが唯一の開発者でない場合。あなたがこれを販売しているなら、どれがより安く、より簡単で、そして一般的にあなたの非開発者の顧客により適していますか？
このようにして、最終的にどちらの方法に進むかを決定できます。そうしないと、両方のオプションが非常によく合うため、与えられた情報に基づいて決定することは本当に困難になります。
ほとんどのアプリケーションでは、
- データを入力し、いくつかの処理を実行し、データを保存し、データを取得してクエリします。データに関するレポートを生成する必要がある場合もあります。
- システムの異なる部分間または外部システムとのデータ交換
アイテム1の要件を達成するには、データを永続化する方法が必要です。通常、データの量が非常に少なく、データのタイプが単純で、広範な検索機能を必要としない場合は、単純なファイル構造を使用できます。データがより複雑になると、XML（またはJSON）構造を使用して、データをファイルに保存したままにすることができます。しかし、検索はさらに問題になります。データの量が増加し、検索の複雑さが増すにつれて、通常はデータベースが選択されます。これにより、データの永続性、クエリなどの業界標準の方法が提供されます。 。
項目2の要件を達成するために、XML、JSONなど、システム間のデータ交換を可能にするさまざまな方法があります。
これらのメソッドを使用すると、データ構造をユーザーが定義でき、言語に依存しないため、異なるシステムでデータを交換できます。
特定のケースでは、JSONを正しく使用して、一連の音楽イベントを記述しています。音楽イベントの数が増えるにつれて、データをJSON形式で保存してこのデータを検索することもできますが、速度が遅く、非効率的です。
懸念の分離アプローチを使用する場合は、データを収集してデータベースに格納し、データベースでのユーザー入力に基づいてクエリを実行し、結果をクライアント側にJSON形式で返し、データを表示します。
JSONアプローチのもう1つの問題は、データ構造の変更です。現在、あなたの構造は比較的単純です。この構造を数か月使用すると、追加のフィールドが識別されます。次に、既存のすべてのJSONオブジェクトをどのように処理しますか？これらを更新すると問題が発生します。
データベースを使用した場合、フィールドを追加するのは比較的簡単で、JSONを生成するコードのみを1か所で変更するだけでよいので、新しいフィールドを持つすべての新しいJSONを取得できます。
簡単に言えば、データ交換のためのJSONとデータ永続性のためのデータベースのために設計されたものに対して、各テクノロジーを使用します。
このデータを格納するためにSQLよりもNoSQLを使用すると、クエリを実行する必要があるため、成功すると思います。
また、一部のデータが純粋にリレーショナルであるからといって、もはやRDBMS（SQL）に永続化する必要があるという意味ではありません。 IMOリレーショナルデータは、グラフデータベースに変換しやすくなります。
もちろん、SQLでクエリを作成することもできますが、必要な結合の数が原因でパフォーマンスがひどくなります（データがある程度正規化され、すべてが1つのイベントテーブルに含まれるとは限らないことを考慮してください）。
ただし、結論として、すでに永続化されたデータを考慮せずに将来スキーマを変更できることを考慮して、NoSQL（JSONまたはデータベースでサポートされているその他の形式）を使用すると、より自由になります。
非常に複雑なクエリを使用する場合は、NoSQLを考慮してグラフデータベースを調べることもできます。これにより、クエリを簡単に作成でき、非常に高速に実行できるという利点があります。
私はあなたが両方を使うべきだと思います、そして私はそれを「対する」決定として見ません。
リレーショナルデータベースは、リレーショナルプロパティを持つデータの高速で効率的な保存と取得に適しています。
JSONはシンプルで軽量であり、テキスト情報の保存と交換に適した構文を備えた非常に基本的な形式で生データを渡すのに最適であるため、優れたデータ形式です。ブラウザとサーバーの間で少量のデータを渡すのに最適です。リレーショナルタイプのデータクエリで使い始めるのは簡単な形式ではありません。
したがって、データストレージにはSQL、データ転送形式にはJSONをお勧めします。
Mongo、RedisなどのSQLのKey-Valueオプションがないことは事実です。これらのオプションには、JSON形式へのマッピングがより簡単になるという利点がありますが、通常、クエリで使用するのは少し難しいです。それらの主なハードルは、特によく知られており、考えられるほとんどすべての状況で利用可能な膨大なリソースと知識を持たないSQLと比較した場合、一般的なITコミュニティによる不慣れです。