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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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