0

プロジェクトで膨大な量のデータを処理します。ビッグデータの概念について読んだことはありますが、まだ使用したことはありません。しかし、これらすべてのビッグ データ ドキュメントを読んでも、自分の要件にビッグ データが必要なのか、それとも従来のリレーショナル データベースで処理するのが適切なのか、まだわかりません。

ここに私のDBに関するいくつかの情報があります。

私のメイン DB は、さまざまなデータ ソースのリポジトリです。これらのデータ ソースはそれぞれ、同じ種類のデータ (同じドメイン内のデータ) を処理しますが、一部のデータ ソースには他のフィールドでは使用できない余分なフィールドが含まれており、一部のデータ ソースには含まれていないフィールドが含まれています。つまり、これらのデータ ソースのデータ フィールドには同じものもあれば、異なるものもあります。したがって、コア DB にはこれらすべてのフィールドが含まれている必要があります。コア DB の合計フィールド数は約 2000 フィールドで、1,000 万から 2,000 万のレコードが含まれている可能性があります。

私のコア DB で行われている DB 操作は、データの挿入と読み取り (検索) です。膨大な量のデータを扱うため、ビッグデータの概念を使用することを考えていました。しかし、これがビッグデータに適しているかどうかはまだわかりません。一部のデータには同様の特性 (同じフィールド) があり、一部には追加情報が含まれているためです。そして、DB であらゆる種類の高速検索が必要です。ありがとう。

4

1 に答える 1

6

MySQL のようなリレーショナル データベースは、数十億の行/レコードを処理できるため、ユース ケースによって決定が異なります。ビッグ データ NoSQL システムの場合、各システムの長所と制限がユース ケースにどのように対応するかを理解することが非常に重要です。

MySQL の例を次に示します。

2 番目の例では、MySQL に保存していた 9 億 5,000 万行をはるかに超える 3,590 億行に相当する行を保存する必要があるため、MySQL から Redis に移行しました。

高速検索の要件があるということを考えると、データベースによってサポートされる検索が異なるため、必要な検索の種類を理解することが重要です。さらに、サポートされている一部の検索では、機能が制限されている場合があります。コア データ ストア機能を超える検索要件がある場合、多くの場合、全文ソリューションが追加されます。たとえば、データ ストアに Cassandra を使用し、検索コンポーネントに Elasticsearch を使用します。

この決定の背景を説明するために、CAP 定理に関する要件を検討することは有益かつ重要です。CAP 定理では、分散コンピューター システムが次の保証のすべてではなく一部を提供できると述べています (ウィキペディアから)。

  • 一貫性 (すべてのノードが同じデータを同時に見る)
  • 可用性 (すべての要求が成功したか失敗したかに関する応答を受け取るという保証)
  • 分断耐性 (任意のメッセージ損失またはシステムの一部の障害が発生しても、システムは動作し続けます)

http://en.wikipedia.org/wiki/CAP_theorem

MySQL および NoSQL ソリューションを含むさまざまなデータベース ソリューションがどのようにマップされているかをグラフで確認できます。

ここに画像の説明を入力

ユースケースについてさらに情報を提供すると、より詳細な回答を得ることができます。

于 2015-03-23T07:33:12.047 に答える