Numbers Everyone Should Know #17
Conversation
|
|
||
| | 操作 | ns | μs | ms | 補足 | | ||
| | --- | --- | --- | --- | --- | | ||
| | 通常のCPU命令 | 1 ns | | | | |
There was a problem hiding this comment.
| | ms | $10^{-3}$ | | ||
| | μs | $10^{-6}$ | | ||
| | ns | $10^{-9}$ | | ||
| | ps | $10^{-12}$ | |
There was a problem hiding this comment.
この続きは、フェムト、アトです。私は、もともとレーザー屋だったので、フェムト秒、アト秒には馴染があります。
フェムト秒はだいたい可視光の振動周期で、化学反応や振動などが100フェムト秒前後でおきる感覚ですね。
| | --- | --- | --- | | ||
| | C/C++ | 1 | 1～10億ステップ/s | | ||
| | Go, Java, C# | 3 | | | ||
| | Python | 50~100 | | |
There was a problem hiding this comment.
|
|
||
| | 型（C/C++） | バイト | | ||
| | --- | --- | | ||
| | bool | 1 B | |
| | 型（C/C++） | バイト | | ||
| | --- | --- | | ||
| | bool | 1 B | | ||
| | char | 1 B | |
| | long long | 8 B | | ||
| | float | 4 B | | ||
| | double | 8 B | | ||
|
|
There was a problem hiding this comment.
C++ の話をしているとすると、サイズは何ビット最低あるか、くらいしか決まっていません。
https://stackoverflow.com/questions/589575/what-does-the-c-standard-say-about-the-size-of-int-long
|
|
||
| - Webページの表示速度は数msが望ましく、2~3秒が限界 | ||
| - １台のWebサーバーの最大同時接続数は200~1000ぐらい | ||
| - １台のDBサーバーで扱えるレコード数は数十万ぐらい、100万レコードを超えてくると厳しくなる |
There was a problem hiding this comment.
これの出典・カウント方法はどのようなものでしょうか？
DBサーバーのスペックにもよりますが、1レコードにつき1kBぐらいであれば素で保存するとしても1GBぐらいで、100万レコードぐらいは（すごく頻繁に登録更新があるとかでなければ）特に問題ないと思います。
シンプルなテーブルであれば、普通のPCぐらいの性能でも千万レコードを超えてもあまり不自由なく扱えますが、インデックスを貼ってないカラムで検索やソートしたりすると、めちゃくちゃ時間がかかったり、初期設定だとメモリ不足でエラーになったり、という事はあります。
OLAPとかだと、1台のDBで億を超えるレコードを扱うことも割とあると思います。スペックではない台数で語るのがナンセンスかもですが...
There was a problem hiding this comment.
これを参照しました。読み違えているかもしれません（cc @oda ）
https://discord.com/channels/1084280443945353267/1084283898617417748/1226569567476912190
There was a problem hiding this comment.
これは、MySQL を何も考えずに使っているときの(ウェブサーバーと同じマシンで同居くらいの)条件で、このあたりから運用方法を考え始める、くらいの話です。
あと、私は、こういうの作っていたの昔なので、感覚小さめの数字をいうと思います。
There was a problem hiding this comment.
なるほど、そういうことですね。
私の感覚としては、主要なレコードの量が100万〜1000万の間ぐらいになってくると、素の状態で雑に使っているとだんだんと課題が出てきて、スケールさせることを考えるかなと思うので、そういう意味で「もう1桁2桁」というのは同じような感覚かなと思いました。
「1台のDBサーバーで扱えるレコード数が数十万ぐらい」というよりは、「Web・DB同居の1サーバーぐらいの構成だと100万〜1000万レコードぐらいで課題が出始めるので、必要ならスケールを考えはじめる」「数十万ぐらいまでは深く考えなくていい」みたいな事かもしれません。
（100万を超えたら厳しくなるのだ、と言われれば確かにそうかもしれませんが、元の文脈と微妙にニュアンスが違うような印象を受けました。オーダーの話として記されているか否かの違いですかね。。）
There was a problem hiding this comment.
1台で10万の桁までは扱えるが、もう1桁2桁上がってくると厳しいという感覚
そろそろ垂直にスケールさせたい
たしかに、これ日本語の読解として厳しいですね。
これくらいのところから、ORM が吐く SQL 文が気に食わないとか、クエリープランナーが妙なことしているなとか、暖機の時間が長いとか、書き方変えたり、DB を別サーバーにして強化したり、ちょっと考えないといけないようになるようなイメージです。
他の課題があったら挙げてくれるとありがたいです。> @sasanquaneuf
There was a problem hiding this comment.
そうですね、DBそのものについては、更新が多い場合にはPostgresだとVACUUMのパフォーマンスが気になってくるとか、他DBでもRedoログ/トランザクションログが肥大化したり切り捨てを調整したりとか、というような事があります。
MySQL等では、バッファプールに乗り切らなくなる（orスワッピングが発生する）などして、データ量の増加によって同じクエリがある日突然遅くなる場合もあります。
あと、数値と直接は関係ないんですが、このスケールを考慮するタイミングで、負荷をWebサーバーに寄せるかDBサーバーに寄せるか、みたいな設計戦略が変わってくる場合があります。
例えば同居サーバーの場合は同じリソースを分け合って使うので、単純に処理効率が良い方法を選ぶのが最適になります。このとき「データ量はそこそこあるがユーザー数は必ずしも多くない」みたいなケースでは、DBに寄せて処理した方が早くて楽なケースがそこそこあります。一方、WebとDBを分離すると、スケールさせやすいのがどちらかという事になるのですが、セッション管理等をちゃんとやればWebのスケールの方が楽になります。そうすると、なるべくDBの負荷を下げてWebに負荷を寄せる、というような戦略を取った方がよく、それによって実装方針が変わるケースもあります。
典型的な例としては、データの結合をWebサーバーでやるかDBでやるかとか、多少煩雑な集計をWebサーバーでやるかDBでやるかとかです。これはDB側でデータ転送量とCPU使用率のトレードオフがあったりするので、WebとDBのトレードオフだけではないのですが、それもこのぐらいのデータ規模から真剣に考えます。
※この辺は「書き方変えたり」に含まれるかもしれません。もちろん、やはりDBを増やせば十分なのでDBに寄せる、といった判断もあります。
|
|
||
| ## システムデザイン | ||
|
|
||
| - Webページの表示速度は数msが望ましく、2~3秒が限界 |
There was a problem hiding this comment.
表示速度の定義にもよりますが、数msというのは一般的にはかなり実現が難しいと思います。
Webのパフォーマンスチューニングの会社で、表示速度にこだわっているサイトでも、私の環境では静的コンテンツのキャッシュがある状態で0.1〜0.2秒ぐらいかかります。（末尾に表示速度があります）
https://spelldata.co.jp/
There was a problem hiding this comment.
https://developer.chrome.com/docs/lighthouse/performance/speed-index/
参考までに Google のおすすめはアクセスから描画が始まるまで1.8秒以内ですね。(ちょっとその限界値は小さそうです。)
| ## システムデザイン | ||
|
|
||
| - Webページの表示速度は数msが望ましく、2~3秒が限界 | ||
| - １台のWebサーバーの最大同時接続数は200~1000ぐらい |
There was a problem hiding this comment.
たとえばnginxのworker_connectionsのデフォルト値は1024で、ざっくりとは整合的だと思います。
https://github.com/nginx/nginx/blob/a4100450c067009158299ad69adb7d6f5e775943/conf/nginx.conf#L13
（ただし、動かしているサーバーのファイルディスクリプタの設定によっては、そちらに足を引っ張られます）
There was a problem hiding this comment.
もともと select の扱えるファイルディスクリプタの数の限界が FD_SETSIZE 1024までだったんですよね。(老人。)
|
Discordなどで散らばってた数値をまとめてみました。感覚とずれているものや追加した方が良い数値などがありましたら教えてください。