web-dev-qa-db-ja.com

NoSQL：非構造化データとは何ですか？

現在、mssqlサーバーベースのソリューションを使用して、リソースのエッジで実行しています。

負荷に取り組むための次の動きに関して、多くの従来のオプションがあります。

  • より高速なCPUとIOを購入する
  • 一部の顧客を分割してサーバーを分離する
  • クラスタにデータベースを移動

ライセンスとハードウェアまたは時間の点で、すべてが高価です。したがって、システム全体をnosqlエンジンcassandraが約束するスケーラブルなソリューションに移動することにより、別のオプションを追加したいと思います。

それでも、私は定かではなく、noSQLデータベースの経験もないので、「非構造化」データの構造を理解する必要があります。

このアプリケーションでは、基本的に、ユーザーがさまざまな方法で入力したデータを「Key-Value」リストとして保存します。 （Orderのような）ヘッド要素を含む親テーブルがあり、（Order_Linesのような）注文の内容を構成するキーと値のペアを持つ子テーブルがあります。

ビジネス的には、OrderとOrderLinesは1つの単位です。ただし、RDBMSにより、これらはテーブルに格納され、常に結合する必要があります。

操作中に、上部のみをロードすることを選択する場合がありますが、ほとんどの場合、先頭行といくつかのKVPをロードして、いくつかの有用な情報を表示します。

たとえば、概要リストでは、ヘッド識別子といくつかの値を各行の列に表示します。

更新：あらゆる種類のフォームを保存します。したがって、基本的には「ドキュメント」を保存します。それにもかかわらず、これらのフォームを準備し、値、並べ替えなどで検索する必要があります。データアクセス制御により、データベースにもう1つの複雑なレイヤーが追加されます。

ご想像のとおり、特定のKVPの量と可用性はオブジェクトごとに異なります。さまざまなデータの組み合わせに対して数千のテーブルを作成する必要があるため、オブジェクトの種類ごとに単一のテーブルを作成する有効な可能性はありません。

この種の「辞書」のようなデータセットは、noSQLデータベースに保存した方がよいでしょうか？これによるパフォーマンス上のメリットはありますか？ cassandraこれらのヘッド+ KVPを1つのデータセットとしてモデル化しますか？cassandra Webページといくつかのチュートリアルを見ると、それほど多くはないという印象がありますデータ編成の点でRDBMSとcassandraの違い-各行のリストに5つのKVPを選択する場合は、同じ量の結合を残すことができます。

啓蒙は歓迎されています、そして問題を説明する論文へのポインターも大丈夫です。

sql-serverdatabase-designnosqlcassandra
9
thst

区別する必要があるいくつかの概念があります。 1つは構造に関するもので、もう1つはスキーマに関するものです。

構造化データは、アプリケーションが受け取る各バイトの意味を事前に知っているデータです。良い例は、センサーからの測定です。対照的に、Twitterストリームは構造化されていません。スキーマとは、DBMSにどのように構造を伝達するかということで、これを強制するように要求されます。 DBMSが格納するデータを解析する量を制御します。 SQL Serverなどのスキーマが必要なDBMSは、未解析データ（varbinary）またはオプションで解析されたデータ（xml）と完全に解析されたデータ（列）を格納できます。

NoSQL DBMSは、解析（Key-Valueストア）を行わないことから始まります。 Cassandraは、この点で比較的豊富な機能を提供します。それらがリレーショナルストアと著しく異なるのは、データの均一性です。テーブルが定義されると、その定義に一致するデータのみがそこで保持されます。ただし、Cassandraでは、列とファミリが定義されている場合でも、同じテーブル内の2つの行が互いに似ている必要はありません。1つの行（行とも呼ばれる）の量を決定するのはアプリケーション設計者の責任です。文書）と、ポインターでリンクされて個別に保持されるもの実際には、どれだけの非正規化が必要ですか。

利点は、単一の順次読み取りでデータの完全なセットを取得できることです。これは速いです。欠点の1つは、アプリケーションプログラマーであるあなたが、このデータストアにアクセスするすべてのコードについて、すべてのデータの整合性と下位互換性の問題に常に責任を持つことです。それを正しく行うのは難しい場合があります。また、データの1つの視点に固定されます。注文番号で行をキーイングする場合、特定の1つの製品、地域、または顧客の販売についてどのように報告しますか？

3
Michael Green

NoSQLデータベースIMHOの主流にもかかわらず、このようなテクノロジーを採用するかどうかの決定は、現在のパフォーマンスだけでなく、保存された情報に従って必要な成果に基づいて行う必要があります。これは、おそらくSQLデータベースに固執し、ハードウェアを改善することが最善の選択肢であることを意味します。

しかし、さらに私はあなたの質問で私に考えさせられた何かを読みました。データベースの現在の状態についてはそれほど多くありませんが、文章"ユーザーが入力したデータは、基本的にさまざまな方法で" Key-Value "リストとして保存されます問題が起こらないかどうかを考えさせます物理リソースの不足ではなく、貧弱なデータモデルである。 「従来の」SQLデータベースで驚異的なパフォーマンスを発揮する、非常に大きなテーブル（+100億行）を管理してきました。

もちろん、現在のソリューションに関する情報がほとんどないため、適切なデータモデルであなたを評価することはできませんが、他のオプションとともにデータモデルを再検討することを考えてください。そこに引っかき傷があるかもしれません。

通常、Key-Valueリストは、直面する必要のあるさまざまなキーがわからないために最終状態でモデルを実装できない場合、または可能ないずれかの値が必要になる場合のトレードオフとして問題ありません。特定の要素のキー。しかし、実装するときは、一般的な使用例を特定し、データモデルの決定が最適かどうかを判断するのに十分な量の情報を収集した後、通常、そのような決定を再考したいと思います。特定の数のキーがあることがわかっている場合は、従来の方法で通常のテーブルの設計をいくつかベンチマークしてみてください

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

...対応するインデックスを追加します。それを試して、両方のアプローチで実行計画を測定してください。一度に複数のキーを収集すると、特に驚かれるかもしれません。何よりも、データブロックのサイズを小さくする必要があるため、パフォーマンスが向上するからです。

これが役立つか、少なくとも可能性が広がり、調査の新しい道が開かれることを願っています。

5
LironCareto