データサイエンスとデータベース
非従来型のデータストレージに関するデータエンジニアガイド
データエンジニアリング
の台頭とともに ビッグデータ データサイエンスでは、多くのエンジニアリングの役割が挑戦され、拡大されています。 1つの新時代の役割は データエンジニアリング 。
もともと、データエンジニアリングの目的は、外部データソースの読み込みとデータベースの設計（データを収集、操作、保存、分析するためのパイプラインの設計と開発）でした。
それ以来、ビッグデータの量と複雑さをサポートするように成長しました。そのため、データエンジニアリングは現在、Webクロール、データクレンジング、分散コンピューティング、データの保存と取得など、幅広いスキルをカプセル化しています。
データエンジニアリングとデータエンジニアにとって、データの保存と取得は、データの使用方法と分析方法とともに、パイプラインの重要なコンポーネントです。
最近では、多くの新しいさまざまなデータストレージテクノロジーが登場しています。しかし、データエンジニアリングに最適で、最も適切な機能を備えているのはどれですか？
ほとんどのエンジニアは、PostgreSQL、MSSQL、MySQLなどのSQLデータベースに精通しています。これらのデータベースは、行指向のストレージを備えたリレーショナルデータテーブルで構造化されています。
それに応じて、負の実質金利を持つことは、経済を刺激する可能性があります
これらのデータベースがどれほどユビキタスであるかを考えると、今日はそれらについて説明しません。代わりに、人気が高まっており、データを処理するためのさまざまなアプローチを導入している3種類の代替データストレージについて説明します。
データエンジニアリングのコンテキスト内では、これらのテクノロジは検索エンジン、ドキュメントストア、および列ストアです。
- サーチエンジン テキストクエリに優れています。
LIKEなどのSQLデータベースのテキスト一致と比較すると、検索エンジンは、すぐに使用できる優れたクエリ機能と優れたパフォーマンスを提供します。 - ドキュメントストア 従来のデータベースよりも優れたデータスキーマ適応性を提供します。多くの場合JSONとして表される個々のドキュメントオブジェクトとしてデータを保存することにより、スキーマの事前定義は必要ありません。
- 柱状店 単一列のクエリと値の集計を専門としています。
SUMなどのSQL演算およびAVGは、同じ列のデータがハードドライブ上でより近くに保存されるため、列ストアではかなり高速です。
この記事では、次の3つのテクノロジーすべてについて説明します。 Elasticsearch 検索エンジンとして、 MongoDB ドキュメントストアとして、そして AmazonRedshift 柱状ストアとして。
代替データストレージを理解することで、それぞれの状況に最適なストレージを選択できます。
データのインデックス作成、シャーディング、集計方法。 つぶやき
これらのテクノロジーを比較するために、データのインデックス作成、シャーディング、集計の方法を調べます。
各データインデックス戦略は、特定のクエリを改善し、他のクエリを妨げます。
どのクエリが最も頻繁に使用されるかを知ることは、採用するデータストアに影響を与える可能性があります。
データベースがデータをチャンクに分割する方法論であるシャーディングは、より多くのデータが取り込まれるにつれてインフラストラクチャがどのように成長するかを決定します。
私たちの成長計画と予算に一致するものを選択することが重要であり、これはすべてに適用されます データサイエンス会社 、サイズに関係なく。
最後に、これらのテクノロジーはそれぞれ、データの集約方法が大きく異なります。
ギガバイトとテラバイトのデータを処理する場合、誤った集計戦略により、生成できるレポートの種類とパフォーマンスが制限される可能性があります。
データエンジニアとして、さまざまなデータストレージを評価する際には、3つの側面すべてを考慮する必要があります。
候補者
検索エンジン：Elasticsearch
Elasticsearchは、そのスケーラビリティと統合の容易さで、すぐに同業他社の間で人気を博しました。上に構築 Apache Lucene 、それは強力な、すぐに使えるテキスト検索と索引付け機能を提供します。従来の検索エンジンタスク、テキスト検索、正確な値のクエリに加えて、Elasticsearchは階層化された集計機能も提供します。
ドキュメントストア：MongoDB
この時点で、MongoDBは頼りになるNoSQLデータベースと見なすことができます。その使いやすさと柔軟性はすぐに人気を博しました。 MongoDBは、複雑なドキュメントを掘り下げるための豊富で適応性のあるクエリをサポートしています。頻繁にクエリされるフィールドはインデックス作成によって高速化でき、大量のデータを集約する場合、MongoDBはマルチステージパイプラインを提供します。
列指向ストア：Amazon Redshift
NoSQLの人気の高まりとともに、列指向データベースも、特にデータ分析のために注目を集めています。通常の行ではなく列にデータを格納することで、ディスクから直接集計操作を実行できるため、パフォーマンスが大幅に向上します。数年前、AmazonはRedshiftと呼ばれる列指向ストア向けにホスト型サービスを展開しました。
インデックス作成
Elasticsearchのインデックス機能
多くの点で、検索エンジンはテキストのインデックス作成に特化したデータストアです。
他のデータストアはフィールドの正確な値に基づいてインデックスを作成しますが、検索エンジンでは（通常はテキスト）フィールドのフラグメントのみで取得できます。
アカウント設計のベストプラクティスチャート
デフォルトでは、この取得はアナライザーを介してすべてのフィールドに対して自動的に実行されます。
アン アナライザ は、フィールド値を評価し、それらをより小さな値に分解することによって複数のインデックスキーを作成するモジュールです。
たとえば、基本的なアナライザーは、「速い茶色のキツネが怠惰な犬を飛び越えた」を「the」、「quick」、「brown」、「fox」などの単語に変換する場合があります。
この方法では、ユーザーは結果内のフラグメントを検索してデータを検索し、同じドキュメントデータに一致するフラグメントの数でランク付けすることができます。
より洗練されたアナライザーは 距離を編集する 、 nグラム 、およびでフィルタリング ストップワード 、包括的な検索インデックスを構築します。
MongoDBのインデックス作成機能
汎用データストアとして、MongoDBはデータのインデックス作成に多くの柔軟性を備えています。
Elasticsearchとは異なり、_idのみにインデックスを付けますデフォルトではフィールドであり、一般的にクエリされるフィールドのインデックスを手動で作成する必要があります。
Elasticsearchと比較すると、MongoDBのテキストアナライザーはそれほど強力ではありません。ただし、最適なクエリを実行するための複合および地理空間から、ストレージ削減のためのTTLおよびスパースまで、インデックス作成方法に多くの柔軟性を提供します。
Redshiftのインデックス作成機能
Elasticsearch、MongoDB、またはPostgreSQLを含む従来のデータベースとは異なり、AmazonRedshiftはインデックス作成方法をサポートしていません。
代わりに、ディスク上で一貫した並べ替えを維持することにより、クエリ時間を短縮します。
ユーザーとして、列値の順序付きセットをテーブルソートキーとして構成できます。データがディスク上でソートされているため、Redshiftは、値が照会された範囲外の場合、取得中にブロック全体をスキップできるため、パフォーマンスが大幅に向上します。
シャーディング
Elasticsearchのシャーディング機能
Elasticsearchは、Luceneの上に構築されており、水平方向に拡張して本番環境に対応できます。
スケーリングは、複数のLuceneインスタンス（シャード）を作成し、それらをクラスター内の複数のノード（サーバー）に分散することによって行われます。
デフォルトでは、各ドキュメントは_idを介してそれぞれのシャードにルーティングされます。フィールド。
取得中に、マスターノードは各シャードにクエリのコピーを送信してから、最終的にそれらを集約してランク付けして出力します。
MongoDBのシャーディング機能
MongoDBクラスター内には、ルーター、構成、シャードの3種類のサーバーがあります。
ルーターをスケーリングすることで、サーバーはより多くの要求を受け入れることができますが、シャードサーバーで大きな負担が発生します。
Elasticsearchと同様に、MongoDBドキュメントは（デフォルトで）_idを介してルーティングされますそれぞれの破片に。クエリ時に、構成サーバーはルーターに通知し、ルーターはクエリをシャーディングします。ルーターサーバーはクエリを配布し、結果を集約します。
Redshiftのシャーディング機能
Amazon Redshiftクラスターは、1つのリーダーノードと複数の計算ノードで構成されます。
リーダーノードは、クエリのコンパイルと配布、および中間結果の集約を処理します。
MongoDBのルーターサーバーとは異なり、リーダーノードは一貫性があり、水平方向に拡張することはできません。
これによりボトルネックが発生しますが、一般的なクエリのコンパイル済み実行プランを効率的にキャッシュすることもできます。
集約
Elasticsearchの集約機能
Elasticsearch内のドキュメントは、正確な値、範囲のある値、または時間的および地理的位置の値でバケット化できます。
これらのバケットは、ネストされた集約によってさらに細かくグループ化できます。
平均や標準偏差などの指標は、レイヤーごとに計算できます。これにより、単一のクエリ内で分析の階層を計算できます。
ドキュメントベースのストレージであるため、ドキュメント内のフィールド比較の制限があります。
たとえば、フィールドのフィルタリングは得意ですが フォロワー 10より大きい場合、確認できません フォロワー 他のフィールドよりも大きい 以下 。
別の方法として、カスタム述語としてスクリプトを挿入することもできます。この機能は1回限りの分析には最適ですが、本番環境ではパフォーマンスが低下します。
MongoDBの集約機能
ザ・ 集約パイプライン 強力で高速です。
その名前が示すように、それは段階的に返されたデータを操作します。
各ステップでは、ドキュメントのフィルタリング、集約、変換、新しいメトリックの導入、または以前に集約されたグループの巻き戻しを行うことができます。
これらの操作は段階的に行われるため、ドキュメントとフィールドをフィルタリングのみに削減することで、メモリコストを最小限に抑えることができます。 Elasticsearch、さらにはRedshiftと比較すると、AggregationPipelineはデータを表示するための非常に柔軟な方法です。
その適応性にもかかわらず、MongoDBはElasticsearchと同じようにドキュメント内フィールド比較が不足しています。
レバレッジドバイアウト（lbo）
さらに、$groupを含む一部の操作では、結果をマスターノードに渡す必要があります。
したがって、分散コンピューティングを活用していません。
段階的なパイプライン計算に慣れていない人は、特定のタスクが直感的でないことに気付くでしょう。たとえば、配列フィールドの要素数を合計するには、最初に$unwind、次に$groupの2つのステップが必要になります。操作。
Redshiftの集約機能
AmazonRedshiftのメリットを過小評価することはできません。
モバイルトラフィックの分析中にMongoDBでのイライラするほど遅い集計は、AmazonRedshiftによって迅速に解決されます。
SQLをサポートする従来のデータベースエンジニアは、クエリをRedshiftに簡単に移行できます。
オンボーディング時間は別として、SQLは実績のあるスケーラブルで強力なクエリ言語であり、ドキュメント内/行フィールドの比較を簡単にサポートします。 Amazon Redshiftは、コンピューティングノードで実行される一般的なクエリをコンパイルしてキャッシュすることでパフォーマンスをさらに向上させます。
リレーショナルデータベースであるAmazonRedshiftには、MongoDBやElasticsearchのようなスキーマの柔軟性がありません。読み取り操作用に最適化されているため、更新および削除中にパフォーマンスが低下します。
最適な読み取り時間を維持するには、行を並べ替えて、運用上の労力を追加する必要があります。
ペタバイトサイズの問題を抱えている人に合わせて調整されているため、他のデータベースでスケーリングの問題がない限り、安価ではなく、投資する価値がない可能性があります。
勝者を選ぶ
この記事では、データエンジニアリングのコンテキスト内で、Elasticsearch、MongoDB、AmazonRedshiftの3つの異なるテクノロジーについて検討しました。ただし、これらのテクノロジーはそれぞれ、ストレージタイプのカテゴリの最有力候補であるため、明確な勝者はありません。
データエンジニアリングの場合、ユースケースに応じて、一部のオプションが他のオプションよりも優れています。
- MongoDB 素晴らしいスターターデータベースです。これは、データスキーマがまだ決定されていないときに必要な柔軟性を提供します。とはいえ、MongoDBは、他のデータベースが専門とする特定のユースケースを上回っていません。
- 一方 Elasticsearch MongoDBと同様の流動的なスキーマを提供し、書き込みパフォーマンスとストレージサイズを犠牲にして、複数のインデックスとテキストクエリ用に最適化されています。したがって、MongoDBで多数のインデックスを維持していることに気付いた場合は、Elasticsearchへの移行を検討する必要があります。
- Redshift 事前定義されたデータスキーマが必要であり、MongoDBが提供する適応性に欠けています。その見返りとして、単一（または少数）の列のみを含むクエリでは、他のデータベースよりも優れています。予算が許せば、Amazon Redshiftは、他の人がデータ量を処理できない場合の優れた秘密兵器です。
