MySQLを使用したスキーマレスUberエンジニアリングデータウェアハウスの設計

MySQLを使用したスキーマレス、Uber Engineeringのスケーラブルなデータストアの設計

ヤコブ・ホールドガード・トムセン

2016年1月12日



https://eng.uber.com/schemaless-part-one/







MySQLを使用したスキーマレスUber Engineeringデータウェアハウスの設計。 これは、スキーマレスデータウェアハウスに関する3部構成の記事の第1部です。



Project Mezzanineでは、1つのPostgresインスタンスからUberトリップデータを高性能で信頼性の高いデータウェアハウスであるSchemalessに移行する方法を説明しました 。 この記事では、そのアーキテクチャ、Uberインフラストラクチャにおける役割、および設計履歴について説明します。

新しいデータベースのための戦い

2014年の初めに、トリップ数の増加によりデータベースリソースが使い果たされました。 新しい都市、新しい旅行のたびに私たちは深aに導かれましたが、ある日、Uberインフラストラクチャが年末までに機能しなくなることに気付きました。 私たちの仕事は、Uberのデータベーステクノロジーを変更することでした。これは、何ヶ月もかかった仕事であり、その解決策として、世界中のオフィスから多数のエンジニアを引き付けました。



しかし、多くの商用およびオープンソースソリューションがあるのに、なぜスケーラブルなデータウェアハウスを構築するのでしょうか？ 新しいデータウェアハウスには5つの重要な要件がありました。



データウェアハウスは 、Postgresのインストールにはなかった新しいサーバーを追加することで、容量を直線的に増加させることができたはずです。 新しいサーバーを追加すると、使用可能なディスク領域が増加し、システムの応答時間が短縮されます。



記録時には、データストレージの高可用性が必要です。 以前は、Redisを使用して単純なバッファメカニズムを実装していたため、Postgresの書き込みが失敗した場合、旅行はRedisに保存されているため、後で再試行できます。 レコードがRedisに保存され、Postgresにはまだ保存されていなかった時点で、請求などの機能を失いました。 迷惑ですが、少なくとも私たちは旅を失いませんでした！ Uberは時間とともに成長し、Redisベースのソリューションはスケーラブルではありません。 スキーマレスデータストアは、Redisを使用したソリューションと同様のメカニズムをサポートするはずでしたが、読み取りと書き込みの一貫性を提供します。



依存するコンポーネントとメッセージングする方法が必要です 。 その時点で動作していたシステムでは、同じプロセス内で依存コンポーネントを順番に処理しました（たとえば、課金、分析など）。 エラーが発生しやすいプロセスでした。プロセスのいずれかのステップが失敗した場合、プロセスの一部のステップが成功したとしても、最初からやり直す必要がありました。 スケーリングしなかったため、プロセスをデータの変更に応じて開始される独立した下位プロセスに分割したいと考えました。 Kafka 0.7に基づく非同期メッセージングシステムが既にありました。 しかし、データを失うことなく起動することはできなかったので、同様の機能を備えた新しいシステムを歓迎しますが、データを失うことなく機能します。



セカンダリインデックスが必要です。 Postgresから離れていきましたが、新しいデータウェアハウスはPostgresレベルでインデックスをサポートすることになっていたため、同様に効率的にセカンダリインデックスを検索できました。



ミッションクリティカルなデータが含まれているため、絶対に信頼できるシステムが必要です。 午前3時に、データウェアハウスが応答せず、ビジネスが破壊されたと言われた場合、すぐに復元するための運用情報がありますか？



前述の観点から、Cassandra、Riak、MongoDBなど、広く使用されている代替システムの利点と潜在的な制限を分析しました。製品）：

	線形の拡張性	書き込みアクセシビリティ	メッセージング	二次インデックス	信頼性
製品1	✓	✓	✗	（✓）	✗
製品2	✓	✓	✗	（✓）	（✓）
製品3	✓	✗	✗	（✓）	✗

3つのシステムはすべて、新しいサーバーを追加することで直線的に拡張できますが、書き込みアクセス性の高いシステムは2つだけです。 どのソリューションもすぐに使えるメッセージングを実装していないため、アプリケーションレベルで実装する必要があります。 それらはすべてインデックスを持っていますが、多くの異なる値にインデックスを付ける場合、スキャッターギャザーコマンドを使用してすべてのノード（シャード）をポーリングするため、クエリが遅くなります。



最後に、ビジネスにとって重要な旅行データを保存する必要があるため、決定は最終的に信頼性によって決定されました。 一部の既存のソリューションは、理論的には確実に機能します。 しかし、その潜在能力を最大限に発揮するための運用知識はありますか？ 実際、私たちが使用している技術だけでなく、私たちのチームにいた人々にも大きく依存しています。



2年以上前にこれらのオプションを検討し、旅行のデータウェアハウスを使用する場合には適用できないことがわかったため、CassandraとRiakの両方をインフラストラクチャの他の領域に正常に適用し、数百万人のユーザーにサービスを提供するために本番環境で使用しています。

Schemalessでは、信頼性があります。

上記のオプションはいずれも、時間枠に応じた要件に対応していなかったため、他の人からのスケーリングレッスンを使用して、できるだけ作業が簡単な独自のシステムを作成することにしました。 設計はFriendfeedに触発され、ピンターズに触発された運用面に焦点が当てられました。



キーと値のストレージを設計する必要があるという結論に達しました。これにより、厳密なスキーマ検証なしでJSONデータを保存できるようになります（そのため、スキーマレスという名前になります）。 シャードに分散されたMySQLサーバーに実装され、フォールトトレランスのための書き込みバッファリングと、トリガー呼び出しに基づくデータ変更に関するパブリッシュ/サブスクライブメッセージングを備えています。 最後に、スキーマレスデータストアはグローバルインデックスをサポートします。

スキーマレスデータモデル

Schemalessは、GoogleのBigtableに似た、追加のみのスパースな3次元ハッシュマップです。 Schemalessの最小のデータオブジェクトはセルと呼ばれ、不変です。 記録後は、変更または削除できません。 セルはJSON（BLOB）オブジェクトであり、行キー、列名、およびrefキーと呼ばれる参照キーを使用してアクセスできます。 行キーはUUID、列名は行、参照キーは整数です。



行キーをリレーショナルデータベースの主キーとして、列名をリレーショナルデータベースの列として表すことができます。 ただし、Schemalessには事前定義または強制されたスキーマがなく、列名は行に対して事前定義されていません。 実際、列の名前はアプリケーションによって完全に決定されます。 参照キーは、セルのバージョン管理に使用されます。 したがって、セルを更新する必要がある場合は、より高い参照キーを使用して新しいセルを作成する必要があります（最後のセルが最も高い参照キーを持ちます）。 refキーは配列のインデックスとしても使用できますが、通常はバージョン管理に使用されます。 refキーの使用方法は、アプリケーションによって決定されます。



通常、アプリケーションは関連データを1つの同じ列にグループ化し、各列のすべてのセルはアプリケーション側でほぼ同じスキーマを持ちます。 このグループ化は、変化するデータを結合する優れた方法であり、アプリケーションがデータベース側でダウンタイムを発生させることなくスキーマを迅速に変更できるようにします。 以下に例を示します。

例：スキーマレス旅行データの保存

Schemalessへの旅行をシミュレートする方法に飛び込む前に、Uberへの旅行の解剖学を見てみましょう。 旅行データはさまざまな時点で生成されます。たとえば、旅行の終わり、旅行の支払い、これらのさまざまな情報は非同期に到着します。 以下の図は、ユーバー旅行のさまざまな部分が発生した場合の簡略化されたフローです。







この図は、イベントフローの簡略版を示しています。 *はオプションであり、複数回存在する可能性のある部品を示します。



旅行は、顧客の注文を履行し、開始と終了のタイムスタンプを持つ運転手によって連絡されます。 この情報は基本的な（推定）旅行であり、これから旅行の料金（料金）を計算します。これはクライアントの料金です。 旅行後、運賃の調整が必要になる場合があります。 クライアントまたはドライバー（上記の図にアスタリスクでマーク）からのレビューを考慮して、旅行にメモを追加できます。 または、カードの1つがブロックされている場合、クライアントは旅行の代金を支払いカードで何度か支払う必要があります。 Uberでのイベントのフローは、データ駆動型のプロセスです。 旅行中にデータが利用可能または追加されると、特定の一連のプロセスが実行されます。 サービスの質の評価などの一部の情報（上の図のメモの一部と考えられる）は、旅行の数日後に発生する場合があります。



では、上記の旅行モデルとSchemalessをどのように比較しますか？

旅行データモデル

イタリック体を使用してUUIDを示し、大文字を使用して列名を示します。以下の表は、旅行リポジトリの簡易バージョンのデータモデルを示しています。 2つの旅行（UUID trip_uuid1とtrip_uuid2）と4つの列（BASE、STATUS、NOTES、FARE ADJUSTMENT）があります。 各セルは、番号とJSONオブジェクト（略称{...}）を持つブロックで表されます。 バージョン管理を表すためにブロックが重ねて表示されます。







trip_uuid1には3つのセルがあります。1つはBASE列に、2つはSTATUS列に、FARE ADJUSTMENTs列にはありません。 trip_uuid2のBASE列には2つのセルがあり、1つはNOTES列にあり、FARE ADJUSTMENTS列にもあります。 スキーマレスの場合、列に違いはありません。 したがって、列のセマンティクスはアプリケーション（この場合はメザニンサービス）によって決定されます。



メザニンでは、BASEの基本セルに、ドライバーのUUIDや乗車時間などの基本的な乗車情報が含まれています。 STATUS列には、現在の旅費支払いステータスが含まれており、請求の試行ごとに新しいセルが挿入されます。 （クレジットカードに十分な資金がない場合、またはカードがブロックされている場合、試行は失敗しました）。 ドライバまたはディスパッチャによってメモが残っている場合、NOTES列にはセルが含まれます。 最後に、運賃が調整されている場合、FARE ADJUSTMENTs列にはセルが含まれています。



この列構造を使用して、競合状態を回避し、更新中に記録する必要があるデータの量を最小限に抑えます。 BASE列は、旅行の完了時に記録され、通常は1回だけ記録されます。 STATUS列は、BASE列にデータを書き込んだ後に発生した旅行の代金を支払うときに記録され、請求書の支払いに失敗した場合に数回発生する可能性があります。 NOTES列は、BASEレコードの後のある時点で複数回書き込むこともできますが、STATUS列レコードとは完全に分離されています。 同様に、FARE ADJUSTMENTS列は、たとえば非効率的なルートのために運賃が変更された場合にのみ記録されます。



エンドツーエンドのトリガー



Schemalessの主要な機能は、Schemalessのインスタンスへの変更を通知できるトリガーです。 セルは不変であり、新しいバージョンが追加されるため、各セルは変更またはバージョンも表し、インスタンスの値を変更ログとして扱うことができます。 この場合、これらの変更をリッスンして、Kafkaなどのメッセージバスに非常に類似した機能を実行できます。



スキーマレストリガーは、データへの直接アクセスに加えて、メッセージシステムがトリガー機能を使用してアプリケーションコード（同様のシステムがLinkedBのDataBus）を監視および実行し、データの作成と処理を分離できるため、スキーマレスをデータの信頼できるソースにします。



他の用途の中でも、UberはBASE列がメザニンのインスタンスに書き込まれたときに、スキーマレストリガーを使用して請求します。 上記の例では、trip_uuid1にBASE列が書き込まれると、BASE列で実行される課金サービスがこのセルを選択し、支払いカードを介して旅行の支払いを試みます。 成功か失敗かに関係なく、支払いカードを介した支払いの結果は、ステータス列のメザニンに記録されます。 したがって、請求サービスは旅行の作成とは別に、Schemalessは非同期メッセージバスとして機能します。

イージーアクセスインデックス

最後に、SchemalessはJSONオブジェクトのフィールドで定義されたインデックスをサポートします。 これらの定義済みフィールドを介してインデックスにクエリを実行し、クエリパラメータに一致するセルを見つけます。 インデックスのクエリは、返されるセルのセットを見つけるためにアクセスするシャードを1つだけ必要とするため、これらのインデックスのクエリは効果的です。 実際、Schemalessではインデックスに直接書き込むことでセルデータを非正規化できるため、クエリをさらに最適化できます。 インデックスに非正規化データがあるということは、インデックスをクエリして情報を取得するためにインデックスをクエリするのに必要なシャードは1つだけであることを意味します。 実際、通常、スキーマレスユーザーは、行キーを介してセルを直接取得することに加えて、頻繁に要求されるデータをインデックスに非正規化することをお勧めします。



例として、メザニンの場合、特定のドライバーの旅行を検索できるインデックスがあります。 また、旅行の作成時間と旅行が行われた都市を非正規化しました。 これにより、一定期間、市内のドライバーのすべての旅行を検索できます。 以下に、旅行データストレージの一部であり、BASE列の上に定義されているYAML形式のdriver_partner_indexインデックスの定義を示します（例には標準＃を使用してコメントが付けられています）。

table: driver_partner_index # Name of the index. datastore: trips # Name of the associated datastore column_defs: – column_key: BASE # From which column to fetch from. fields: # The fields in the cell to denormalize – { field: driver_partner_uuid, type: UUID} – { field: city_uuid, type: UUID} – { field: trip_created_at, type: datetime}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このインデックスを使用して、city_uuidおよび/またはtrip_created_atでフィルタリングされた、指定されたdriver_partner_uuidの旅行を検索できます。 この例では、BASE列のフィールドのみを使用しますが、Schemalessは複数の列のデータの非正規化をサポートします。これには、上記のcolumn_defリストに複数のエントリが含まれます。



前述のように、Schemalessには、影付きフィールドに基づいてインデックスをシャーディングすることにより実装される効率的なインデックスがあります。 したがって、シェーディングインデックスの唯一の要件は、インデックス内のフィールドの1つがシェーディングフィールドとして指定されていることです（上記の例では、最初に指定されているため、driver_partner_uuidになります）。 シャードフィールドは、インデックスを書き込みまたは読み取るシャードを決定します。 これを行うには、インデックスのクエリ時にシャードフィールドを決定する必要があります。 これは、クエリの時点で、インデックスエントリを取得するシャードを1つだけ要求する必要があることを意味します。 シャードフィールドの重要な要件は、シャード間でデータを適切に分散する必要があることです。 UUIDが最適であり、都市の識別子は優先度が低く、ステータス（列挙）フィールドは害よりも害が大きくなります。



シャードフィールドを除き、Schemalessは、等値、不等、およびフィルタリングのクエリをサポートし、インデックス内のフィールドのサブセットのみを選択し、インデックスレコードが指す行キーの特定またはすべての列を取得することもサポートします。 現在、シャードフィールドは不変である必要があります。これにより、Schemalessはデータが存在するシャードを単独で決定できます。 しかし、パフォーマンスのオーバーヘッドなしでそれを可変にする方法を学んでいます。



インデックスは最終的に一貫しています。 セルにデータを書き込むたびに、インデックスエントリも更新しますが、これは単一のトランザクションでは発生しません。 通常、セルとインデックスエントリは同じシャードに属しません。 したがって、一貫性のあるインデックスを実装する場合、書き込み時に2フェーズコミットを導入する必要があり、これには大きなオーバーヘッドが伴います。 その結果、最終的に一貫したインデックスを使用してオーバーヘッドを回避しますが、スキーマレスユーザーはインデックス内の古いデータを見ることができます。 ほとんどの場合、ラグはセルの変更と対応するインデックスの変更の間で20ミリ秒よりも大幅に短くなっています。

まとめ

データモデル、トリガー、およびインデックスの概要を提供しました。これらは、旅行データストレージエンジンのコアコンポーネントであるSchemalessを定義する重要な機能です。 今後の投稿では、彼がUberインフラストラクチャの優れたアシスタントになった方法を示すために、さらにいくつかのSchemaless関数を見ていきます。アーキテクチャの詳細、MySQLをシャードとして使用する方法、モバイルアプリケーションの信頼性を確保するためのエラー処理方法です。



パート2：スキーマアーキテクチャ



パート3：スキーマレスでトリガーを使用する



Jakob Thomsenは、Schemalessプロジェクトのソフトウェアエンジニアおよび技術リーダーであり、デンマークのオーフスにあるUber Engineeringオフィスで働いています。 Schemalessの詳細については、2015年9月に開催されるFacebookの2回目の@Scaleカンファレンスでの講演をご覧ください。



ヘッダーの写真クレジット：CC-BY 2.0でライセンスされているNOAA Photo Libraryの「anim1069」。 ヘッダーのサイズと色が修正された画像をトリミングしました。



ヘッダーの説明：SchemalessはMySQLを使用して構築されているため、似たようなポーズをとるがMySQLのロゴとは逆の向きのイルカを使用したシリーズを紹介します。