最強のレイテンシを実現するIOデバイスの秘密とは
引用元：https://news.ycombinator.com/item?id=43355031
ブログの作者です。この記事を書くのが楽しかった。今までで一番複雑な記事で、インタラクティブなビジュアルのために数千行のjsを書いたよ。みんな楽しんでくれるといいな。
アニメーションが素晴らしくて、インタラクティブな部分もすごい！例えとしてHDDとSSDのレイテンシの違いを視覚化するのが分かりやすくて、仕事で説明することが多いから助かる。すごい作品だね。
ありがとう！ビジュアルがこの投稿に特別な要素を加えていると思う。時間がレイテンシ説明の重要な要素だからね。
視覚重視の人々のために技術的な娯楽とブランド構築へのマーケティング予算投資にリーダーシップをありがとう！
ビジュアルが素晴らしい；バウンスボックスはレイテンシの相対的な例えとして今まで見た中で一番いいと思う。あなたの”1 in a million”の耐久性についての意見は、ダウンタイムの短さを考慮すると悲観的すぎるんじゃない？例えば、回復が10分だとしたら、3つのサーバーが月に1回ずつ故障する保証があったら、実際には200万分の1じゃないかな。顧客が100万人いるときに1 in a millionは良くないよね！
＞あなたの”1 in a million”の耐久性についての意見は、ダウンタイムの短さを考慮すると悲観的すぎるんじゃない？もちろん。本当の耐久性はこれより遥かに高い。誰もデータを失う心配をする必要がないっていう安心感を提供しているんだ。
＞一つのサーバーにすべてのデータを保存するのではなく、いくつかのコンピュータにレプリケートすることができる。一般的にはプライマリサーバーがすべての書き込みリクエストを受け取り、そのデータが2つ以上の追加サーバーにレプリケートされるという方法がある。この三つの場所にデータがあれば、データを失う可能性が非常に小さくなるってことだよね。私の理解は合ってる？
PlanetScale Metalでは半非同期レプリケーションを使っていて、プライマリがコミットする前に少なくとも1つのレプリカからACKを受け取る必要があるよ。
あの…やっぱりネットワークホップがあるってこと？
書き込みの場合はそうだけど、ワークロードが90%リードだったらどうなるの？
確かに読み込みが多いワークロードにはすごく合ってるね！もっと裏で何が起きてるか理解したくてさ。
リクエストを受け取った時にAckは送られるの？それともリモートのディスクに保存された時？
これを作った人に感謝だね！ちょっと脱線だけど、これを使った教材は中高生にリアルな学びを提供できると思う。
これが高校のカリキュラムで使われたらすごくいいね。
サーバー3台が1ヶ月でダウンする確率は百万分の1だって。失敗したノードをすぐに交換すれば、リスクは大きく下がる。計算は合ってるかもだけど、30分の間に全滅する確率は213,160,000分の1になるんだ。
でも、失敗は独立で無関係だと仮定してる点が気になる。実際には、失敗が相関していることは多いから、リスクがより高くなるかも。
その通りだね。サーバーの場所によってかなり影響される。失敗が無関係だって見積もりは簡単だけどさ。
努力のレベルがすごく伝わってくるよ。どれくらいの時間を費やしたと思う？キーボードでの時間と頭の中で考える時間は全然違うよね。
ありがとう！去年の10月から始めて、他のこともやってきたけど、これには200時間以上かけたね。参考までに、合併用のgit diffは＋5,820、−1だよ。
半分オンテーマだけど、アニメーションに使ったライブラリは何？ソースページからはすぐに分からないから。コンテンツについては十分に分かってるから、特に意見はないけどさ。
d3.jsをめっちゃ使って作ったよ。 小ネタだけど、MacOSのChrome 133.0.6943.142では見れなかった。Firefoxでは問題なし。 こっちはFirefoxでアニメーションが無いけど、Braveではちゃんと表示される。ブラウザコンソールがこちらのリンクをバンバン出してる：＜https://react.dev/errors/418?invariant=418＞。追記：どうやらユーザースタイルの拡張機能が原因みたい。Reactがそれを嫌ってページが壊れちゃう。 おお、興味深い！理想的ではないけど、拡張機能の問題なんだね。 面白いね。何かブラウザの拡張が影響してるかも？コンソールのエラーも教えて。 やっぱりそうだった！拡張機能を一つずつ無効にしていったらreflect.appの拡張だと判明。編集：彼らのDiscordに報告したよ。大丈夫だった！素晴らしい作品だね！ こういうデータビジュアライゼーションが大好き。スケールの比較を内面化するのが苦手だけど、視覚化で直感がかなり掴めるよ。素晴らしい仕事、ありがとう！ 時間要素がある分、視覚が特に重要だと思う。いい感じだね。 あなたのテープ操作モデルを見て嬉しかった。COBOL時代にかなり使ってた。記事の理由で、シーケンシャルスキャンを最大限に使おうとしたけど、COBOLはそれが得意だった。処理速度の遅さとドライブヘッドからくるブロックの流れにギャップがあると、ドライブがオーバーシュートしちゃって、追いつけなくなる。コードを見直して修正してた。 Bartosz Ciechanowskiの影響を受けてる？最初に思ったのは、彼がこの投稿のビジュアルを担当したのかと思ったよ。 素晴らしいプレゼンテーションだね。概念を理解するのに役立つよ。ただ、SSDの並列処理の影響が少し過小評価されてる気がする。ハイエンドのデバイスでは8チャンネルコントローラーが一般的で、4KランダムIOPSはキューの深さとともにスケールするんだけど、入門としてはこの例で十分かも。PlanetScaleがこの方向に進んで知識を共有してるのを見るのはいいね。 情報ありがとう！もっと学びたい人のために、参考になる資料とかあれば教えてほしいな。 EC2でローカルのNVMeが付いてるメタルインスタンスって実際に何なの？最小の遅いGravitonを除いて、AWSでベアメタルインスタンスを取得するには月に約2.3k USDかかるって前に見たけど。 視覚化が素晴らしいね。見たり遊んだりするのが楽しくて、記事ととても合ってる。これを誇りに思っていいよ、すごく楽しめた。 Safariではアニメーションが見えないんだ。可変幅のフォントが好みだし、モノスペースの文章は読みづらい。それにReader Modeを使うとテキストの色付けが消えちゃうし、視覚効果も隠れちゃうかも。 面白いね！何かエラーが報告できることある？Safariでも動くはずだけど、カスタム設定があるのか、古いバージョンを使ってるのかな？ AndroidのChromeを使ってるけど、AdGuardがあなたの視覚化を全部ブロックしてるよ、FYI。 視覚化が一つも見当たらないんだ。JavaScriptを使わずにウェブを使ってるから、静的な画像を埋め込むか追加してはどうかな？ 視覚化がこの記事にとても貢献してるね。全体のテーマはレイテンシーで、視覚化によってテープがHDDより遅く、HDDがSSDより遅い理由がわかりやすくなるし、楽しいよ。最近はJavaScriptなしで、何をしてるの？ ＞”最近はJavaScriptなしで、何をしてるの？” SQLite+NVMeの組み合わせを推してるんだけど、これでいつも通りよりもトラブルに深くハマれるかもしれないんだ。場合によっては、水平スケールせずに解決できちゃうかも。レイテンシはパフォーマンスの王様だし、特にアイテムをシリアルに処理しなきゃいけないケースではね。SQLiteをNVMeで動かせば他にはないレイテンシの利点が得られると思う。実際の使い方では、メモリ上で動かすよりもNVMeの方が大きな効果があるとは思えない。 SQLiteを選ぶ理由って何だろう？Postgresみたいな従来型のクライアントサーバーDBの方がいいんじゃない？単一ホストなら少し早いかもしれないけど、2台のWebサーバーがあったらお互いにDBに書き込むのが大変になるし。＞“レイテンシはパフォーマンスの王様だ”ってのはちょっと誤解を招くかな。まず、一貫性がないとパフォーマンスは意味がないし、複数のWebサーバーがあるとその問題が出てくる。 SQLiteのシングルライター制限に当たるまでは、Postgresにより多くのCPUサイクルを使う必要はないよ。 その制限は、特にリードオンリーなSQLiteやセッションごとに一つのSQLiteに計画を立ててない場合、すぐに直面することになるよ。 うーん、想像つかないな。ほとんどのCRUDアプリはOLTPでリードオンリーなんじゃないかな。普通のCRUDアプリでSQLiteをぎりぎりまで使うには、数千の同時ユーザーが必要になる気がする。 ほとんどの企業のOLAP処理ではその制限には達しないと思うよ。ほとんどがリードオンリーのSQLiteだからね。書き込みは通常、バッチ処理されてて、業務外に実行されるからSQLiteの制限は関係ないんだ。 バッチ処理はどこでやってるの？ DuckDBの信者が操ってる別のシステムだよ。 必要になる可能性が高いなら、最初からPostgresを選んだ方がいいと思うよ。SQLiteから後で切り替えるのは手間だからね。小さなトラフィックなら、ウェブアプリと同じホストで動かすのは簡単だし、Unix認証ならパスワードも管理いらないし。複数のライターが必要になった時に、DBクエリを全部書き直す必要はないよ。 全体の目的はネットワークの遅延を避けることなんだ。アプリケーション <-> SQLite <-> NVMeは、アプリケーション <-> Postgresクライアント <-> ネットワーク <-> Postgresサーバー <-> NVMeよりも桁違いにレイテンシが少ない。＞“できるだけシリアルなDBクエリを避けるべき”っていうのは、その決定権は俺にはないんだ。ビジネス側が決めるから。 Postgresは同じマシンでUnixソケットをサポートしてるよ。そのおかげで127.0.0.1のTCPスタックよりレイテンシが大幅に改善されるんだ。 ”…は桁違いにレイテンシが少ない…”って本当？ローカルネットワークアクセスはローカルIPCと大差ないはずだよ。 ＞ローカルネットワークアクセス MySQLやPostgres、DB2、Oracleなどがアプリケーションと同じマシンで動くプロダクションシナリオってどんなの？ほとんどのベンダーはそうするなって言うと思う。 95％のウェブサイトがAmazonやGoogleじゃないの？小さなVMで運営されているサイトはたくさんあるよ。Postgresは512MBの環境でも快適に動くからね。 SQLiteをローカルで使うなら、Postgresもローカルで使うのは全然ありだよ。シャーディングの問題も解決済みなんだからさ。 ＞私はほとんどのベンダーがそうするなって言うと思う それは違うよ。Apacheが動いてる同じホストにPostgresやMySQLを置くのは、新しく始めるサイトでは非常に一般的だから。512MBのインスタンスでも問題なく動くし、SSDでもかなりのトラフィックに耐えられる。人気が出たら、次はデータベースを別サーバーに分けるけど、その理由は複数のウェブサーバーが必要になるから。データベースは思ってるほど重くないよ。 コンテクストスイッチとmmapアクセスは、しばしばmmapアクセスより遅くなることがあるよ。 SQLiteにはIPCが無いんじゃない？ 複数のプロセスから同じデータベースにアクセスすればIPCはあるよ。 SQLiteの同時アクセス時のIPCメカニズムについて、ファイルロックやOSが確保する原子的なIO操作以外に何かあるの？ 過去にテストしたけど、PostgresはローカルネットワークよりUnixソケットの方が明らかに速いよ。 “データベースのレイテンシは一般的にインターネットの往復レイテンシに比べて微小”って言ったんだけど、ユーザーとウェブサイトの間を指してるの。だから、ローカルネットワークのホップで注文のあるレイテンシにはならないよ。記事でもデータセンター内の往復で5倍遅いって言ってるし、データベースがクエリ実行する時間に比べれば大したことない。それに最適化しすぎるのは時期尚早な例だよ。 SQLiteはプロセス内で動かせるけど、プロセスコンテキストスイッチでレイテンシと帯域幅が10倍悪化することもある。n＋1秒とかで開発時間が節約できることもあるよ。 ＞レイテンシと帯域幅が10倍悪化することもある。そんなことはないよ。帯域幅に関する主張が意味を持たない。速度差は1％か5％の話であって、10倍じゃない。 絶対に悪化するよ。同じコアでのコンテキストスイッチは数マイクロ秒だけど、コア間を超えると数十から数百マイクロ秒かかることもある。 数百マイクロ秒とかL1アクセスって何言ってるの？プロセス間の通信は、クエリ実行に必要なディスクやSSDのアクセスと処理に比べると無視できるレベルだよ。SQLiteがプロセス内で動くのはシンプルさと便利さのためだし、パフォーマンスが悪化することもある。 Postgresを同じサーバーで使うならIPCのオーバーヘッドについて、自分の直感と永続的なプロセスからの節約を天秤にかけて考えてみて。SQLiteは取引の間に別のプロセスがデータベースを完全に変えちゃうから、あまりキャッシュできない。Postgresはデータベースの全てを知ってるよ。 SQLiteは書き込みの並列性があまり得意じゃない。サポートはしてるけど、ちょっと扱いづらくて失敗することも。特定のモードを使う以外にも、アプリで書き込み用のスレッドを一つにしておくトリックが有効。 ＞書き込み用のスレッドが一つだけで問題ないなら、SQLiteは絶対に優れている。コマンドをマイクロ秒単位で処理することが目的なんだから、書き込みは一つで済むのが理想だよ。金融取引所もこの前提で運営されてる。 金融取引所が永続データストアに対してシングルスレッドの書き込みを行ってるなんて信じられない。もしそうだと証明できるリンクがあれば教えてほしい。 ＞https://www.infoq.com/presentations/LMAX/ 記事のソースとしてのリンクだね。 それは金融取引所じゃなくてスポーツベッティングや経費管理システムだよ。データセンターは特別なハードウェアを使ってるから、sqliteがその裏で動いてるとは思えない。オーダーマッチングはシングルスレッドだし、電子取引システムの実装について知ってる人がいたら知りたいな。 デスクトップでNVMeディスクを使ってfsync()をやったら1〜2msのレイテンシを測定した。最新のシステムだと約800usだよ。 あんまりそうは思わないな。これはWD 850X Gen4 SSDでのfio randwriteワークロードの結果だよ。 O_DIRECTを使ったら逆に大きな違いに気づかされた。ありがとう！ ランダム書き込みとfsyncは同じじゃない。消費者向けSSDの連続書き込みは耐久性がないからすごく速いよ。 これはどのドライブで、トリムが必要か？ NVMeデバイスは、特に消費者向けでは品質に差があるんだ。僕の前の仕事では、こういったレイテンシを持つドライブはアウトだったよ。 今使ってるのはSAMSUNG MZVL21T0HCLR-00BH1で新しい仕事用ラップトップに搭載されてる。250us下回ることができない。前のWD_BLACK SN850XはM.1スロットに接続されてたけど遅かったかも。今のエンタープライズハードウェアの性能についての情報を探してるんだけど、いい情報源が見つからない。 NVMeはただのプロトコルだよ。ゴミのようなドライブから高級車並みの価格のものまでいろんなのがある。結局、DRAMのレイテンシには及ばないけどね。 この内容、めっちゃ役立ったし、商品を宣伝してるとは忘れちゃうくらいだよね！グラフィックやインタラクティブな部分も素晴らしかった。もっとコメントを表示（1）
ウェブを閲覧したり、メールの送受信をしたり、ストーリーを読んだり、ゲームをしたり、普通のことをしてるよ。主にネイティブアプリを使って、JavaScriptを使うサイトを選んでるんだ。もっとコメントを表示（2）
もっとコメントを表示（3）
