Tarantool：1日あたり15億のリクエストを処理する方法

Tarantoolレポート：1日あたり15億のリクエストを処理する方法 " -Mail.Ru Technology Forum 2011の一連のトランスクリプトの次。 レポートを復号化するシステムの仕組みの詳細については、 Mail.Ru Technology Forum：High-tech in event-managementの「Inside Out」記事を参照してください。 フォーラムWebサイト（ http://techforum.mail.ru ）および他のレポートのトランスクリプトへのリンクもあります。

（モバイルデバイス用のビデオバージョンをダウンロード -iOS / Android H.264 480×368、サイズ170 Mb、ビデオビットレート500 kbps、オーディオ-64 kbps）

（高解像度ビデオバージョンH.264 624×480、サイズ610 Mb、ビデオビットレート1500 kbps、オーディオ128 kbpsをダウンロードします）

（プレゼンテーションスライドのダウンロード 、520K）



誰もが彼を知っているので、このスピーカーを紹介するのは難しいです。 皆さんは、Kostyaが手にした製品を使用していると確信しています。 これは主にMySQLです。 Kostyaは、長年にわたってこの人気のあるデータベースを開発してきました。このデータベースは、100％でなければ、ロシアのサイトの90％に使用されます。 今日KostyaはMail.Ru Groupで働いています。 Kostyaは今日、私たちが何をしたか、どのように機能するか、そして最も重要なこと-サービスを利用できるようにするパフォーマンスの種類について教えてくれます。







こんにちは 今日はたくさんの人がいます。 来てくれてありがとう！ 私はすでに紹介されているので、私はまだ自分の魂とケースのエンジニアであることを付け加えたいと思います。 私はむしろリードするのではなく、タランツールの開発に積極的に参加しているので、もし興味があれば、今日は彼に関するすべてを学ぶ機会があります。 何らかの方法で、このレポートは、将来のDBMSのトピックに関する哲学に加えて、タランツールに関するものです。 ですから、今日ここに来た人たちを理解し、なぜあなたがそれをしたのかを理解したいと思います。



Tarantoolを試しにこのレポートにアクセスした人は、このフォーラムで詳細をご覧ください。 そのような人はいますか？



一般に、 TarantoolはMail.Ru Groupによって開発されたシステムであり、当社で最も積極的に使用されていますが、適用範囲ははるかに広いため、これは素晴らしいことです。 これはオープンソースのシステムであり、私の意見では十分に文書化されており、多くのプログラミング言語（Python、Ruby、Perl）へのコネクタがあります。 最近、ほんの2日前、コミュニティのメンバーの1人がPythonの新しいコネクタを作成しました。 したがって、今日の会話の結果がタランツールを試すことになることを願っています。 そして、おそらくあなたはこれがなぜ悪いのかと言う-私はそのようなレビューを聞いて喜んでいるでしょう。







何について話しますか？ レポートのトピックはかなり野心的であるため、DBMSエコシステムにおけるTarantoolの位置について説明します。データを格納するためのさまざまなソリューションが存在する理由、この量が適切な理由について説明します。 次に、システムに直接アクセスして、何ができるかを分析します。 最後に、私の計画、チームの計画、製品に追加する機能などについての話を締めくくります。







これがそのような写真です。たった30分でこれらすべてのロゴを訓練しました。 これらのロゴの半分以上を認識している人は何人いますか？ 少数派。 つまり 多くの人がMySQL、おそらくMemcached、おそらくPostgreSQLを知っています。 これですべてです。



今日、Hadoopについての話を聞きましたが、実際、これらのシステムはすべて非常に広く使用されており、非常に人気があります。 そして、これはすべてオープンソースシステムです。 システムソフトウェアの世界は、ますますオープンソースに向かっています。 元Yahooプログラマーによって開発された唯一の非オープンソースシステムはCitrusleafです。 これはかなり豊富な商用システムです。



上記のシステムが対象とするデータ特性の観点からこのスライドを分析すると、2つの次元が見つかります。 最初の次元はデータの量です。 Cassandra、Hadoop、Voldemort-大量のデータを管理するように設計されたシステムです。 図の反対側には、あまり大量のデータを処理しないシステムがよく見られますが、このデータへのアクセスは非常に高性能です。 2番目の次元は、データ構造のレベルです。 これらは、これらのシステムを比較できる2つの指標です。 実際、NoSQLの世界の次元ははるかに大きくなっています。 なぜNoSQL運動が生まれたのか、なぜこの富を見るのか？ 私の意見では、従来のDBMSの世界には、主に3つの未解決の問題があります。 10、20の問題を見つけることができますが、リレーショナルDBMSの主で実際に解決が不十分な問題は次のとおりです。







最初の問題である水平スケーリングの問題は、二次キー、複雑なクエリ、ストアドプロシージャが、数十または数百のコンピューターのクラスター上で十分にスケーリングされないことです。 前のレポートのようにノードを追加することはできません。Hadoopでは新しいノードを追加するだけだと聞いたことがあります。 原則として、問題は解決されます。 十分な数のスケーラブルなSQLシステムがありますが、非常に高価です-NonStop SQL、Teradata。 たとえば、銀行部門で使用されます。 つまり、水平方向にうまく拡張できるSQLシステムがありますが、これまでのところ、これらのソリューションはオープンソースではありません。



リレーショナルDBMSの2番目の問題は、最初にデータスキームを定義し、次にアドホックデータリクエストを作成できるように設計されていることです。 つまり 任意のSELECT、任意のJOINなどを記述できます。 それはしばしば反対です。 データスキームは非常に動的に変化しますが、リクエストは多かれ少なかれ固定されています-データスキームとともに変化しますが、それだけです。



まあ最終的に問題＃3はパフォーマンスです。 それは、ガスの価格のようなものです。つまり、20年前のもので、エンジンが4〜6リットルだった場合、同じガソリンまたは内燃機関のリットルからさらに多くの馬力またはキロメートルを絞り出す方法を考えています。 。 従来のDBMSは、古いアメリカの車に似ています-大きくて美しく、革のインテリアと高い滑らかさを備えています。 しかし、従来のDBMSのアーキテクチャは、別のアプリケーションである他のハードウェアを想定して作成されました。 ハードドライブの速度、メモリの速度、CPUとCPUキャッシュの速度のこれらすべてに対する比率...一般的には、System R以来大きく変化しています。 そして、何万台ものコンピューターが存在するMail.Ru Groupなどのデータセンターでは、この非常に重要な要素であるリレーショナルDBMSのエネルギー効率が非常に重要になっています。 実際、NoSQLクエリを処理する場合、SQL解析のオーバーヘッド、効果的なクエリ実行プランの検索、および複数の読み取り値の一貫性の確保は不要になります。



そして、従来のDBMSの問題は一般に科学者や実務家のコミュニティによって理解、研究、認識されているという事実にもかかわらず、NoSQLの世界はこれらの問題に対する新しい解決策だけでなく、明確なスレート、アイデアの爆発、そして実際には爆発することが多い場所で答えました何も必要ありません。 たとえば、データモデルなどの領域。 つまり NoSQLの世界では、Edgar Coddの有名なモデルを廃止し、列指向ストレージ、キーバリューストレージ、JSON、XML形式などの列ストレージなどのパラダイムを提案しました。





データの一貫性のさまざまなモデルも再検討され、実際に適用されています。 ここで、一貫性、データの可用性、DBMSクラスターのパーティションに対する安定性、つまり無関係なセグメントへの分割の関係を定義する、前述のCAP定理を思い出すことができます。 多くの人がこの定理を解釈しようとしているため、アプリケーションプログラマは3つのデータモデルから2つのプロパティを選択する必要があります。 たとえば、最終分析ですべてのノードがノード間で一貫している場合、各ノードのデータの一貫性、およびノー​​ド間の最終的な一貫性を選択できます。



たとえば、新しいデータアクセス言語も積極的に提供されていますが、これらは歴史、 オブジェクトクエリ言語 、XQL、NQLなどの例です。10年前、XML DBMSは非常に人気がありましたが、現在はどこにありますか？



そして最後に、常に非常に重要なデータストレージアルゴリズムの絶え間ない進化と、定数ハッシュ 、マスターマスタレプリケーションなどの膨大な数の新しいスケーリングメソッドの作成を目の当たりにしています。



DBMSの世界の未来は何ですか、NoSQLの動きは何につながりますか？ 私の意見では、データストレージソリューションの世界は拡大し、アプリケーションエンジニアは、NoSQLリポジトリ、リレーショナルリポジトリ、Hadoopのような分散クラスタがあることを知らざるを得なくなります。 したがって、将来の製品の多様性のうち、3つのニッチが形成され、3つの基本的なソリューションのクラスターがあります。そのうちの1つはリレーショナルDBMSであり、当然、今後も長く残ります。





データモデルを使用した多数の実験につながるものは何ですか？ たとえば、データ構造サーバーとしても知られるRedisのパラダイムを考えてみましょう。このアプローチは普及しますか？ 私の意見では、データモデルは2つの基本的なアプローチを安定させる必要があります：プレゼンテーションからのモデルの抽象化の存在を示唆するアプローチ、ここではリレーショナルモデルよりも優れた抽象化、およびデータ表現モデル自体です。



これで、最新のDBMSの世界のレビューを完了したいと思います。 予測は恩知らずの出来事ですが、NoSQL DBMSの世界におけるTarantoolの位置を知るために、一般的な状況を説明することにしました。



Tarantoolは、すべてのデータをRAMに保存する高性能ストレージです。 多くの場合、最初はそのような異論を耳にします-「しかし、それは非常に高価です」。 しかし、RAMとフラッシュメモリを比較すると、RAMはフラッシュよりも安価であることがわかります。



Tarantoolは永続的なストレージです。 データはRAMに保存されますが、データの変更はすべてアトミックです。 Tarantoolに記録されているものはすべてディスクに書き込まれます。



ここで、私は気を散らし、過去から例を挙げたいと思います。 MySQLの歴史を思い出すと、最初はすべて、MySQLユーザーコミュニティがトランザクションを必要とせず、データストレージの信頼性と原子性は必要なかったという事実から始まりました。 MyISAMのみがMySQLの安定したストレージサブシステムであり、Montyがトランザクションを必要としないことをユーザーに納得させようとしたMySQL 2000を思い出します。



MySQLの経験に基づいて、トランザクションは現代の産業用ストレージシステムに必要であるという信念を形成しました。 これは、システムアーキテクチャの残りのパラメーターを決定する基本パラメーターであるため、Tarantoolはすでにアトミック操作をサポートしており、現時点では本格的なトランザクションサポートを開発しています。 次のバージョンでは、すでにそれがあります。



データアクセス言語の分野では、TarantoolソリューションはSQL言語ですが、他のプログラミング言語もサポートされています。





ただし、データモデルの観点から見ると、Tarantoolはキーバリューストレージ、つまり 主なデータアクセスシナリオは、キーごとに値を取得することです。 したがって、すべてのSQL機能が実装されているわけではありません。



単純なINSERT / UPDATE / SELECT / DELETEクエリに加えて、Luaストアドプロシージャをサポートしているため、使用しているデータアクセススクリプトを非常に柔軟に決定できます。 ストアドプロシージャを使用すると、Tarantoolをデータサーバーからビジネスロジックサーバーに変えることができます。 任意のデータ保存形式、データの一貫性の任意の不変式、任意のクエリをプログラムすることが可能になります。



聴衆からの質問：

データの永続性はどのように維持されますか？

ロギング、つまり すべてのエントリはディスクに記録されます。 これについて説明しますが、最初にデータモデルについて説明します。





私たちのデータモデルは発明ではありません。 単純化されたリレーショナルモデルとして説明します。 基本的なストレージ要素はタプルです。 タプルには任意の次元があり、一意のキーに関連付けられたフィールドの任意の長さのリストにすぎません。 各タプルはいくつかのスペースに属します。 タプルのフィールドを使用して、インデックスを決定できます。 リレーショナルDBMSとの類似性を引き出す場合、「スペース」はテーブルに対応し、「フィールド」は列に対応します。 整数と文字列の2種類のデータと、ハッシュとバイナリツリーの2種類のインデックスをサポートしています。







インデックスは単純または複合のいずれかであり、検索には任意のインデックスを使用できます。 ただし、各スペースでは、単純な主キーを指定する必要があります。これは、挿入、更新、または削除の際にアクセスするために使用する必要があります。 たとえば、フィールド3および5、またはフィールド7、9、11を介して、複合セカンダリキーを介してアクセスできます。











繰り返しますが、私たちはデータアクセス言語の分野のイデオロギー家ではありません。クライアントはSQLアクセスを実装し、他のプログラミング言語のコネクタの分野では、従来のDBMSの世界の合意に準拠しています。 PHPでは次のようになります。





開始するには、データベースとの接続を確立する必要があります。 クエリを実行するには、アクセスしているタプルスペースを特定する必要があります。 この段階では、Tarantoolのすべてのスペースとすべてのオブジェクトに番号が付けられ、アクセスはオブジェクトの番号によって行われます。 インデックス番号、スペース番号などがあります。 次のスライドでは、接続が確立された後、タプルが挿入され、タプルが主キーによってアクセスされ、PHPの場合は単純な配列の形式でデータが返される様子を確認します。 キーによって、希望のスペースでタプルを更新することもできます。





タプルを選択する場合、リクエストが行われるキー番号を選択します。これは、番号0の主キーまたは他のキーです。





機能の一般的な概要を説明したので、おそらく既に使用した他のNoSQLシステムとの違いに移りたいと思います。



パフォーマンスから始めます。 一般に、これはRAM内のデータストレージであるため、パフォーマンスは最初、たとえばMySQLなどの従来のDBMSのパフォーマンスよりも大幅に高くなります。 複数の接続には非同期I / Oと非同期サポートを使用します。 10,000の活性化合物を簡単に保持できます。 先読みログにすべての変更を書き込んでいるという事実にもかかわらず、1台のマシンでのパフォーマンス。 すべての変更をディスクに記録すると、1秒あたり100,000のUPDATEとINSERTに達します。 このマシンでの読み取り要求については、1秒あたり260,000 SELECTのパフォーマンスを達成しました。 これらはそのようなスーパーディジットではありません。MemcacheまたはRedisのパフォーマンスに匹敵します。

そして、何のレイテンシ？ 応答遅延はいくらですか？

質問はとても良いです。



スライドが参照するベンチマークは10個のスレッドで作成され、各スレッドは一度に10個のリクエストを送信しました。 ベンチマークは、クライアント側が複数の要求をバッチで受信し、応答を並行して送信するように構築されました。 サーバーがパケットを送信するとすぐに、クライアントはパケットを読み取りました。 なぜこのようなパフォーマンス測定スキームを選択したのですか？ Tarantoolをロードするためには、まだ100台以上のクラスターが必要ですが、自由に使える車は2台しかなかったためです。 パフォーマンスを測定するこのアプローチでは、遅延はもちろん、実際の負荷で観察できるものよりも高くなります。 実際、単一のリクエストクエリの実行時間は、データを変更するかどうかに大きく依存します。 SELECTの遅延は最小限です。サーバーはキーからメモリからデータを読み取り、クライアントに送信するだけで、ロックはありません。



一般的に、Tarantoolはロックフリーシステムであり、データ構造とキャッシュのレベルですべてのデータへのアクセスは順次実行されますが、ネットワークレベルでは、多くの接続の並列処理がサポートされます。 このアプローチを実装するために、いわゆる「コルーチン」を使用します。これは、「ライト」または「グリーン」ストリームとも呼ばれます。





要求がデータを変更する場合、変更はディスクに記録する必要があります。 バッチ書き込みを実装するには、深刻なDBMSで「グループコミット」と呼ばれるアルゴリズムが使用されます。つまり、いくつかの蓄積された変更を同時にディスクに書き込みます。 フロントエンドとバックエンドの2つの駅を結ぶ列車として想像するのが最も簡単です。 ディスクに記録する必要があるすべての要求は、ネットワーク（フロントエンド）の操作を担当するプロセスのプラットフォームに蓄積されます。 次に、これらの要求はすべて「トレインに浸漬」されます。つまり、バッファリングされてディスクに書き込まれます。 1つのクエリグループがディスクに書き込まれるとすぐに、「トレイン」が次のクエリグループに戻ります。 したがって、INSERT / UPDATE / DELETE要求の実行の遅延は、プラットフォームを使用している瞬間に依存します。 最新の機器の最大値は0.01秒で、ハードディスクの任意のシリンダーの任意のブロックの記録時間です。

どのファイルシステムを使用していますか？

任意のファイルシステムを使用します。 Linuxなど、この特定のZFSでZFSを実行している場合は、お願いします。 この場合、POSIX APIを使用してファイルを操作します。 私たちが使用する唯一の非POSIX呼び出しはfallocate（）の呼び出しです。これは、私の意見では、JFS、XFS、およびEXT4でサポートされています。





なぜfallocate（）を使用するのですか？ これは、最新のファイルシステムの仕組みによるものです。 これについて詳しく説明する必要があります。後で説明します。

クライアントに関するより具体的な質問は、1つの場所から1つのクライアントから、同じキーの1000個のGETに同時にアクセスする方法です。 どういうわけか、このビジネスをプロキシできますか？ に1000リクエストを送信しないでください...

GETはどのように機能し、プロキシすることはできますか？ Tarantoolにはクライアントプロトコルがあります。 たとえば、Memcacheはテキストおよびバイナリプロトコルをサポートしています。 同様の方法で行いました。 バイナリプロトコルは主に、GETがコマンドの1つである場合に使用されます。 コマンドコードは要求パケットヘッダーで4バイトを使用し、ヘッダー全体は12バイトを使用します。 ヘッダーの2番目の4バイトには、リクエストIDが含まれています。 リクエストIDは、特定のリクエストを一意に識別するマーキングの手段です。 リクエストへの応答として、サーバーは渡されたリクエストIDを返します。 これにより、リクエストを非常に簡単にプロキシでき、Mail.Ru Groupで積極的に使用されます。 プロキシは数十のマシンから数十のマシンからリクエストを受信し、それらをTarantoolに送信します。その後、request-idによってリクエストの送信元マシンを特定し、このマシンにTarantoolの応答を送信します。

commit, ?

, . . group commit, . wal_fsync_delay — 0.01 . , Linux. Tarantool, MySQL. , , NUMA- MySQL, . — . , - Mail.Ru wal_fsync_delay 0.01 , .

Tarantool?

はい、あります。 .

, Tarantool MySQL?

. , Tarantool, MySQL, Mail.Ru Group, . MySQL, .

. . , GET, , 700 . . , .







SET' . , (Intel Core I7, 7200 ), 300 000 700 000 .





, . 1.5 1.4. UPDATE's. , UPDATE'. .









, , , . Tarantool Key-Value, Trantool , .





auto-increment. PHP, NoSQL Tarantool, - -. UPDATE, , , . , . -, , , . .













Tarantool, . , , — .. space 0. , . , — , .





, , . , Tarantool .



« = tuple ()». なぜなら , . : № 0 — , № 1 — , .. . № 2 , , , , . , . , . top bottom, UPDATE , box.update() — , callback . , UPDATE , , , printf(). , , =p=p=p, '=' () 1 'p' ( ) top, '=' () 2 'p' ( ) bottom, '=' () top val.









UPDATE, , , , , . , . .









, , Lua. , Lua . Javascript…





. , LuaJIT — just-in-time compiler, open source . — . Lua , , , - . , GitHub Tarantool, .





, , , - — ?

, -, - . , , 2 2 max+1.

, . , . Tarantool . ? , , WAL. 1 Tarantool 1 . , fiber', coroutines - , -. , ; , , , multi-threaded , . ? nodes, Tarantool. 2-4 . Tarantool — shared nothing MPI . .



? Mail.Ru Group.



- , , . , , , , . つまり , . — Memcache, Memcache- Memcache expiry — , , , , Lua. Mail.Ru. 4 , 2 Tarantool'. 2 , 2 . 60 100 , Mail.Ru .





, , , Tarantool , Tarantool , , , . , . , , , . - , 400 , . , . Tarantool 120 , , . , 2 , 60 . production , , . , , 20%.

. MongoDB. Mongo , . , . , ..

Mongo ? Mongo — , c Write Ahead Log', ?

, .

, Tarantool . Tarantool snapshot', . , , . copy-on-write, Redis. Write Ahead Log. , Write Ahead Log'. , 0.01 .

MySQL , , , . Tarantool ?

. Tarantool, , MSQL? MSQL , Write Ahead Log, , .. MSQL . Tarantool Write Ahead Log — . : Write Ahead Log . , , , . Write Ahead Log (log sequence number, LSN), , , , .

— , : 5, 8. , , , , . ?

, . , . , .







, — , .



, 6, 83, 1, 21, 8 .. : « 44 , 83 ». ? : , , friend-requests .. 5. . 30 friend-requests, 20, .. 20. .



Tarantool. 5 . 2 , — « ». Tarantool , . , , , . , SQL- ? .



— « ». , , , . .



, .



notification_push() . — user_id, . MySQL, , MySQL, .



notification id . .

GitHub.



notification_push(). unread count, UPDATE . .







. , Tarantool — , , . , -, , , , . , , CAP-.







Tarantool, , Voldemort, Riak, , . , 100 — , Mail.Ru, , 4, 6 , .. . , .



, , , , --, . : . ありがとう

---

このテキストは、Infospace Centerで11月16日に開催されたMail.Ru Technology Forum 2011での Konstantin Osipovによるレポートの転写です。ビデオレポートテキストを作成するための技術の詳細については、こちらをご覧ください：Mail.Ruテクノロジーフォーラムの裏側：ハイテクイベント管理。他のレポートのビデオバージョン（モバイルデバイス用のバージョンを含む）は、フォーラムWebサイトtechforum.mail.ruで入手できます。レポートのテキスト版は、ここおよびフォーラムのWebサイトで毎週またはほとんど同じ頻度で発行されます。テキストのタイプミスについてPMでお知らせください。