イベント/アクティビティデータにリレーショナルデータベースとJSONオブジェクトを使用する


28

私は、標準のSQLリレーショナルデータベースまたはJSONオブジェクトを使用して、イベントまたはアクティビティに関するデータを保存するかどうかを決定しようとしているプロジェクトに取り組んでいます。

プロジェクトは複数のイベントタイプのデータを保存するため、この質問に対して1つのイベントタイプのみを説明することにしました。

ライブ音楽イベント(この質問の最後にあるJSONスキーマを使用して詳細に説明します)は、イベントが行われる場所、イベントの日時、イベントのコストなどのデータを格納するオブジェクトです。ライブ音楽イベントオブジェクトには、1対1(イベント->名前、イベント->説明)と1対多(イベント->会場、イベント->日付、イベント->チケットタイプの両方があります。 )関係。さらに、イベントオブジェクトには、パフォーマーオブジェクトにリンクする1つ以上のパフォーマーIDを含めることができます。演奏者オブジェクトは、ライブ音楽イベントで演奏しているミュージシャンのデータを保存します。

データは、単純(「x名前のイベントを検索」)と複雑(「現在の音楽ジャンルから半径「z」以内の「x」音楽ジャンルと「y」コストのイベントを検索」」の両方を使用してユーザーに照会されます場所」)クエリ。データは、ユーザーが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"
        }                                       
    }
}   

サイトの要件はわかりませんが、パフォーマー、会場、場合によっては日付で検索したいと思います。配列型で保持されているため、これは問題になりますか?
ジェフ14

関連する配列の値を検索するクエリをプログラムできませんでしたか?
zgall1 14

13
JSONはストレージ形式ではありません。確かに、テキストファイルを使用してデータを保存できますが、これは最も単純なシナリオでのみ可能です。リレーショナルデータベースよりも「新しい」JSONは、決定とは無関係です。
ロバートハーヴェイ14

1
私はそれがストレージ形式ではないことを理解しています。つまり、MongoDBまたはPostgreのJSONオブジェクトを使用して、JSON形式でデータを保存できるということです。
zgall1 14

2
@RobertHarveyと有権者、今日(2017)JSON ストア形式ですPostgreSQL 9.6以降を参照してください。
ピータークラウス

回答:


45

あなたの質問は本当に要約されると思います: いつNoSQLアプローチとRDBMSを使うべきですか? おそらく、Ajaxコンシューマーを持っているからでしょう。

もちろん、NoSQLアプローチとRDBMSアプローチのどちらを使用するかに対する答えは、基本的に、どのタイプのデータを使用し、どのコンシューマーを所有するかについてです。データが本質的にリレーショナル(かなりフラットな階層、画像や音声などの奇妙なデータ型、キーで簡単に記述できるスキーマ間の予測可能な関係)であり、最終的にビジネスインテリジェンスクエリを実行したい人が消費者に含まれる場合(アドホッククエリ)、RDBMSがその方法です。クエリをJSON表現に変換するのは非常に簡単なので、Ajaxコンシューマーに大きな負担をかけることはありません。エンドポイント(REST / SOAP /何でも)に少し変換コーディングを追加するだけです。 逆に、データが非常に階層的(深いスキーマ)で、画像、音声、ビデオなどの奇妙なデータタイプが含まれている場合、エンティティ間の関係はほとんどなく、エンドユーザーはBIを実行せず、NoSQL /保存JSONが適切な場合があります。

もちろん、これらの一般的なガイドラインでさえ確固たるものではありません。理由Googleは、Googleのファイルシステムを開発したMapReduce(ヤフーでのHadoopを構築するために切断ダグによって使用された作品)以降にBigQuery(NoSQLの指向[スキーマレス]大規模なデータを管理する方法)は正確だったので、彼らはアドホックの多くを持っていましたBIリクエストであり、管理しようとしていたテラ/ペタ/エクサ/ゼッタ/ヨッタスケールにスケールアップするリレーショナルアプローチを取得できませんでした。唯一の実用的なアプローチは、RDBMSが提供するアドホッククエリの使いやすさを犠牲にしてスケールアウトし、特定のクエリに簡単にコーディングできる単純なアルゴリズム(MapReduce)に置き換えることでした。

上記のスキーマを考えると、私の質問は基本的に次のようになります。RDBMSを使用しないのはなぜですか。しない理由はあまりありません。私たちの職業は、ファッション志向ではなく、エンジニアリング志向であると想定されているので、私たちの本能は、機能する最も簡単な解決策を選ぶことです。つまり、消費者がAjaxyの場合、エンドポイントは少し翻訳する必要があるかもしれませんが、データは非常にフラットに見え、ビジネスユーザーは音楽イベントなどのあらゆる種類のアドホッククエリを実行する可能性がありますイベントは昨年、首都から50マイル以内で最も多く参加しましたか?)

「エルフに相談してはいけません。彼らはノーとイエスの両方を言うからです。」-フロド


「私たちの職業は、ファッション志向ではなくエンジニアリング志向であるため、私たちの本能は...を選ぶことです」;)
ビンク

5

ここには、あなたが探していないかもしれない考慮事項がもっとあると思います。ここには2つの大きな懸念事項があります。

  • ストレージ
  • 検索と検索

ストレージ

データにno-sqlまたはRDBMSストアを使用する理由については、多くの意見があります。有用だと思った最も重要な項目の1つは、jsonオブジェクトの完全な構造やさまざまなタイプのオブジェクト間の関係を定義することを心配せずに、jsonオブジェクトを簡単に定義してストレージに保存できることです。NoSql dbを使用するその他の理由のいくつかは、データの自動断片化、ロケーションベースの検索、および簡単なメンテナンスです。多くの優れたNoSqlデータベースがありますが、私の個人的な好みはMongoDBです。ただし、NoSqlデータベースを以前に使用したことがない場合は、心を再配線することを学習する際に明確な学習曲線があります。私たちのほとんどは、しばらくの間RDBMSを使用していますが、その習慣を打破するには意識的な努力が必要です。さらに、作業を進めて概念をよりよく理解するにつれて、データモデルをやり直したいと思うでしょう。リファクタリングまたはリモデリングの機能がプロジェクトのオプションではない場合、私はあなたがすでに最もよく知っているものに固執することをお勧めします。

サーチ

使用可能な検索を提供する場合は、SOLRなどの専用のテキスト検索エンジンを使用して検索を実行することを強くお勧めします。テキスト検索は遅く、複数のシャードがある場合はさらに遅くなります。SOLRは、重み付けされた検索パラメーター、場所ベースの検索など、非常に高速なテキスト検索をサポートしています。ただし、SOLRはデータのプライマリストアとしては適していません。これは、イベントを追加または更新するときに、プライマリデータベースとSOLRレイヤーの両方に対する二重挿入および更新のメカニズムを作成する必要があることを意味します。さらに、古い/終了したイベントを削除して、SOLRを後で更新する必要があります。

これは多くの余分な作業のように見えますが、後で全文検索エンジンを使用する先見性に感謝します。NoSqlデータベースまたはRDBMSのどれもSOLR / Luceneのパフォーマンスと俊敏性に近づきません。


3

まず、あなたがしようとしている場合はストア任意のストレージにJSONデータではなくのNoSQLデータベースを、私は間違いなくあなたはJSONを使用することを阻止するだろう。その理由は、たとえば、データをJSONファイルとして保存すると、データのオープン、解析、ループスルーなどが非常に遅くなるためです。

つまりNoSQLRDBMSの長所と短所は何ですか?そして、それはすでにネット上で何千回も回答されています。

プロジェクトをリグレードする場合、もちろんNoSQLまたはRDBMSを使用できます。ただし、一般的にお勧めできるのは、箱から出して考えて、2つのオプションを決定するのに役立つその他の目に見えない要因を探すことです。どのオプションが開発をスピードアップできるか試してみてください?あなたが唯一の開発者ではない場合、これは他のチームメンバーにより適しています。これを販売している場合、開発者以外の顧客に安く、簡単で、一般的に適しているのはどれですか?

このようにして、最終的にどちらの方法を決定することができます。そうしないと、両方のオプションが非常にうまく適合するため、指定された情報に基づいて決定するのは非常に困難になります。


2

ほとんどのアプリケーションでは、次の要件があります。

  1. データを入力し、何らかの処理を実行し、データを保存し、データを取得してデータを照会します。データに関するレポートを生成する必要がある場合もあります。
  2. システムの異なる部分間または外部システムとのデータ交換

項目1の要件を達成するには、データを永続化する方法が必要です。通常、データの量が非常に少なく、データのタイプが単純で、広範な検索機能を必要としない場合、単純なファイル構造を使用できます。データがより複雑になると、XML(またはJSON)構造を使用して、データをファイルに保存したままにすることができます。ただし、検索はさらに問題が多くなります。データの量が増え、検索の複雑さが増すと、通常、データベースが選択され、データの永続性、クエリなどの業界標準の方法が提供されます。データベースは、大量のデータを処理し、データをすばやく効率的に保存、検索、検索できるように設計できます。

アイテム2の要件を達成するために、XML、JSONなどを含むシステム間のデータ交換を可能にするさまざまな方法があります。

これらのメソッドにより、ユーザーがデータ構造を定義でき、言語に依存しないため、異なるシステムでデータを交換できます。

特定のケースでは、JSONを正しく使用していると、一連の音楽イベントが記述されています。音楽イベントの数が増えるにつれてこのデータを検索するJSON形式でデータを保存することはできますが、速度が遅く非効率的です。

関心の分離アプローチを使用してより良いアプローチは、データを収集し、データベースに保存し、データベースのユーザー入力に基づいてクエリを実行し、結果をJSON形式でクライアント側に返してデータを表示することです。

JSONアプローチの別の問題は、データ構造の変化です。現在、構造は比較的単純です。この構造を数か月使用すると、追加のフィールドが識別されます。次に、既存のすべてのJSONオブジェクトをどうしますか?これらの更新には問題があります。

データベースを使用した場合、追加フィールドを追加するのは比較的簡単で、JSONを生成するコードのみを1か所で変更する必要があるため、新しいフィールドを使用してすべての新しいJSONを取得できます。

要するに、データ交換用のJSONとデータ永続性用のデータベース用に設計されたものに、各テクノロジーを使用します。


0

このデータを格納するためにSQLよりもNoSQLを使用する方が、クエリを実行する必要があるため、より成功すると思います。

また、一部のデータが純粋にリレーショナルであるからといって、もはやRDBMS(SQL)に永続化する必要はありません。IMOリレーショナルデータは、グラフデータベースにより適切に変換されます。

もちろん、SQLでクエリを書くこともできますが、必要な結合の数のためにパフォーマンスはひどくなります(データは1つのイベントテーブルにすべてではなく、多少正規化されると考えられます)。

ただし、結論としては、すでに保持されているデータを考慮せずにスキーマを将来変更できることを考慮して、NoSQL(したがって、JSONまたはデータベースでサポートされるその他の形式)を使用することで、より自由になります。

NoSQLを考慮すると、非常に複雑なクエリを使用する予定がある場合、グラフデータベースを調べることもできます。これらは、クエリを簡単に作成でき、非常に高速に実行できるという利点があるためです。


0

両方を使用する必要があると思いますが、それを「対」の決定とは見なしません。

リレーショナルデータベースは、リレーショナルプロパティを持つデータを高速かつ効率的に保存および取得するのに適しています。

JSONはシンプルで軽量であり、テキスト情報の保存と交換に適した構文を備えた非常に基本的な形式で生データを渡すのに理想的であるため、優れたデータ形式です。ブラウザーとサーバー間で少量のデータを渡すのに最適です。リレーショナルタイプのデータクエリに使い始めるのは、それほど簡単な形式ではありません。

したがって、データストレージにはSQLを、データ転送フォーマットにはJSONをお勧めします。

Mongo、RedisなどのnoSQLキー値オプションが存在することは事実です。これらには、JSON形式へのマッピングがより単純であるという利点がありますが、通常はクエリでの使用が少し難しくなります。それらの主なハードルは、特によく知られ、考えられるほぼすべての状況で利用可能な膨大なリソースと知識を持っているSQLと比較すると、一般のITコミュニティに不慣れであることです。


クエリでnoSQLキー値ストレージメソッドを使用する方法を十分に理解しているプログラマを見つけた場合、JSONをデータストレージ形式として使用する場合に克服する最も重要な課題は何でしょうか?
zgall1

ただ、データ構造が貧弱/平均以上であるためだろう。開発者はリレーショナルデータベースであることを知っています。ただし、これは開発者の平均的な品質であり、学習を回避する方法を学習したため、NoSQLは非リレーショナルデータに適切な選択肢になります。実際、開発者にとっては、データが本当に非-リレーショナル。ただし、DBの正しい選択を取得する必要があります。NoSQLは最初の選択で成功または失敗します。データとの一致度。
JMベッカー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.