1970年にE.F.によって提案されたリレーショナルデータモデル Coddomは長い間、データベース開発のトレンドを確立し、今日までビジネスの要件を完全に満たすことを許可していました。 1970年以来、リレーショナルデータベースは長い道のりを歩んできました。 絶えず増加するデータ量は、インデックス、ソートされた形式でのデータの保存など、必要なデータへの高速アクセスを提供できるメソッドの出現をもたらしました。 これらのメソッドは、タスクに非常にうまく対処しましたが、まだ関連性を失っていません。 ただし、ストレージメディアの容量の急激な増加とデータストレージのコストの削減により、数十テラバイトのデータベースサイズはもはや珍しいものではなく、一般的な現象として認識されるようになりました。 ビジネスでは、このデータを「無駄」にすることはできません。世界で激化する競争により、彼は活動の範囲をマスターするための新しいアプローチを模索することを余儀なくされています。 時間について話せば、法案は数日、あるいは数時間ではなく、数分ではなく、必要な情報を素早く入手できる人が勝ちます。
しかし、すべての最新のデータベースが新しいボリュームに対応できるわけではありません-古い方法はもはや効果的ではありません。 データベース全体を全体として「減速」させる主なコンポーネントは、情報ストレージデバイスです。 残念ながら、数十テラバイトの巨大なデータセットから有用な情報を取得する方法のさらなる開発に着手したのは、まさにハードドライブの機能です。 今日、分析する必要のあるデータ量の増加にテクノロジーが追いついていません。 フラッシュディスクは非常に高価であり、特にデータベースの企業データストレージデバイスとしての使用を妨げる記録リソースという重大な欠点があります。 この記事では、既存の技術の欠点を克服するために、現代の分析データベースで使用される方法を議論することを提案します。 また、既存のアプローチに混乱をもたらさないように、さまざまな種類の豊富なNoSQLデータベースファミリに関する議論を別の記事に残したいと思います。 それでも、NoSQLモデルを使用したデータベースは、従来の分析システムにとっては非常に珍しいものですが、個々のタスクである程度の人気を得ています。 主な関心は、ACID要件を満たし、ビッグデータ分析を目的とする従来のリレーショナルデータモデルを備えたデータベース、つまり現代の課題への対応方法に引き付けられています。
カオスと規則性を区別することは難しいため、分析データベースで使用されるデータは、適切に準備および順序付けする必要があることは完全に明らかです。 ただし、このルールには例外があり、これについては後で説明しますが、フレームワーク内には別の記事があります。 データが何らかのETLプロセスによって準備され、データウェアハウスにロードされると仮定します。 最新の分析データベースは、数テラバイトまたは数十テラバイトの読み取りに数日を費やすことのないデータへのアクセス速度をどのように提供できるか。
超並列処理
超並列アーキテクチャは、各ノードが独自のプロセッサ、メモリ、および他のノードと通信できるようにする通信ツールを備えた個別のノードから構築されます。 この場合の個別のノードは、他のすべてのノードと連携して機能する個別のデータベースです。 したがって、ノッチを下ると、データベースであるプロセスまたはプロセスのセットが表示され、独自の個別のタスクを実行して、共通の原因になります。 各ノードに独自のインフラストラクチャ（プロセッサとメモリ）があるという事実により、データベースの特性である従来の制限に反することはありません。 ここで、各ノードはデータの一部を保存し、それと連携して、最速のアクセスを提供します。 全データを全ノードに均等に分散する方法は、別の議論のトピックです。
理論的には、各ノードに独自のプロセッサとディスクメモリを提供できるため、最大データ読み取り速度は情報ストレージデバイスのすべての読み取り速度の合計に等しくなり、非常に大きなボリュームを分析する必要がある要求の応答時間に関して許容できる結果を達成できます情報。 実際には、使用率を高めるために、複数のノードが同じサーバー上に存在し、それらの間でリソースを共有しています。
明らかに、そのようなアーキテクチャ上に構築されたデータベースの場合、ノードの1つまたは各ノードは、ユーザーからの要求を受け入れ、残りのすべてのノードに配布し、それらからの応答を待機し、要求の実行結果としてこの応答をユーザーに渡すことができる必要があります。
そのようなアーキテクチャの利点は表面上にあります-それはほとんど線形のスケーラビリティです。 さらに、水平および垂直の両方の形式のスケーラビリティ。
欠点は、そのようなアーキテクチャのすべての利点を使用できるようにするソフトウェアを作成するために多大な努力をする必要があることです。これが、そのような製品の高コストを決定します。
MPPを使用した分析リレーショナルデータベース：
1. EMC Greenplum
あらゆるタスクに合わせて構成できる強力な機能セットを備えた最高のソリューションの1つ。
2. Teradata
市場で実績のある有名なソリューション。 競合他社に比べて高いコストであり、大きな利点はありません。
3. HP Vertica
ソリューションの利点は、同時に欠点でもあります。 大量の冗長（複製）データを保存する必要があり、狭い範囲のタスクに焦点を合わせ、いくつかの重要な機能が不足しています。
4. IBM Netezza
興味深い、かなり迅速なソリューション。 欠点は、これが完全にハードウェアソリューションであり、独自のプラットフォーム上に構築されており、部分的に古いことです。 スケーラビリティに関する質問があります。
読者が将来に興味を持つようになった場合、決定ごとに個別のレビューを行うことができます。 それはともかく、これらの4つの製品が、何も共有しないアーキテクチャを備えたMPPセクターのトレンドを設定しています。 それらの例を使用して、超大容量データの処理を目的としたさらなる技術の開発のベクトルを観察できます。 数十テラバイトを処理するために特別に設計された、まったく新しいクラスのデータベースが登場しました。
ただし、ハードドライブの機能に関連する制限を回避できるようにする2番目の方向が登場しました。
IMDB
インメモリデータベースは、完全にRAMにあるデータを処理するデータベースです。 ご存知のように、RAMの速度は従来のハードドライブに比べて桁違いに優れており、これにより、膨大な読み取りおよび書き込み速度の高性能データストレージデバイスが提供されます。 それにもかかわらず、データを完全にRAMに保存したい人はまだほとんどいません。 これは主に、そのようなメモリのコストがハードドライブのコストよりもはるかに高いという事実によるものです。 重要な要因は、電源を切るとすぐにすべてのデータが消えることです。 長い間、メインメモリ内のデータを処理するデータベースは補助的なものであり、運用処理にのみ必要な短期データを保存するバッファとして機能していました。 ただし、このタイプのメモリのコストの低下により、この種のデータベースへの関心が高まっています。 ビッグデータ領域への入場はテラバイトから始まると考えられています。 最近まで、このタイプのデータベースには、十分に大きなボリュームで機能するソリューションはありませんでした。 ただし、2011年、SAPは最大8テラバイトの非圧縮データをサポートするHANAデータベースを導入しました。 理論的には、圧縮を使用すると、使用されるデータの量を40テラバイトに増やすことができます。 IMDBテクノロジーのもう1つの代表は、OracleのTimesTenです。 どちらのソリューションも優れた機能を備えており、インメモリRDBMSの分野で最も開発された製品です。
したがって、企業はビッグデータの課題を受け入れる用意ができています。 ソリューションはすでに発明され、テストされており、数十年にわたって蓄積された情報を使用して、アナリスト、マーケティング担当者、およびデータベース管理者によって提起された質問に対する回答を得るための許容時間を考慮しています。 超大量のデータを処理するための新しいデータベースクラスが作成されています。 データアクセスの速度を上げるための新しい方法が開発されています。
同時に、現代の現実は、リレーショナルデータベースがオールインワンソリューションになれないことを示しています。 そのため、大量の情報を保存および処理する機能を実行するデータウェアハウスに加えて、会社は会社の業務を遂行するために設計されたOLTPデータベースも必要です。