非従来型のデータストレージに関するデータエンジニアガイド

データエンジニアリング

ビッグデータとデータサイエンスの台頭に伴い、多くのエンジニアリングの役割が挑戦され、拡大されています。 新時代の役割の1つは、データエンジニアリングです。

もともと、データエンジニアリングの目的は、外部データソースの読み込みとデータベースの設計（データを収集、操作、保存、分析するためのパイプラインの設計と開発）でした。

それ以来、ビッグデータの量と複雑さをサポートするように成長しました。 そのため、データエンジニアリングは、Webクロール、データクレンジング、分散コンピューティング、データの保存と取得など、幅広いスキルをカプセル化しています。

データエンジニアリングとデータエンジニアにとって、データの保存と取得は、データの使用方法と分析方法とともに、パイプラインの重要なコンポーネントです。

最近では、多くの新しい異なるデータストレージテクノロジーが登場しています。 しかし、データエンジニアリングに最適で、最も適切な機能を備えているのはどれですか？

ほとんどのエンジニアは、PostgreSQL、MSSQL、MySQLなどのSQLデータベースに精通しています。これらのデータベースは、行指向のストレージを備えたリレーショナルデータテーブルで構造化されています。

これらのデータベースがどれほど普及しているかを考えると、今日はそれらについて説明しません。 代わりに、人気が高まっており、データを処理するためのさまざまなアプローチを導入している3種類の代替データストレージについて説明します。

データエンジニアリングのコンテキスト内では、これらのテクノロジは検索エンジン、ドキュメントストア、および列指向ストアです。

• 検索エンジンはテキストクエリに優れています。 LIKEなどのSQLデータベースのテキスト一致と比較すると、検索エンジンは、すぐに使用できるより高いクエリ機能とより優れたパフォーマンスを提供します。
• ドキュメントストアは、従来のデータベースよりも優れたデータスキーマ適応性を提供します。 多くの場合JSONとして表される個々のドキュメントオブジェクトとしてデータを保存することにより、スキーマの事前定義は必要ありません。
• 列型ストアは、単一列のクエリと値の集計に特化しています。 SUMやAVGなどのSQL操作は、同じ列のデータがハードドライブ上でより近くに格納されるため、列型ストアではかなり高速です。

この記事では、検索エンジンとしてのElasticsearch、ドキュメントストアとしてのMongoDB、列指向ストアとしてのAmazonRedshiftの3つのテクノロジーすべてについて説明します。

代替データストレージを理解することで、それぞれの状況に最適なものを選択できます。

これらのテクノロジーを比較するために、データのインデックス作成、シャーディング、および集計の方法を調べます。

各データインデックス戦略は、特定のクエリを改善し、他のクエリを妨げます。

どのクエリが最も頻繁に使用されるかを知ることは、採用するデータストアに影響を与える可能性があります。

データベースがデータをチャンクに分割する方法論であるシャーディングは、より多くのデータが取り込まれるにつれてインフラストラクチャがどのように成長するかを決定します。

成長計画と予算に一致するものを選択することが重要です。これは、規模に関係なく、すべてのデータサイエンス企業に当てはまります。

最後に、これらのテクノロジーはそれぞれ、データを非常に異なる方法で集約します。

ギガバイトおよびテラバイトのデータを処理する場合、誤った集計戦略により、生成できるレポートのタイプとパフォーマンスが制限される可能性があります。

データエンジニアとして、さまざまなデータストレージを評価する際には、3つの側面すべてを考慮する必要があります。

候補者

検索エンジン：Elasticsearch

Elasticsearchは、そのスケーラビリティと統合の容易さで、すぐに同業他社の間で人気を博しました。 Apache Luceneの上に構築されており、すぐに使用できる強力なテキスト検索および索引付け機能を提供します。 従来の検索エンジンタスク、テキスト検索、正確な値のクエリに加えて、Elasticsearchは階層化された集計機能も提供します。

ドキュメントストア：MongoDB

この時点で、MongoDBは頼りになるNoSQLデータベースと見なすことができます。 その使いやすさと柔軟性はすぐに人気を博しました。 MongoDBは、複雑なドキュメントを掘り下げるための豊富で適応性のあるクエリをサポートしています。 頻繁にクエリされるフィールドはインデックス作成によって高速化でき、大量のデータを集約する場合、MongoDBは多段階のパイプラインを提供します。

列指向ストア：Amazon Redshift

NoSQLの人気の高まりとともに、特にデータ分析のために列型データベースも注目を集めています。 通常の行ではなく列にデータを格納することで、ディスクから直接集計操作を実行できるため、パフォーマンスが大幅に向上します。 数年前、AmazonはRedshiftと呼ばれる列指向ストア向けにホスト型サービスを展開しました。

インデックス作成

Elasticsearchのインデックス機能

多くの点で、検索エンジンはテキストのインデックス作成に特化したデータストアです。

他のデータストアはフィールドの正確な値に基づいてインデックスを作成しますが、検索エンジンでは（通常はテキストの）フィールドのフラグメントのみを使用して検索できます。

デフォルトでは、この取得はアナライザーを介してすべてのフィールドに対して自動的に実行されます。

アナライザーは、フィールド値を評価し、それらをより小さな値に分解することによって、複数のインデックスキーを作成するモジュールです。

たとえば、基本的なアナライザーは、「速い茶色のキツネが怠惰な犬を飛び越えた」を「the」、「quick」、「brown」、「fox」などの単語に調べます。

この方法では、ユーザーは、同じドキュメントデータに一致するフラグメントの数でランク付けされた、結果内のフラグメントを検索してデータを見つけることができます。

より洗練されたアナライザーは、編集距離、n-gram、およびストップワードによるフィルターを利用して、包括的な検索インデックスを構築できます。

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と同じようにドキュメント内フィールド比較が不足しています。

さらに、 $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は、他の人がデータ量を処理できない場合の優れた秘密兵器です。