高度な並行ストレージシステム


12

たとえば、それぞれ300億行(合計サイズ4TB)の3つの巨大なテーブル(構造化データ)があり、多数の同時ユーザー(リモートLANマシンの並列osスレッド)が一部を読み取る必要があることを想像してくださいSELELCT WHERE GROUPBYクエリと非常に同時、たとえば10,000同時読み取りによるデータと、ユーザーがこれらのテーブルにデータを挿入する必要があります(更新なし)2000同時書き込み(データセンターLANネットワーク全体) 。ユーザーは、このストレージから可能な限り高速で読み取りと挿入を行い、各読み取りと書き込みが行われる場所はms〜1秒の範囲です。

そのような要件を満たすために、どのテクノロジーをお勧めしますか?これを実行できるデータストレージまたはキーバリューストアはありますか?クラウドはオプションではありません。

いくつかの明確化:

ユーザーはデータをすぐに見る必要はなく、最終的な一貫性は許容されます。データはストレージが提供できるドライバーを介してアクセスされ、ユーザーは再びデータセンターのリモートマシンで実行される単なるスレッドになります。クエリは、主にSELECT WHERE GROUPBYに似ています。

データは表形式で、各行は約60バイトです。

DynamoDBまたは同様のソリューションを使用できないクラウドオプションはありません。データセンターで内部的にホストできる必要があります。

テーブルのすべてのデータを常に読み取ることができ、使用パターンは予測できません。結合または超長いクエリはありません。DRは必要ありませんが、合理的なHAは必要ですが、空想である必要はありません。すべての読者は、where句に基づいて行のバッチを取得しており、行は実際には関連していません。各行の長さを固定することもできますが、ストレージレイヤーが心配することを期待しています。

また、私の最大の懸念は、同時読み取りで発生するすべての同時書き込みです。

これに対するあなたの洞察は非常に高く評価されています。

さらに、これらのテーブルのうち3つにそれぞれ300億行の異なるオブジェクトタイプがあります


クラウドを定義するのは、一般の人々の99%やマーケティングの人々の100%がクラウドと呼ぶものは、他の誰かが維持している単なるクラスターだからです。

つまり、DynamoDBや、AmazonやAzureなどのパブリッククラウドでしか利用できないテクノロジーを使用することはできません。
iCode

回答:


6

最終的な一貫性が許容され、すべてのクエリが集計である場合、おそらく低レイテンシのOLAPシステムが機能する可能性があります。要件は、アルゴリズム取引プラットフォームに少し似ています。このタイプのアーキテクチャは、最新のデータに対して統計分析の集計計算を実行する必要があるトレーディングフロアシステムでよく使用されます。

日付でデータを分割でき、古い行が更新されない場合は、通常のRDBMSプラットフォームに支えられたMicrosoft Analysis Servicesなどの従来のOLAPサーバーを使用してハイブリッドOLAPシステムを構築できます。これを約4 TBのデータに対応させることが可能であり、SQL ServerとSSASの両方が共有ディスククラスターを実行します。同様のOLAPシステム(Oracle / Hyperion Essbaseなど)は、他のベンダーから入手できます。

OLAPサーバーは、集約と共にデータをネイティブストアに永続化することにより機能します。ほとんどがパーティションデータをサポートします。さらに、ほとんどは、基になるデータベースに対してクエリを発行するROLAPモードでも動作します。重要なことは、ストレージ戦略をパーティションごとに管理でき、パーティションをプログラムで切り替えることができることです。

このモデルでは、履歴データはMOLAPパーティションに保存され、データの集計も保持されます。集計からクエリが満たされる場合、サーバーはそれらを使用します。集計はクエリに合わせて調整でき、正しい集計はクエリの解決に必要な計算量を劇的に削減します。このタイプのシステムでは、非常に応答性の高い集計クエリが可能です。

リアルタイムデータは、必要に応じて、現在の月、日、さらには1時間の小さな先頭パーティションを維持することで実装できます。OLAPサーバーはデータベースに対してクエリを発行します。このパーティションが十分に小さい場合、DBMSは迅速に応答できます。通常のプロセスでは、新しい主要パーティションが作成され、閉じられた履歴期間がMOLAPに変換されます。古いパーティションをマージして、履歴データを必要な粒度で管理できます。

データベースに書き込むクライアントは、基になるRDBMSを直接書き出すだけです。履歴データが静的なままである場合、先頭のパーティションにのみ書き込まれます。4TBは、追加のDBMSパフォーマンスが必要な場合にSSDを使用する実用的なボリュームです。メインストリームベンダーでさえ、オプションとして高速SLCユニットを備えたSSDベースの製品を提供しています。


ご回答ありがとうございます。あなたは正しいです。私の問題はアルゴリズム取引プラットフォームに似ていますが、異なっています。RDBMSルートを試してみましたが、拡張できませんでした。データのサイズが拡大しつつあり、3つのテーブルでより多くのTBに達すると、RDBMSは多くのロックおよび同様の問題を作成するため、OLAPシステムの複雑さのない、拡張可能なストレージが必要です。nosqlオプションがこのような要件を満たすことができることを期待しています。それについて何か考えはありますか?
iCode

@MDotnet 12,000人の同時ユーザー、4TBサイズの問題に対する単純なソリューションに対する期待/要件は非現実的かもしれません。RDBMSのアプローチを見たが、スケールしなかったことに言及しています。1)この詳細をQに追加できますか?2)この回答は、純粋なリレーショナルデータベースではなく、ハイブリッドROLAP / MOLAPアプローチを提唱しています。
マークストーリースミス

私はDBAではないので、「賛成票によるドライブ」はほとんどの専門サイトにとって悪いと思いますが、気にしません。この答えはたった1つの賛成票にとっては良いことです。1
PSR
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.