HighLoad ++ 2016カンファレンスで、Ivan KruglovはBooking.comがどのように検索を開発したかについて話しました。これはホテルのオンライン予約システムの中心的な機能の1つです。



みなさんこんにちは！ 私はVanyaです、Perlで書いています-私に同情できます。 [ホールとステージでの微笑。]



わかった 真剣に、私の名前はIvan Kruglovです。私はBooking.comのアムステルダム市出身です。 私はここ4年間働いており、ここ1年半は検索を改善するチームで働いています。



私は遠くから少し始めたいです。 このフレーズで：







あなたが著者を知らなくても驚かないでください、これは私の同僚のエドゥアルド・スキオトです。 なぜ私は彼女を見せたいのですか？ 私の意見では、Booking.comの開発文化を非常に正確に反映しています。 その本質は、最高の印象、最高の体験を提供し、成長し、顧客のニーズに迅速に適応しなければならないということです。



ここにはいくつかのコンポーネントがありますが、それぞれについて簡単に説明し、同時にBooking.comについてお話したいと思います。 HighLoad ++で初めて導入されました。 興味があると思います。

統計

成長から始めましょう。 このように成長します。







青いグラフは、現在データベースにある宿泊施設の数です。 宿泊施設は、ホテル、ホテル、ヴィラ、アパートなどです。 現時点では約100万人です。 オレンジ色の線は、毎日予約される夜の数です。 Booking.comを通じて毎日100万泊以上予約されています。



2つ目は迅速な適応です。 適応するには、クライアントが何を望んでいるかを理解する必要があります。 どうやってやるの？ この方法を使用します。観察を行い、なぜこれが起こるのかという仮説を立て、この仮説をテストします。 何かがうまくいかなかった場合、私たちの観察は間違っているか、その解釈が損なわれます。 修正して、もう一度試してください。 これらのオプションのほとんど。 私たちのチェックで「すべてが大丈夫」と表示された場合、すべては問題ありません。次の観察に進むことができます。



これらの仮説を確認するために使用するメカニズムは、A / Bテストまたは実験です。 実験により、ある程度の統計的正確さで「はい」または「いいえ」と言うことができます。



多くの実験がありますが、それらは異なります。 サイト上のグラフィックを変更するときの実験は次のとおりです。







古典的な例は、アイコンの追加または変更、新しい機能の追加、いくつかのブロックの表示、メニューの新しいアイテムなどのボタンの色です。 これはユーザーに見えるものです。



2番目のタイプの実験は、内部で何かが変更された場合です。 たとえば、新しいAPIまたは何らかの新しいサービスがあるか、何らかのパッケージをアップグレードしただけです。 この場合、定量的な特性を収集します。 スライド上のこれは、応答時間の分布です。 一番上がそれでした。 以下になったものがあります。







次の最も重要なポイント-ユーザーがイノベーションによって悪化することはなかった、つまりユーザーのエクスペリエンスが低下しなかったことを確認したい。



非常に広範囲ですべてをカバーする別のタイプの実験があります。 従来は、次のように表すことができます。







ここで何を言いたいですか？ 私が少し誇張しているのは明らかです。誰もすぐにコードを本番にプッシュしません。 しかし、テストはありません-それは非常に最小限であり、開発者によって実行されます。



私たちには非常に優れた監視機能があり、トラフィックの一部で実験を開始できるだけでなく、何かが起こった場合、すぐに理解し、火を消して先に進むことができる優れた実験ツールがあります。 さらに、エラーバジェット-エラートレランスがあり、開発者の道徳的負担を大幅に軽減します。 これらの一連の要因により、実装の品質よりも問題のビジネス側により多くの注意を払うことができます。



現在Booking.comで実行されている実験の数を数えると、1,000を超える数が得られます。 非常に多くの実験を作成し、展開する必要があります。 レポートの準備で、私は昨年の統計を見ました。 平均して、1日に約70の展開を行っていることがわかりました。 これを標準的な8時間の営業日にすると、Booking.comの一部が5〜10分ごとに変更されることがわかります。

最高の経験

ユーザーが最高の印象を得るためには、IT部門だけでなく、会社全体が大きなパズルを組み立てる必要があります。 このパズルには多くの要素がありますが、いくつかはそれほど明白ではなく、いくつかはより明白で、いくつかはそれほど重要ではなく、いくつかは非常に重要です。 たとえば、リストは次のようになります。







リストが不完全であることは明らかで、単なる例です。 ここにあるべき大きな明白なポイントの1つは、優れた検索です。これは、次の2つのことを提供する必要があります。高速である必要があり、関連情報を提供する必要があります。 私のレポートでは、これらの2つのことについて話します。情報の速度と関連性です。



速度について少し話しましょう。 速度が重要な理由 なぜ私たち全員がサイトを高速化するのですか？



誰かが競合他社と測定します。 他の人は、顧客がそれらを離れないことを確認し、より多くのコンバージョンがありました。 Googleに尋ねると、そのようなことを言っている記事がたくさんあります。 これはすべて真実です。Booking.comではすべてを行っています。 しかし、もう1つの興味深いコンポーネントを強調します。



条件付きで2秒かかる条件検索ページがあるとします。 この2秒間がしきい値になり、その後クライアントが病気になると想像してください。 検索ページのフレームワーク内でメインの検索ロジックが90％の時間を要する場合、すべての機能について、他のすべての実験については、10％の時間が残ります。 ある種の難しい実験を突然開始した場合、2秒を超える可能性があります。



すぐに実行した場合、検索にかかる時間はわずか50％になり、その後、新しい機能や実験のために多くの時間が解放されました。 Booking.comで迅速に行っていることの1つは、実験や機能のために時間を空けたいということです。

検索する

さらに、検索とその特別な点について説明します。 検索の進化、現在のアーキテクチャと結論についてお話します。



例から始めたいと思います。 パリに行きたいゲストがいると想像してみましょう。 彼は遠く離れて住んでいる場合は家族、友人、車で一人でそこに行くことができます（そして彼が停止する駐車場があることが望ましいです）、そして彼は公共交通機関で行くこともできます（それならいいでしょう停止は遠くなかった）。 そしてもちろん彼は朝食が欲しい。 Booking.comの目標は、彼のすべての要件を満たす一時的な宿泊施設を見つける手助けをすることです。



この場合のゲストとサイトの相互作用は何ですか？ まず、彼はメインページに移動します。 フォームがあります。皆さんご存知だと思います。 彼はパリを運転します。 オートコンプリートと曖昧性解消サービス（曖昧さの明確化）との対話をすぐに開始します。その目的は、それがどのようなジオロケーションを意味するかを理解するのを支援することです。







実際には、「パリ」という単語で検索しただけで、世界中に約30個のパリがあることがわかります。 たとえば、パリの村、キギンスキー地区、ロシアのバシコルトスタン共和国。 これは彼が念頭に置いていたものではありません。 ベラルーシにはまだ2つ、1つの太平洋の島に村があり、10〜15個が米国にあります。







ユーザーは、意味を選択できるリストを表示し始めます。







リストに要素がない場合、ゲストは曖昧さ回避にリダイレクトされます。実際には、同じデータで、リストのみがわずかに大きくなります-数十の要素。







ゲストが望んでいることを説明するとすぐに（私はパリに行きたい）、検索クエリが検索ロジックに形成され、次の処理が行われます。

• 彼女は、属性でホテルを選択します。たとえば、駐車場のないホテルや朝食のないホテルをフィルタリングします。
• その後、必要に応じてグループフィットを行います。 ゲストが彼の家族と一緒に旅行する場合、家族は6人で大規模ですが、6人を収容できる部屋はありません。3+ 3、4 + 2、5 + 1でプレイしてみてください。
• 次に空室状況のホテルの選択です 。
• そして最後にランキング 。

検索サービスが機能すると、ゲストが説明とレビューを読んで価格を調べ、選択する検索ページが形成されます。 その結果、最終段階である予約に進みます。 Booking.comに新しい予約があり、成功しました。すべて順調です。







ここで、2つの余談を行います。 最初に、私のさらなるレポートはその検索ボックスに関するものであり、私は検索ロジック、内部で何が起こっているかに焦点を当てます。 第二に-私はすでに可用性による選択について言及しました。 それを明確にするために私が何を意味したかをお話ししましょう。



ここで2つの用語を定義する必要があります。 最初は在庫 、可用性です。 2つ目は可用性です。 違いは何ですか？



「パイプのある家」ホテルがあると想像してみましょう。 部屋が1つあり、その所有者はこのホテルを年末年始にレンタルしたいと考えています。 彼はそのような価格を設定しました：







1月1日から2-2000₽、2から3-1750₽など。 これは、ホテルが使用するデータです。 ホテル、部屋、日付、価格。



ゲストの観点からは、すべてが少し異なって見えます。 「1月1日から5日までパイプホテルのあるホテルに泊まりたい。その値段は6500₽だ」 データは同じですが、プレゼンテーションはわずかに異なります。 これらの表現間の移行は常に些細なことではありません。







この場合、それは簡単です、私たちはそれを取り、それらをすべて合計します。 そして、私たちが多くの部屋、多くの関税、多くの政策がある大きなホテルを持っているなら、いくつかの部屋は忙しいかもしれません、いくつかの政策は利用できないかもしれません？ 結果は、価格を計算する重要な機能です。

検索の進化

私は紹介を終え、検索に決め、用語を紹介しました。 ハードコアに行きましょう。



古代、データベースに10万件未満のホテルがあったとき、Booking.comは暖かいLAMPスタックを使用していました。 LAMP-Linux、Apache、MySQL、およびP-PHPではなくPerl。 Booking.comはモノリシックアーキテクチャも使用していました。 ビジネスプロセスは次のとおりです。







当ホテル。 MySQLには在庫ベースがあり、ホテルはそこにデータを入力します。私はそのようなホテルです。私はそのような部屋を持っています。そのような日のために私の価格です。 次に、インベントリデータベースからデータを取得し、可用性を計算し、検索結果をゲストに返す検索ロジックがあります。 次に、ゲストは「予約しています」フェーズに進みます。 この段階のロジックは、インベントリデータベースに移動し、レコードにマイナスまたはマイナスを付けて、そのような数がないことを伝えます。



データベースが約15万ホテルだった2010年の領域では、このアプローチは完全に使い果たされました。 問題は可用性の計算でした。 この機能は非常に重いものでした。 痛みが何であるかをよりよく理解できるように、例を示します。







その時点でデータベースに500のホテルがあり、それぞれに平均3部屋タイプ、2関税がある場合、選択して価格で並べ替えるには、約3000の計算が必要です。 アーカイブデータによると、スタックは次のようなものを生成できます。







1秒で、彼は1日の生活のたった1000の価格と30日の生活のたった90の価格を数えることができました。 滞在期間が長くなるほど、より多くの選択肢を整理する必要があります。



ちなみに、2008年のしばらくの間、Booking.comでこのような理由で価格による並べ替えはありませんでした。 私は学生として初めてア​​ムステルダムに到着したことを個人的に覚えています。 あまりお金がなかったので、一番安いホテルを探したいです。 この理由だけで価格で並べ替えることはできませんでした。 今ではすべてが順調です。



どうする

• 同僚の頭に浮かんだ最初のことは、すべてをキャッシュすることでした。 うまくいきませんでした。 最大キャッシュヒット率はわずか60％でした。
• すべてを新しいテクノロジーで書き直しましょう。 私たちはそうしないことにしました。 なんで？ まず、モノリシックアーキテクチャ。 つまり、書き換える場合、そのほとんどを書き換える必要があり、多くの時間がかかります。 第二に、敏ility性が低下します。 会社は前進する必要があります。 何が良いか見てみましょうか？
• すべてを具体化してみましょう。

実体化とは これに関連して、これはおよそ次のとおりです。 例に戻って、チェックインと滞在期間の可能なすべての組み合わせを取得し、単純に計算します。 たとえば、1番目から2番目、1番目から3番目、1番目から4番目、1番目から5番目、2番目から3番目、2番目から4日から4日など 事前にすべてを検討します。







すべてが事前に計算されているため、この価格を引き出すだけで良いパフォーマンスが得られます。 それは正しい方法であり、それは重要です。 たとえば、キャッシュからデータを取得する場合の迅速な方法はなく、キャッシュにない場合は遅くなります。 欠点は、大量のデータです。 これらのオプションをすべて保存する必要があります。



このオプションで、停止しました。 このデータ量がどれほど大きいかを理解するために、現在の情報を示します。







現時点では、100万のホテル、3種類の部屋、2つの関税、1〜30日、滞在期間。 （Booking.comは、最大30日間、2か月間ホテルを予約することはできません。）データは、約1年半前に計算されます。 これらすべての数字を掛けると、Booking.comは現在約1,000億の価格を保存していることがわかります。

実体化の場合のビジネスプロセス

おなじみのホテル、おなじみの在庫ベース。 新しい可用性データベースと実体化プロセスが表示され、価格を実体化して可用性データベースに追加します。 検索ロジックは事前に計算された価格を使用し、予約ロジックは元の在庫データベースのデータを引き続き変更します。 在庫は私たちの主なデータベースであり、その中には真実があり、可用性はキャッシュの一部であり、ヒット率は常に100％です。



このようなスキームでは、2つの課題があります。 最も重要なこと：ユーザーエクスペリエンスを損なわないようにする方法 検索ロジックで最初にそのようなホテルがあり、そのような部屋があると言ってから、予約段階に行ったときにそうではないと言ったことを確認しないのはどうですか？ 2つのデータベースを一貫した形式で維持する必要があります。



この問題を解決するために、次の観察を行いました。 ダイアグラムに戻りますが、これは、ユーザーがサービスとどのようにやり取りするかをすでに示しています。







検索エンジンが戻ったら、この部分を見てください。「予約しています」フェーズへの移行です。 ここで、ユーザーがここで費やす時間には数分かかることがわかります。レビューを読みながら、説明を読みながら5〜10分です。 ゲストが予約ステージに移動したときに、彼が予約したかった最後の部屋がすでに残っていることがあります。 ビジネスモデルには自然な矛盾があります。



2つのデータベースを完全に一貫性のあるものにしたとしても、その性質のために、「予約」段階では常に一定の割合のエラーが発生します。 なぜデータを完全に一貫させる必要があるのか​​と考えました。 それらを不整合にしましょう。しかし、この不整合に関連して発生するエラーのレベルは、ビジネスプロセスに起因するしきい値より高くなりません。

パイプライン

まず、更新元があります。 インベントリに何らかの変更を加えるたびに、グローバルキューの1つに通知を送信します。 通知は、例えば、「そのようなホテル、彼は部屋を予約している」または「そのようなホテルは価格を変更した」である。



2つのキューがあり、1つはリアルタイム、もう1つはバッチ、これはバックログです。 これは、いくつかの優先順位を設定するために行われます。 明日予約が行われた場合、1年前に予約するよりも早くカウントすることは理にかなっています。



さらなる通知は、多くのマテリアライザが存在するマテリアライゼーションクラスタの1つに流れ込みます。 これらは容量を超えて特別に作成されているため、問題が発生した場合に迅速に攻撃を仕掛け、すべてをすばやく計算し、すべてを可用性データベースにすばやく配置できます。 インベントリデータベースからデータを取得し、すべての可能なオプションを並べ替えて、可用性を高めます。



興味深い点が1つあります。 小さな青い「I book」ボタンは、予約が成功した場合だけでなく、予約が失敗した場合、エラーの場合に通知を送信します。 エラーが発生した場合、潜在的に何らかの矛盾があることがわかります。念のため、つまり、自己修復メカニズムをカウントしてみましょう。



最後の要素は、新しい日の計算です。 大まかに言って、可用性は1年半の大きさのそのような動く窓です。 たとえば、1年と1日前に毎日計算する必要があります。 明らかな理由で、それらは常にバッチキューを通過します。

データ保存

多くのデータがあり、読み取りおよび検索クエリが優先されます。 したがって、読み取り用に最適化されています。 MySQLに保存された、扱いにくいクラスター化プライマリキーインデックスを使用しました。



クラスター化する理由 なぜジオロケーションなのか？ 検索が実行されるたびに、互いに近いホテルのグループで実行されます-地域プロパティがあります。 現実に地理的に近いホテルがデータベース内で近くにあると便利です。 貧弱なMySQLがドライブを異なる方向に走る必要がないように。 データがディスク上でコンパクトであればあるほど良い。



これを行うために、Zオーダーカーブテクニックを使用しました。これについては説明しません。すべてが非常に単純です。 詳細はこちら 。



チェックインによるシャーディングを行いました。 多くのレコードがあります：在庫の1つのレコードは、可用性の数千のレコード変更を引き起こす可能性があります。 そのため、SSDを使用する必要がありました-ハードドライブは負荷を保持しませんでした。 負荷は4000 IOPSでした。

結果

• 可用性の計算が50〜100回加速されました。 何も数える必要はありません。すべてが数えられ、必要なものを取り出して引き出します。
• 巧妙なクラスタ化されたMySQLインデックスにより、すぐにコールドスタートを開始しました。 すべてのデータは互いに近いため、ディスクから数ページをプルする必要があります。
• 実体化時間は通常1分未満です。 実際には、数十秒です。
• 最初の仮定が有効であることを確認するために、あらゆる種類のメトリックとアラートでシステム全体を網羅しました。 重要な指標は品質チェックでした。 品質チェックは、可用性から選択を行い、在庫から選択を行う何らかの外部プロセスであり、このデータに基づいて可用性を考慮して比較します。 データが一致すれば、すべて問題ありません。 データがなく、データが異なる場合、またはレコードがここにあり、そこにもレコードがない場合は、何らかのアラートを通知します。 このようなアラートは常に存在しますが、特定のしきい値を超えないことが重要です。

実体化は、問題を十分に長い期間解決しました。 この間、スタックは少し変更され、uWSGI + Nginx + Perl + MySQLの使用が開始されました。



2014年の地域では、データベースに約50万のホテルがあり、ビジネスの成長があり、新しい機能が登場し、国と地域による検索が登場しました。 たとえば、イタリアでは10万のホテルです。



反対側からほんの少しだけ、同じ問題に遭遇しました。 問題は、Perlがあり、シングルスレッドであるということでした。 1つのリクエストは1人のワーカーによって処理されます。 彼は、これらすべてのサンプル、選別などを消化することはできません。



どうする Map-Reduceスキームに従って全体を並列化することにしました。 Map-Reduceフレームワークを書きました。 サービス指向アーキテクチャに切り替えました。 そして、次の結果が得られました。大規模なリクエストが高速化されました。 このため、私たちのリクエストは小さなものにintoられ、ワーカーに送信され、ワー​​カーは自分の小さな部品を考慮し、データをメインワーカーに送り返し、全体を管理して最終結果を作成します。



大きなクエリは高速になりましたが、同時に世界の検索には約20秒かかりました。 まだあまり良くありませんが、それよりはましです。 逆の結果は、小さなクエリが遅くなることでした。 この理由は、特にシリアル化とプロセス間のデータ転送のための大きなIPSオーバーヘッドです。 Perlはシングルスレッドであり、多くのプロセスを使用してのみシリアル化できます。



これは、アーキテクチャの変更について考え始めた時期であり、現在使用しているアーキテクチャに至りました。

現在のアーキテクチャ

私たちは理解しました：もし私たちが持っていたものをアップグレードし、締め、調整し、ワークフローを変更したら、トレーラーでしばらく動作させることができます。 しかし、スタックはその能力を使い果たしそうになりました。 ラクダは少し疲れています。



私は時代遅れのアプローチを放棄したかった。 このアーキテクチャは、5〜10年前に基盤が築かれたアプローチに基づいて構築されました。 その時点で使用されていたこれらのアプローチは、現時点でデータベースに50万または100万ものホテルがある場合にはあまり適していません。



MapReduceを維持したい、サービス指向のアーキテクチャを維持したかった。 検索クエリを実行するために必要な可用性およびその他のすべてのデータにすばやくアクセスできるようにしたいです。 高速なデータベースにすばやく書き込みたいと思いました。 当社では、可用性を更新します。 安価な並行性が必要でした。



見回した。 私たちはTarantoolが好きで、試しました。 それは約一年半前でした。 ただし、次の理由で使用しないことにしました。



まず、Tarantoolに切り替えると、Luaですべてのビジネスロジックを記述する必要があることを非常に混乱させました。 彼女はよく勉強していますが、私たちは彼女をあまりよく知りません。 ある種のスクリプト、小さなストアドプロシージャがある場合、それはLuaのビジネスロジック全体です。 2つ目-私たちがLuaで取ってすぐに書いたコードは、私たちが望むほど速く動作しませんでした。 Javaの並列実装がありました。 Javaでは、コードは高速に動作しました。



最終的に、PerlからJavaに移行することにしました。 Javaは安価なマルチスレッドを提供しますが、これは一定の要因ではありません。 Javaは原則的に高速であり、内部オーバーヘッドが少なくなります。 すぐにアクセスできるように、メモリ内にあるすべてのデータを決定しました。 MySQLからRocksDBに移行することにしました。

建築

すべての中心には検索ノードがあり、ローカルに組み込まれた可用性データベースがあります。 これは、データベースがプロセスと同じネームスペースにあることを意味します。 このノードにはインメモリインデックスがあり、永続化されるインメモリデータベースがあります。



多くのノードがあり、それらはクラスターに結合されています。 行ごとの断片、列ごとのレプリカ。 静的シャーディングを適用し、シャードが属する各ノードにペンを割り当てます。 シャードの数は、すべてのデータがノードのメモリに配置されるほどです。 単純な操作「余りのある除算」、hotel_id mod Nを使用してデータを拡散します。すべてのレプリカは同等です。 マスターがなく、すべてのピアがあり、ノード間の相互作用はありません。



これで、検索クエリはコーディネーターの1つに当てはまり、多くのコーディネーターがいます。 コーディネーターのタスクは、リクエストを受け取ってすべてのシャードにブロードキャストするときにスキャッターギャザーを作成することです。 ローカルデータを処理した各シャードはコーディネーターにリクエストを送り返し、コーディネーターはこのデータをマージして最終結果を形成します。



シャード内で、レプリカがランダムに選択されます。 レプリカが利用できない場合は、別のものを取得して試してください。 コーディネーターは常にすべてのノードにpingを実行し、クラスターの現在の状態を把握します。



実際、これは標準の検索エンジンであり、同じYandexまたはGoogleはほぼ同じように機能します。 ここには可用性という形でのチェリーがあります。組み込みデータベースを更新する必要があります。可用性は常に変化しているため、リアルタイムで更新する必要があります。



このために、PerlとMySQLに基づいた既存の経験を使用しました。 わずかな変更を加えて同じPipelineを使用しました。データベースに直接データを書き込む代わりに、マテリアライズされた可用性キューに書き込みました。 なぜ実現するのですか？ 実体化の黒い四角の中では、すべての行は通知のみでした。つまり、オレンジ色の行はデータそのものであり、肉そのものです。



可用性データを更新するにはどうすればよいですか？ 各ノードは、このキューを個別に独立して取得および読み取り、更新をローカル状態に適用します。 データを1回カウントしましたが、これは非常に高価ですが、何度も使用します。このキューには、過去1時間のデータが格納されます。ノードが背後にある場合、彼女は追いつくことができます。



このようなスキームを使用すると、クラスターは最終的に一貫します。最終的に、すべてのノードが同じ速度で動作しない場合、変更を停止すると、すべてのノードが同じ状態になります。



この状況は私たちに合っています。ここでは、実体化の構築に使用した原則に依存しています。つまり、ベースを完全に一貫させる必要はありません。このレベルのエラーが許容値を超えないようにするだけです。



ここでも品質チェックがあり、さらに1つのメトリックを使用します。各乳量を監視し、キューの終わりからどれだけ離れているかを監視します。遅すぎる場合は、それを取り出してクラスターから引き出します。これは自動化されたプロセスです。



内部で何が起こるか見てみましょう。入力があります：

1. 場所：パリ;
2. 検索属性：駐車場、朝食など。
3. チェックイン、チェックアウト。
4. 「チーム」の構成（たとえば、6人の家族）。

入り口では、逆インデックスに基づいて基準を満たすホテルのプライマリフィルタリングが行われます。インデックスがあり、キーは都市であり、値はこの都市のすべてのホテルです。たとえば、パリとパリにあるすべてのホテル。 2番目のリスト、たとえば駐車場があるホテルがあります。さらに、これらの2つのリストを横断すると（操作は安くて高速です）、パリにある駐車場付きのホテルを取得できます。







最初にフィルター処理されたホテルのリストを取得し、それをピースに分割しました。各ピースにはスレッドが渡されました。これには3つのステップが必要です。最初に、彼は空室状況に基づいて二次フィルタリングを行い、部屋が空いているかどうか、空いている場合はどの価格でこのホテルをチェックします。ここでもグループ適合が行われます。次に、ソート段階に進みます。最終的に、topnが計算されます。



たとえば、検索クエリで「最初のページが欲しい」という場合、ページには15個のクエリがあります。つまり、各スレッドはtop15のみを引き出し、このデータをマージが実行するメインスレッドに送信します。マージは次のように行われます。すべてのnスレッドからデータを取得し、ntop15が取得され、top15がそれらから取得されます。次に、コーディネーターにデータを送信し、コーディネーターはすべてのシャードからの結果を期待します。各シャードから、彼はtop15を受け取り、再びtop15を作成します。カスケードデータ削減が判明しました。だから内部で動作します。



RocksDBに落ち着いた理由をお伝えすることを約束しました。これを行うには、2つのサブ質問に答えます。組み込みデータベースが必要な理由まさにRocksDBなのはなぜですか？



組み込みデータベースが必要な理由このようなタブレットのデモを行いたい：







サーバーの世界とそのレイテンシーからのイベントがあります。理解を深めるために、理解可能な値にスケーリングしました。最速のイベントはCPUサイクルです。 0.3ナノ秒かかります。 1秒があった場合はどうなりますか？この場合、L1キャッシュへのアクセスは3秒間、L3キャッシュへのアクセス-43秒、メインメモリへのアクセス-6分、ネットワーク経由で1キロバイトの送信-9時間、データセンター内の往復-19日、TCPパケットリレー- 200年



組み込みデータベースについて話している場合は、緑色で強調表示されている上部に近いプロパティについて話します。ネットワーク上にあるデータベースについて話している場合-MySQL、Cassandraなど、どんなデータベースであっても-収益について話している。それが組み込みを選択した理由です。



GitHubにあるRocksDBベンチマークを見ると、組み込みデータベースを持つTarantoolベンチマークを見ると、トランザクション、つまりQPS（1秒あたりのクエリ）があり、すべてが数百万単位で測定されます。これは、これが発生する理由の1つです。



RocksDBを選ぶ理由これは非常に簡単な話です。負荷に耐えられるデータベースが必要でした。本当に必要な機能はありませんでした。キーバリュー、保存、取得、削除だけです。 MapDB、Tokyo / Kyotoキャビネット、leveldbのさまざまなオプションを試しました。どうやって試しましたか？私たちはそれらを取り込んで、戦闘環境に置きました。ページキャッシュ内のデータセット、80％の読み取り+ 20％の書き込み、読み取りが大幅に優先されます。 RocksDBは、ランダム書き込みで最も安定したランダム読み取りパフォーマンスを示しました。ランダムレコードは更新の可用性であり、幸せな読書は検索クエリです。止まりました。



興味深い点：RocksDBの作成者-Facebook。書き込みとスペースの拡大により、SSDとして最適化されています。実際には、通常のハードドライブでは問題なく機能します。私たちの場合、1秒あたり1.5万件のレコードを完全に保持します。



私たちは次の







ことを知りました：一番上にあるのは、検索サービスの応答時間、前と後の時間です。場合によっては、検索クエリの速度が3桁向上したことがわかります。重要なのは、大規模な問い合わせ（特に3万のホテルがあるアドリア海沿岸）と小さな問い合わせ（300のホテルしかないソフィア）の両方が高速化されたことです。



すでに下のグラフを示しましたが、これらが現在のアーキテクチャを導入したときに得た結果であるとは言いませんでした。上記のとおり、平均時間は約2秒です。下のチャートは、1.3秒になったものです。ページ速度を700ミリ秒改善しました。これは新しい機能、実験に費やすことができます。これはとてもいいです。

おわりに

結論として、私は言いたい：みんな、みんな自分のやり方を持っている。見て、あなたに合ったものを試してください。同じRocksDBテスト-具体的なタスク、特定のワークロードの戦闘条件を取り入れたため、特にベンチマークを投稿しません。私たちはさまざまなオプションを取り、テストし、試しましたが、うまくいきました。あなたの場合、それはうまくいかないかもしれません、試してください、それはそれほど時間がかかりません。



二番目。このプロジェクトに取り組んでいる間、私は自分自身のために多くの結論を出しました。まず第一に、速度は変換だけでなく、ページにいくつの機能を持ち、ページでいくつの実験を実行できるかということです。



実体化を見てください。最新のプロセスまたは最新のデータストレージシステムは、膨大な量の情報を保存できます。私が示した同じ1,000億の価格は、800ギガバイトという悲惨なものです。最大-価格ごとに8バイト。 800ギガバイトは、マシンクラスターは言うまでもなく、最新のトップエンドサーバー構成のメモリに収まります。すべて実行可能で、すべて機能します。すべてがカウントされるため、すべてが非常に迅速に機能します。



必ずビジネスプロセスを見てください。あなたのビジネスプロセスはあなたに多くを伝えることができ、あなたの人生を大いに簡素化することができます。私たちの場合、2つのデータベース間でデータの一貫性を維持することは意味がありません。ビジネスプロセスに不整合が埋め込まれているためです。主なことは、特定のしきい値を超えなかったエラーのレベルです。



それは私にとってすべてです、来てくれてありがとう！何かお役に立つことをお伝えしたいと思います。





Ivan Kruglov-Booking.com検索アーキテクチャ