Yandex.Mailのストレージシステム運用グループのシステム管理者であるVladimir Borodin （Habrのdev1antで ）は、Oracle DatabaseからPostgreSQLに大規模なプロジェクトを移行することの難しさを紹介します。 これは、 HighLoad ++ 2016カンファレンスのレポートの転写です。



みなさんこんにちは！ 私の名前はVovaです。今日はYandex.Mailデータベースについてお話します。



まず、将来重要になるいくつかの事実。 Yandex.Mail-このサービスは非常に古く、2000年に開始されたため、多くの遺産が蓄積されています。 私たちの場所では、言うまでもなく慣習的でファッショナブルであるため、非常に高負荷のサービスがあり、1日あたり1,000万人以上のユーザー、合計で数億人のユーザーがいます。 バックエンドでは、ピーク時に毎秒20万件を超えるリクエストが到着します。 スパムおよびウイルスチェックに合格した1日あたり1億5,000万件以上のメールを追加しています。 16年間すべての手紙の総量は20ペタバイト以上です。



それはどうなるのでしょうか？ OracleからPostgreSQLにメタデータを転送した方法について。 メタデータはペタバイトではなく、300テラバイトを少し超えています。 1秒あたり25万件を超えるリクエストがデータベースに送られます。 これらは小さなOLTP要求であり、ほとんどが読み取り（80％）であることに注意してください。



これは、Oracleを削除する最初の試みではありません。 2000年代の初めに、MySQLに移行する試みがありましたが、失敗しました。 2007年または2008年に、独自の何かを書く試みがありましたが、それも失敗しました。 どちらの場合も、技術的な理由ではなく、組織的な理由で失敗がありました。



メタデータとは何ですか？ ここでは、矢印で強調表示されています。 これらはフォルダーであり、カウンター、ラベル（実際にはカウンターのあるリスト）、コレクター、スレッド、そしてもちろん文字を含む何らかの階層です。







レター自体をメタベースに保存するのではなく、レターの本文は別のリポジトリにあります。 メタベースには、エンベロープが格納されます。 エンベロープは、メールヘッダーの一部です。誰から、誰へ、手紙の件名、日付、および同様のもの。 添付ファイルと会話に関する情報を保存します。

2012年に戻る

これらはすべてOracleにあります。 最も保存されたデータベースには多くのロジックがありました。 Oracleデータベースは最も効率的なリカバリハードウェアでした。10テラバイトを超える大量のデータをシャードに追加しました。 比較的言えば、30コアでは、通常の平均作業負荷は100でした。これは、すべてが悪い場合ではなく、通常の操作中です。



拠点はほとんどなかったので、多くの作業は自動化せずに手作業で行われました。 多くの手動操作がありました。 お金を節約するために、ベースを「ウォーム」（75％）と「コールド」（25％）に分けました。 「ウォーム」はアクティブユーザー向けで、SSDを使用しています。 「コールド」-非アクティブなユーザー向け、SATA。



シャーディングとフォールトトレランスは、Yandexの重要なトピックです。 シャーディング-すべてを1つのシャードにプッシュするわけではないため、およびフォールトトレランス-データセンターの1つを定期的に取り外して切断し、すべてが機能することを確認するため。



これはどのように実装されましたか？ 内部BlackBoxサービス（ブラックボックス）があります。 1つのリクエストがバックエンドの1つに到着すると、バックエンドは認証データ（ログイン、パスワード、Cookie、トークンなど）を交換します。 彼はこれをBlackBoxに送ります。BlackBoxは、成功するとユーザーIDとシャードの名前を返します。







次に、バックエンドがこのシャード名をOCCI Oracleドライバーに渡し、すべてのフォールトトレランスロジックがこのドライバー内に実装されました。 つまり、大まかに言って、特別なファイル/etc/tnsnames.oraにshardnameが書き込まれ、このシャードに入るホストのリストがサービスを提供します。 Oracle自体が、マスター、レプリカ、生存者、死亡者などを決定しました。合計すると、シャーディングは外部サービスを使用して実装され、フォールトトレランスはOracleドライバを使用して実装されました。



ほとんどのバックエンドはC ++で書かれています。 「自転車」を製造しないために、長い間、macsメタアクセスの一般的な抽象化が行われていました。 これは、ベースに移動するための単なる抽象化です。 ほとんど常に、彼女はmacs_oraの1つの実装を使用してOracleに直接アクセスしました。 もちろん、一番下にあるのはOCCIです。 接続プールを実装する小さなdbpoolレイヤーもありました。







これは、長い間考えられ、設計され、実装されていた方法です。 抽象化が終わると、バックエンドはmacs_ora実装のメソッドを使用し始めました。dbpoolの場合はさらに悪いことです。 このライブラリを使用できないJavaおよびその他のあらゆる種類のバックエンドが登場しました。 それから、このすべての麺は痛々しいほどかき集められなければなりませんでした。



Oracleは優れたデータベースですが、問題がありました。 たとえば、ライブラリキャッシュがあるため、PL / SQLコードのレイアウトは苦痛です。 データベースに負荷がかかっている場合、一部のセッションで使用されている機能コードを取得して更新することはできません。



残りの問題は、使用したアプローチほどOracleには関係していません。 繰り返しますが、多くの手動操作。 ウィザードの切り替え、新しいデータベースのロード、ユーザー転送の開始-拠点がほとんどないため、すべて手作業で行われました。



開発の観点から見ると、プラス[C ++] Oracleドライバーには同期インターフェースしかないという欠点があります。 つまり、通常の非同期バックエンドを先頭に書き込むことはできません。 これにより、開発に多少の痛みが生じました。 開発の2番目の痛みは、テストベースを上げることが問題であるということでした。 第一に、手で、第二に、それはお金だからです。



それを言う人は誰でも、オラクルはサポートしています。 多くの場合、企業のサポートは理想からかけ離れています。 しかし、移行の主な理由はお金です。 Oracleは高価です。

タイムライン

4年以上前の2012年10月に、Oracleを廃止することが決定されました。 PostgreSQLの言葉も技術的な詳細も聞かれませんでした-それは純粋に政治的な決定でした。3年間、取り除くことです。



6か月後、最初の実験を開始しました。 これらの6か月が費やされたものは、少し後でわかります。 これらの6ヶ月は重要でした。



2013年4月に、PostgreSQLを実験しました。 その後、あらゆる種類のNoSQLソリューションに非常にファッショナブルなトレンドがあり、さまざまなことを試しました。 すべてのメタデータは既にメール検索バックエンドに保存されており、使用できる可能性があることを思い出しました。 このソリューションも試しました。



最初の成功した実験はコレクターでした。 2014年のYandexでの会議でそれについて話しました 。



かなりロードされた（1秒あたり4万件のクエリ）メールメタデータの小さな断片（2テラバイト）を取得し、OracleからPostgreSQLに移行しました。 基本的なメタデータとあまり関係のない部分。 私たちはそれをやった、そしてそれが好きだった。 PostgreSQLを選択することにしました。



次に、PostgreSQL向けのメールスキームのプロトタイプを洗い流し、それに手紙の流れ全体を追加し始めました。 これを非同期で行いました。1日に1億5000万通すべての文字をPostgreSQLにスタックしました。 パッチが失敗する場合、気にしません。 それは純粋な実験であり、彼は生産を傷つけませんでした。



これにより、回路を使用して初期仮説をテストできました。 捨てるのが残念なデータがない場合-それは非常に便利です。 ある種のスキームを作成し、それに文字を詰めて、それが機能していないことを知り、すべてを落とし、再び始めました。 あなたがドロップできる素晴らしいデータ、それが大好きです。



また、これのおかげで、独立したスタンドではなく、ある種の合成物質ではなく、ライブ負荷で直接負荷テストを実行することがある程度判明しました。 PostgreSQLに必要な初期の鉄の推定値をたまたま作成しました。 そしてもちろん、経験。 前の実験とプロトタイプの主な目標は経験です。



その後、主な作業が始まりました。 開発には約1年かかりました。 終了するずっと前に、メールボックスをOracleからPostgreSQLに移動しました。 私たちは常に、ある夜「ごめん、技術的な仕事」を見せ、300テラバイトを転送し、PostgreSQLで作業を開始するようなことは決してないことを理解していました。 これは起こりません。 私たちは間違いなく故障し、ロールバックし、すべてが悪いでしょう。 一部のメールボックスがOracleに存在し、一部のメールボックスがPostgreSQLに存在する場合、移行に時間がかかるかなり長い期間があることを理解しました。



2015年の夏に、ボックスを移動しました。 書き込み、テスト、管理などを行うメールチームは、メールボックスを移動しました。 これにより、開発が大幅に加速しました。 抽象Vasyaが苦しむか、あなたが苦しむが、あなたはそれを修正することができます-これらは2つの異なるものです。



すべての機能を追加して実装する前でも、非アクティブなユーザーの移動を開始しました。 メールが届くユーザーを非アクティブと呼び、手紙を追加しますが、彼はそれらを読みません。ウェブ、モバイル、IMAPのいずれでもありません。 残念ながら、そのようなユーザーがいます。 たとえば、IMAPがまだ完全に実装されていないか、モバイルアプリケーションのペンの半分が機能していなかったときに、このような非アクティブなユーザーを携帯し始めました。



しかし、これは私たちが非常に勇敢ですべての箱を壊すことにしたからではなく、逆転送の形で計画Bがあり、それが私たちを大いに助けたからです。 自動化さえありました。 ユーザーを転送し、たとえば、Webインターフェースへのアクセスを突然試みた-起きてアクティブになった-私たちは彼の機能を壊さないようにOracleに戻しました。 これにより、転送コードの多数のバグを修正できました。



その後、移行が続きました。 ここにいくつかの興味深い事実があります。 私たちはすべての麺を書き換えるために10人年を費やしました。



移行自体は非常に高速でした。 これは4か月のスケジュールです。 各行は、サービスがPostgreSQLから提供する負荷の割合です。 サービスに分割：IMAP、Web、POP3、タブ、モバイルなど。







残念ながら、深byは95％を超えることはできません。 登録はOracleに残っているため、全員を4月に移すことはできませんでした。これはかなり複雑なメカニズムです。 そのため、新しいユーザーをOracleに登録し、すぐに夜にPostgreSQLに転送しました。 5月に登録を撮影し、7月にすでにすべてのOracleデータベースを完済しました。

大きな変更

macs_pgの別の抽象化が抽象化に現れ、すべての麺を解きました。 行われたすべての抽象化は、慎重に書き直さなければなりませんでした。 一番下にはlibpqがあり、接続プール、タイムアウト、エラー処理、およびこれらすべてが非同期であるapqの別の小さなレイヤーを作成しました。







シャーディングとフォールトトレランスはすべて同じです。 バックエンドはユーザーから認証データを受け取り、BlackBoxでユーザーIDとシャードの名前と交換します。 シャードの名前にpgという文字が含まれている場合、シャードと呼ばれる新しいサービスに対して別の要求を行います。 バックエンドは、このユーザーの識別子と、データベースを取得するモードをそこに渡します。 たとえば、「マスターが必要」、「同期レプリカが必要」、「最も近いホストが必要」などです。 Sharpeiは接続文字列を彼に返します。 次に、バックエンドは接続を開き、保持して使用します。



情報を知るために、誰がマスターで、誰がレプリカで、誰が生きており、誰が死んでいて、誰が後ろにいて、誰がいないのかを知るために、シャーペイは1秒ごとに最終データベースに行き、そのステータスを尋ねます。 この場所に、シャーディングとフォールトトレランスの両方の機能を担うコンポーネントが登場しました。







鉄に関しては、いくつかの変更を加えました。 Oracleはプロセッサコアのライセンスを取得しているため、垂直に拡張する必要があります。 1つのプロセッサコア、つまりSSDディスクに大量のメモリを詰めました。 少数のプロセッサコアを備えた少数のベースがありましたが、メモリとディスクの巨大なアレイがありました。 フォールトトレランス用のレプリカは常に1つだけでした。それ以降のレプリカはすべてお金です。



PostgreSQLでは、アプローチを変更しました。 各シャードに小さなベースと2つのレプリカを作成し始めました。 これにより、レプリカの読み込み負荷をラップできました。 つまり、Oracleではすべてがマスタから、PostgreSQLでは-2つの小さなマシンではなく3つのマシンからサービスが提供され、PostgreSQLで読み取り値をラップします。 Oracleの場合、垂直にスケーリングし、PostgreSQLの場合、水平にスケーリングしました。







「温かい」および「冷たい」ベースに加えて、「熱い」ベースも登場しました。 なんで？ アクティブユーザーの2％が負荷の50％を作成することが突然わかったからです。 私たちをレイプするような悪いユーザーがいます。 それらの下で、別々のベースを作りました。 ウォームコアと大差はありませんが、SSDもありますが、プロセッサがより積極的に使用されるため、プロセッサコアが1つ少なくなっています。



もちろん、シャード間のユーザー転送の自動化を撮影しました。 たとえば、ユーザーが非アクティブで、現在は[SATAドライブ付き] satashnyデータベースに住んでいて、突然IMAPの使用を開始した場合、「ウォーム」ベースに転送します。 または、彼が暖かい基地で6か月間移動していない場合は、「寒い」方に移します。



古いアクティブユーザーのメールをSSDからSATAに移動することは本当にやりたいことですが、それはできません。 あなたがアクティブユーザーで、SSDに住んでいて、1,000万通のメールがある場合、それらはすべてSSDにありますが、あまり効果的ではありません。 しかし、これまでのところ、PostgreSQLには通常のパーティション分割はありません。



すべての識別子を変更しました。 Oracleの場合、それらはすべてグローバルに一意でした。 このシャードにはそのような範囲があり、このように書かれているという別の基盤がありました。 もちろん、エラーのために識別子が交差し、すべての約半分がその一意性に結び付けられていたとき、私たちはファカップを持っていました。 痛い。



PostgreSQLの場合、識別子が単一のユーザー内で一意である場合、新しいスキームに切り替えることにしました。 ミッドレター識別子が一意である前であれば、uidミッドペアは一意です。 すべてのタブレットには、最初のuidフィールドがあり、すべてに接頭辞が付いています。これは、これまでのところどこにでもあります。



これはスペースが少ないという事実に加えて、別の非自明なプラスがあります。 これらの識別子はすべてシーケンスから取得されるため、インデックスの最後のページでの競合は少なくなります。 Oracleでは、この問題を解決するために逆インデックスを追加しました。 PostgreSQLの場合、挿入はインデックスの異なるページに移動するため、通常のBツリーを使用し、範囲スキャンを行います。インデックス内の1人のユーザーのすべてのデータが近くにあります。 とても便利です。



すべてのオブジェクトにリビジョンを導入しました。 これにより、レプリカからの読み取りが可能になりました。まず、古いデータではなく、次に、モバイルのIMAPの増分更新。 つまり、「このリビジョンでこのフォルダ内で何が変更されたのか」という質問に対する答えは、これにより大幅に簡素化されました。



PostgreSQLでは、配列、複合体ですべてがうまくいきます。 データ部分の非正規化を行いました。 次に例を示します。







これがメインのmail.boxネームプレートです。 各文字の行が含まれています。 彼女の主キーはuidミッドペアです。 1つの文字に複数のタグを含めることができるため、lidsタグの配列もあります。 同時に、「そのようなラベルの付いたすべての文字をください」という質問に答えるタスクがあります。 明らかに、これには何らかのインデックスが必要です。 配列にBツリーインデックスを作成すると、そのような質問には答えられません。 これを行うには、uidフィールドとlidsフィールドにトリッキーな関数インデックスginを使用します。 これにより、「そのようなタグを使用して、またはそのようなタグを使用して、そのようなユーザーのすべての文字を教えてください」という質問に答えることができます。

ストアドロジック

• Oracleはストアドロジックに苦労したため、PostgreSQLにはストアドロジックがまったくないことを誓いました。 しかし、実験とプロトタイプの過程で、 PL / pgSQLが非常に優れていることがわかりました。 ライブラリキャッシュの問題は発生せず、他の非常に重大な問題は見つかりませんでした。
• 同時に、 ロジックの量が大幅に削減され 、データの論理的整合性に必要なもののみが残されました。 たとえば、文字を入力した場合、フォルダーラベルのカウンターを増やします。
• 元に戻すことができないため、エラーの価格はずっと高くなりました 。 残念ながら、私たちは悪いコードをレイアウトした後、数回登りました。このことについて、私の同僚のAlexander は、私たちの会議で別の報告をしました 。
• ライブラリキャッシュがないため、デプロイがはるかに簡単です。 以前のように、四半期に1回ではなく、週に2、3回乗ります。

サービスアプローチ

• ハードウェアを変更し、水平方向に拡張し始めたため、ベースの保守方法を変更しました。 現在、 SaltStackを操作するベース 。 私たちにとって彼の最も重要なキラー機能は、現在ベースにあるものと私たちがそれから期待するものとの間の詳細な違いを見る能力です。 観察が満足された場合、その人は「ロールアウト」ボタンを押し、ロールします。
• 移行によってスキームとコードを変更します 。 これについて別のレポートがありました 。
• 私たちは手動のサービスを残し、可能なことはすべて自動化されました 。 ウィザードの切り替え、ユーザーの転送、新しいシャードのロードなど-これらはすべてボタンで非常に簡単です。
• 新しいデータベースの展開は1つのボタンであるため、開発用の代表的なテスト環境が用意されています。 各開発者には、必要に応じて2つのベースがあります。これは非常に便利です。

問題

そのようなことは決してスムーズに進みません。



これは、自分で解決できなかった問題を抱えるコミュニティのスレッドのリストです。

• 挿入のExclusiveLockの問題
• チェックポイント配布
• 巨大なshared_buffersとの関係の拡張に対するExclusiveLock
• マスターをバキュームした後、レプリカで起動プロセスがハングする
• 複製スロットと分離レベル
• BackendIdGetTransactionsのセグメンテーション違反

つまり、私たちはコミュニティに行き、助けてくれました。 これは、エンタープライズサポートがない場合の対処方法のテストでした。コミュニティがあり、機能しています。 とてもクールです。 もちろん、私たちはもっと多くの問題を自分で解決しました。



たとえば、ここでは非常に人気のあるジョークがありました。「理解できない状況では、自動バキュームのせいです」。 これらの問題も解決しました。



PostgreSQLの診断方法が本当に不足していました。 Postgres Proのスタッフが待機インターフェイスを入手しました。 これについては、2015年のサンクトペテルブルクのPGデーで既に話しました 。 それがどのように機能するかを読むことができます。 Postgres ProとEnterpriseDBの協力を得て、9.6カーネルに入りました。 すべてではありませんが、これらの開発の一部は9.6に含まれていました。 さらに、この機能は改善されます。 9.6では、データベースで何が起こっているかをより良く理解できるようにする列が登場しました。



サプライズ バックアップで問題が発生しました。 回復期間は7日間です。つまり、過去7日間の過去の任意の時点で回復できるはずです。 Oracleでは、すべてのバックアップおよびアーカイブログのスペースのサイズは、ほぼデータベースのサイズでした。 ベースは15テラバイトで、7日間でのバックアップには15テラバイトかかります。



PostgreSQLでは、barmanを使用します。その中で、バックアップにはデータベースのサイズの少なくとも5倍のスペースが必要です。 WALは圧縮されていますが、バックアップがないため、実際には機能しないファイルレベルの増分があり、一般にすべてがシングルスレッドで非常に低速です。 300テラバイトのメタデータをそのままバックアップした場合、バックアップには約2ペタバイトが必要になります。 メールストレージ全体が20ペタバイトであることを思い出させてください。 つまり、過去7日間にメタベースのバックアップのみを10％カットオフする必要がありましたが、これはかなり悪い計画です。



より良いものやパッチを適用したバーマンは思いつきませんでした。これがプルリクエストです。 このキラー機能を削減するように依頼してからほぼ1年が経過しました。 非常に慢な男。 2016年のPGdayで 、すべてを削減した同僚のEugeneがそれについて話しました 。 それは本当にバックアップをより良く揺さぶり、スピードアップし、正直な増分があります。



その時点までにPostgreSQLに登場していた実験、プロトタイプ、およびその他のデータベースの経験から、転送中に大量のレーキが発生することが予想されました。 しかし、彼らはそこにいませんでした。 多くの問題がありましたが、それらはPostgreSQLとは関係ありませんでした。 10年以上にわたって多くのレガシーが蓄積されてきたため、データの問題でいっぱいでした。 突然、一部のデータベースではデータがKOI8-Rまたはその他の奇妙なものでエンコードされていることが判明しました。 もちろん、転送ロジックにエラーがあったため、データも修復する必要がありました。

完了

PostgreSQLで本当に見逃していることがあります。



たとえば、古いデータをSSDからSATAに移動するためのパーティション分割 。 fork batmanを使用しない、組み込みのリカバリーマネージャーが不足しています。これは、おそらくbarmanカーネルに到達しないためです。 私たちはすでに疲れています。彼らはほぼ一年間彼らを蹴っていますが、彼らは急いでいません。 これはPostgreSQLから、つまりカーネル内から離れてはならないようです。



待機インターフェイスを開発します 。 第10バージョンでは定足数コミットが発生し、パッチは良好な状態にあると思います。 また、ディスクの通常の動作も本当に必要です。 ディスクI / Oの観点から、PostgreSQLはOracleに多くの損失をもたらします。



結果は何ですか？ レプリカの襲撃を考えると、PostgreSQLには1ペタバイト以上あります。 私は最近、5000億行以上あると思った。 毎秒25万件のリクエストが処理されます。 合計で3暦年かかりましたが、10人年以上を費やしました。 つまり、チーム全体の努力は非常に印象的です。



何を得たの？ 拠点がはるかに大きくなり、DBAの数が減少したにもかかわらず、展開はより高速になりました。 このプロジェクトのDBAは、Oracleの場合よりも少なくなりました。



望むかどうかにかかわらず、バックエンドコード全体をリファクタリングする必要がありました。 長年にわたって蓄積してきたすべての遺産は削減されました。 私たちのコードは今ではすっきりしています。それはとても良いことです。



スプーンなしのタールはありません。 現在、PostgreSQLでは3倍の鉄を使用していますが、これはOracleのコストと比較しても何もありません。 これまでのところ、大きなファカプスはありませんでした。



私からのちょっとしたコメント。 「メール」では、多くのオープンソースライブラリ、プロジェクト、およびターンキーソリューションを使用しています。 ほぼどこにでもあるタイトな3つの椅子（Linux、nginx、postfix）にPostgreSQLが追加されました。 現在、他のプロジェクトの多くの拠点で使用しています。 彼が好きだった。 4番目は、良い、信頼できる椅子です。 これはサクセスストーリーだと思います。



私はそれをすべて持っています。 よろしくお願いします！





Vladimir Borodin-PostgreSQLを使用したYandex.Mailの成功事例