分析インフラストラクチャの進化

この記事では、分析全般のインフラストラクチャー、特にロシアのVerticaデータベースの特殊なものについての一連の資料を開きます。 記事は私のLifeStreet会社での一連のプロジェクトの経験を説明しており、完全であると主張していません。 ただし、可能な限り、一般的なレビューを行うようにします。 Vertica自体についての会話を始める前に、私たちがVerticaに到達した経緯について少しお話ししたいと思います。 当社の分析インフラストラクチャの開発の歴史から始めましょう。

パート1.少しの歴史、理論、実践

伝統的に、私たちはすべてを新しく開発する反復プロセスを実践しています。 つまり、特定の主題または技術分野を「感じる」ために、最初に簡単なプロトタイプが作成されます。 次に、プロトタイプから始めて、「必要に応じて」アーキテクチャと設計が開発され、学術的に正しいが、長く複雑なものよりもかなり良いソリューションを実装するのに十分な速度が優先されます。 次に、「方法」の概念が変更され、アーキテクチャが「あるべきように」変更されます。 などなど。 すべての変更は、作業中の動的に発展するビジネスで発生するため、慎重な進化的アプローチが必要です。 だから、分析プラットフォームでした。



「インフラストラクチャ」の最初のバージョンは、会社に4人の開発者がいて、ほぼ同数の人がいた2006年の2日間で「ひざまずき」に作られました。 nginxログを処理およびロードするのは、1つのテーブルと1つのJavaクラスを持つMySQLでした。 そのような最小限のセットでさえ、いくつかのマーケティング実験を開始してお金を稼ぐにはすでに十分でした。 その後、要件の設計と仕様の長い期間があり、その結果、データモデル、事実の構造、測定、メトリック、集計などが開発されました。 これらはすべて、同時に開発されているオンライン広告会社のオントロジーと一致していました。 数か月以内に、分析データウェアハウスの最初のバージョンは同じMySQL上に構築されました。これには、すべての主要コンポーネント（物理的および論理回路、ETL、一部ストアドプロシージャ、一部Java）が含まれます。 後に、クライアントの一部として、MicroStrategyの使用を開始しましたが、MicroStrategyは後で開発を放棄して放棄しました。 今後、このインフラストラクチャはわずかな変更で4年間機能し、その上で当社は急速に市場を征服し始めたことに注目します。



しかし、MySQLソリューションは一時的なものであると理解しました。これは、1日あたり最大10億の事実をサポートできるスケーラブルなインフラストラクチャがビジネスに必要だったためです。 楽観的な推定では、年間最大400テラバイトの未加工データが約束されていました。 その後、非常に合理的ではありますが、Oracleに行くという誤った決定を下しました。 1年間、マテリアライズドビューのような標準のOraklovプラクティスに従って、正しいハードウェアとソフトウェアでOrakleにデータウェアハウスを構築しました。 Oracle自体の速度に加えて、ETLを水平にスケーリングすることができました。 1つの「しかし」ではない場合。 社内で進行したプロセス内でOracleをサポートすることは絶対に不可能でした。 そして、プロセスは単純です-継続的なインクリメンタル開発、新しいフィールド、エンティティなどの追加 MVに間接的にさえ影響を与えた新しいフィールドは、システムを完全にブロックする再配置のカスケードを引き起こしました。 これを克服する試みは失敗しました。 最終的に、Oracleを放棄し、より良いオプションが見つかるまでMySQLでもう少し待つことにしました。 ちなみに、当時、 TokutekとそのTokuDB製品に出会いました。



ボストン近郊に位置するTokutekは、何か良いことをしている多くのMySQLベースの企業の1つです。 TokuDBはMySQLのストレージエンジンであり、分析アプリケーションに固有の非常に便利なプロパティがいくつかあります。 おそらく、この場所で少し離れて、分析アプリケーション用の回路の設計機能について話す必要があります。



分析用のデータベーススキーマを設計する従来のアプローチは、いわゆるスタースキーマまたはアスタリスクです。 ポイントは、大きな中央ファクトテーブルと、比較的小さなディメンションテーブルが多数あるということです。 ファクトテーブルには、メトリックと測定キーが含まれます。 エディターまたはボード上でテーブルとリンクを描画すると、測定テーブルの光線に、中央にファクトテーブルがあるアスタリスクまたは太陽が表示されます。 したがって、名前。 ディメンションテーブルでは、多くの場合、データは非正規化され、階層に編成されます。 教科書の例は、時間と地理の階層です。 たとえば、次のような表：



dim_geo

• geo_key
• 市
• 状態
• 国

データの正規化の観点から見ると、同じ州と国が何度も繰り返されるため、これは悪いことです。 しかし、分析モデルの観点からは、反対に、余分な結合を作成する必要がないため、便利で効率的です。



スタースキーマと階層は、典型的なクエリの種類を決定します。 たとえば、さまざまな国での広告のインプレッション数に関する統計情報を取得したいとします。

select date(event_date), sum(impressions) from fact_table join dim_geo using (geo_key) where country = 'RU' group by 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリクエストで重要なことは何ですか？ 実行計画の読み方を知っている人は、この場合、fact_tableにgeo_keyによるインデックスがある場合はロシアのgeo_keyによる大きなインデックス範囲スキャンがあり、そうでない場合にはフルスキャンがあるとすぐに推測します。 次に、日付（event_date）で並べ替えます。 テーブルに数億または数十億の行がある場合、そのようなクエリはMySQLでは高速になりそうにありません。



この単純な例からでも、まず、分析クエリはさまざまなインデックスを「愛する」と仮定できます。 次に、これらのインデックスは放電されます。つまり、単一の一意のインデックス値が多くのレコードに対応します。 3番目に、多数の行を集約およびソートすることは非常に一般的な操作です。 これについては後で説明しますが、今度は、TokuDBの機能に戻り、分析アプリケーションでどのように役立つかについて説明します。



最も重要なのは、バイナリインデックスではなくフラクタルツリーを使用する独自のインデックス技術です。 これはフラクタルとは関係ありません。単なる美しい言葉です。どのように機能するかについては詳しく説明しません-難しいです。 （興味があれば、別の記事を書いたり、学術資料へのリンクがあるmysqlperformanceblogの古い記事に送信したりできます）。 ユーザーの観点からのバイナリツリーとの主な違いは、大きなテーブルサイズでの挿入と削除のパフォーマンスです。 データベースに真剣に取り組んでいる人は、テーブルサイズが数億行以上の同じMySQLで、特にインデックスキャッシュに収まらないインデックスがテーブルに複数ある場合、新しいレコードの追加にかなりの時間がかかることを知っています。 これは、最初に、インデックスを「通過」するために、ディスク上のさまざまな場所から断片的に読み取る必要があるという事実によるものです。 次に、新しい「シート」を追加すると、インデックスの不均衡が発生（および発生）し、インデックスの重要な部分が移動または置換される可能性があります。 一般的に、深刻な問題。 これは、TokDBフラクタルインデックスで解決され、挿入および削除のパフォーマンスは、テーブルのサイズやインデックスの数によって実際には低下しません。 特に、これは、インデックスツリーを通るパス全体がディスクに「適合」し、ディスクを順次読み取ることができるという事実によって実現されます。 さらにトリッキーなキャッシュ。



TokuDBの2番目の主な利点は、インデックスのクラスタリングです。 一番下の行は、レコード全体がインデックスとともに保存されることです。 そうしないと、インデックスは最初にデータへのリンクを取得し、その後でデータ自体が読み取られるため、これはクエリの速度、特に疎インデックスのクエリの速度に大きく影響します。 MySQLでは、MyISAMの場合、インデックスとデータは常に別々に保存されますが、InnoDBの場合、データは主キーでソートされて保存され、残りのインデックスは別々に保存されます。 分析の問題では、通常、1つのインデックスでは十分ではありません。



これらの2つの競争上の優位性により、Oracleを廃止し、さらに3年間、TokuDBを使用してMySQLを使用しました。 彼らの製品は絶えず進化しており、無料のライセンスを使用しているにもかかわらず、すぐにサポートを提供してくれました。 すでにVerticaに切り替えようとしていたとき、TokuDBにはさらに2つの「甘い」機能が登場しました。「ホット」なインデックスの追加と「ホット」なテーブルの変更です。 標準のMySQLエンジンでは、これらの操作によりテーブルがブロックされます。 テーブルのサイズが数十ギガバイトの場合、長時間。



したがって、2009年末のインフラストラクチャは、MySQLとTokuDBであり、1日あたり約1億5千万から2億のファクトをロードします。 ファクトは長期間保存されませんが、異なる粒度の2つのダース単位にロードすると集計されます。 一部のユニットは「永久」であり、他のユニットは数日または数週間だけデータを保存します。 時間がかかる場合がありますが、TokuDBの無料ライセンスによって制限されているため、ユニットのサイズは50GBを超えません。 予備用または特定のタスク用に、ほぼ同一のシステムがいくつかあります。 主なクライアントインターフェイスはMicroStrategyですが、新しいScala言語で分析クエリを実行するためのユニバーサルサービスの最初のバージョンを開発することで、ソリューションへの移行プロセスを既に開始しています。 パフォーマンスとスケーラビリティの両方に問題がありますが、まだヒットしていませんが、すでに噛み付いています。 私たちは、MySQLを設定し、そのアプリケーションを「正しい」方法で設計することで、真のプロフェッショナルになりました。 しかし、それだけでは十分ではありません。

パート2.専門的な分析データベースの選択

TokuDBを使用することで、分析用に最適化された最高のデータベースを求めて、社内の競争をかなり冷静に開催できました。 このようなデータベースで何が特別なのかを理解するために、最初の部分からの国の統計を使用した例に戻りましょう。



fact_tableに100列あるとします。 これは非常に現実的な図であり、たとえば、現在さらに多くあります。 クエリは「event_date」、「impressions」、「geo_key」の3つの列のみを使用しますが、従来のデータベースでは、データは行ごとに保存されます。 クエリを完了するために必要な列の数に関係なく、すべてがディスクから読み取られます。これは、列が多いテーブルには非常に非効率的です。 この不快な効果はかなり前に気づかれ、列指向の内部ストレージ構造を使用した最初のデータベースは、90年代半ばに開発されたSybase SybaseIQの副産物でした。 私の知る限り、彼は正当な評価を受けていませんでした。 しかし、2000年代半ばに再び彼らはこの問題に戻り、悪名高いMichael StonebrakerはC-Store研究プロジェクトの先駆者となり、後にVertica商用プラットフォームの基礎となりました。 CITForumの翻訳記事から2008年半ばにC-Storeについて知りましたが、これはターニングポイントでした。



列指向ストレージの利点は、要求に必要な列のみをディスクから読み取るのに十分であるという事実に限定されません。 通常、列データは非常によく圧縮されています。 たとえば、列に値が2つしかない場合、複数の場合はビットでエンコードできます-辞書を使用します。 値が中心の周りでグループ化されている場合、デルタでエンコードできます。 など、多くのオプションがあります。 これにより、データを時々または数十回圧縮することができ、ディスク操作の量を大幅に削減できます。 もう1つの明らかな特性は、列を追加するのが非常に簡単で、実質的に無料であることです。 明らかではないものもあります。 ただし、これらすべてのプロパティには共通点が1つあります。これらは、分析タスクおよびクエリタイプに使用されるデータベースに非常に適しています。



2009年の終わりには、列指向のデータストレージを提供する商用データベースはわずかしかありませんでした。

• バーティカ
• みどり
• InfoBright
• パラクセル
• Infinidb
• Oracle（Exadata）

それらは準備とアクセシビリティの程度が異なりましたが、Oracle以外のすべてを試しました。 テストのために、25列と120億行のテーブルを用意しました。 8つのテストクエリがパフォーマンスのさまざまな側面を測定しました。 それらのすべてに、いくつかのグループ化とサブクエリの合計とフィルタリングがありました。 MySQL c TokuDBは参照システムとして機能しました。 データベースがクラスターにサーバーを追加することでスケーリングを許可する場合、パフォーマンスがどれだけ向上するかをテストしました。



各システムには調査、構成、およびデータのロードが必要だったため、プロジェクトは1人の努力で約2か月続きました。 すべての実験の結果は、共通の表にまとめられています。 その結果、Verticaは全員を追い抜いた。 単一サーバーシステムは、参照MySQLの20〜100倍、Greenplumの2〜4倍の速度で動作し、2位になりました。 2番目のサーバーを追加しても生産性が半分しか向上しなかったGreenPlumとは異なり、垂直方向は直線的に拡大しました。 さらに、後で気付いたように、これは制限ではなく、より最適な物理設計により、Vertikaはさらに高速になります。 したがって、選択は明白でした。収益性の高い契約に署名し、インフラストラクチャを新しいデータベースに移行し始めるだけでした。



これと、次の記事のVerticaの機能について。