MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
Optimise PostgreSQL for fast testing
I am switching to PostgreSQL from SQLite for a typical Rails application. The problem is that running specs became slow with PG. On SQLite it took ~34 seconds, on PG it's ~76 seconds which is more than 2x slower. So now I want to apply some techniques to bring the performance of the specs on par with SQLite with no code modifications (ideally just by setting the connection options, which is probab
Axios 使うのやめたらビルドサイズが 10 KB 減って、なんか知らんがパフォーマンスも良くなった話
この記事について Zenn では長らく通信処理に Axios を使っていました。 しかし、Fetch API が多くのモダンブラウザなどで普通に使えるようになった今、使う必要性があまり無くなったため、Axios を使っている処理を全て Fetch API に置き換えることになりました。 この記事では、その置き換え作業をどう進めていったのか、その結果どう良くなったのかを解説していこうと思います 🗽 解説より置き換えた結果を知りたいのよ私は！！！ って方が居るかと思いますので、最初に置き換えたことで良くなった部分を紹介しようと思います。 まず一番良くなったところといえば、ずばりサイト全体のビルドサイズが 10 KB も減りました。( ちなみに、10 KB は圧縮時のサイズで、圧縮しない場合 100 KB になります 😇 ﾜｰｵ ) グローバルのビルドサイズが 103.35KB gzip 時
Largest Contentful Paint (LCP)
Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP) は、知覚される読み込み速度を測定するための重要なユーザーを中心とした指標です。これは、LCP がページの読み込みタイムラインにおいてページのメイン コンテンツが読み込まれたと思われる時点を示すためです。LCP を高速にすることで、そのページが便利であることをユーザーに強く印象付けることができるようになります。 歴史的に見ても、Web ページのメイン コンテンツがどの程度早く読み込まれ、ユーザーに対して表示されるかを測定することは Web 開発者にとっての大きな課題でした。 load や DOMContentLoaded のような古い指標は、ユーザーが画面上で見ているものとは必ずしも一致しないため、 適切ではありません。また、First Contentful Paint (視覚コンテンツの初期表示時間
詳解 システム・パフォーマンス 第2版
本書は、エンタープライズとクラウド環境を対象としたオペレーティングシステムとアプリケーションのパフォーマンス分析と向上について解説します。 主にLinuxベースのオペレーティングシステムに含まれるツールとその使用例を通じてシステムパフォーマンスを引き出す手法を説明します。システム評価のためのベンチマーク、キャパシティプランニング、ボトルネックの解消について解説しスケーラビリティを制限する要因を発見、分析し、解決する方法を学びます。 第2版では、perf、Ftrace、BPFの解説が加わり、Linuxとクラウドコンピューティングについての説明が充実しました。 システムのパフォーマンスを向上させ、コストを削減し、レイテンシの外れ値を減らすための方法を学ぶ本書はエンジニア必携の一冊です。 まえがき 1章 イントロダクション 1.1 システムパフォーマンス 1.2 職種 1.3 作業 1.4 分析
Goのnet/httpのkeep-aliveで気をつけること - Carpe Diem
概要 Idle connectionをプールするkeep-aliveの仕組みですが、Goで適切に使用するためにはいくつか注意があります。 環境 golang/go 1.13.1 TCP Keep-Aliveの挙動をパケットキャプチャで確認する 例えば以下のようにDefaultTransportの一部の設定（①、②）をイジってリクエストを送ると client = &http.Client{ Transport: &http.Transport{ DialContext: (&net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 10 * time.Second, // ① DualStack: true, }).DialContext, ForceAttemptHTTP2: true, MaxIdleConns: 100, IdleConnTim
500ms to 1.7ms In React: A Journey And A Checklist
Written by Oren Farhi, Front End Engineer Tech Lead, follow me on This article has been translated: Chinese 1 (by Qlly) Chinese 2 (by Qlly) Korean (by Ykss) I bet the need to tweak perfomance comes in a certain phase of development for every developer, in every app. There are very good resources and articles about how to tweak performance in react and this article is no exception. I thought I will
next.jsでのファイルチャンク最適化の一例 - hiroppy's site
今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書
Tuning Your PostgreSQL Server - PostgreSQL wiki
by Greg Smith, Robert Treat, and Christopher Browne PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system. Rather than get dragged into the details of everything you should eventually know (which you can find if you want it at the GUC Three Hour Tour), here we're going to sprint thr
Tuning Your PostgreSQL Server/ja - PostgreSQL wiki
作者 Greg Smith、Robert Treat、およびChristopher Browne PostgreSQLは性能よりも幅広い互換性を目的に設定された、基本設定で配布されています。 デフォルトのパラメータでは、使用中のシステムを過小評価してしまう可能性が高いです。 最終的に把握しなければならない項目のすべて（必要ならばGUC Three Hour Tourを参照してください）に引きずり込まれないように、ここで基本を簡単に紹介することでお助けしようと思います。 これらはPostgreSQLの初心者は気にしない、もっとも一般的なもののようです。 ここで紹介した概要を読んだ後により詳しく知りたければ、各節にてパラメータの名前をクリックしてください。 最新のPostgreSQLのマニュアルの関連文書にリンクしています。 さらにServer Configuration Tuningには、こ
Lighthouseの計測結果を見ていく - Qiita
Google Chrome 60からデベロッパーツールのAuditsタブからLighthouseが簡単に実行できるようになっているので使い方を見ていく。 Chrome89で日本語化されるので、この記事の内容とはだいぶ差異が出てきそう。 パフォーマンス測定に必須のLighthouseがChrome 89で日本語化される Chrome79から各評価項目の参照URLがだいぶ変わってしまっている。web.dev内のページに置き換わっているようだ。 Chrome 103からTimeSpan、Snapshotレポートが追加になり、ユーザーが操作した状態のページの分析も行うことが出来るようになりました。 DevTools の新機能 (Chrome 103) Lighthouseとは Lighthouseとはウェブページの品質改善の指針を「パフォーマンス」、「PWA」、「アクセシビリティ」、「ベストプラク
メルカリShopsのキャッシュ戦略
メルカリ Shops の開発 vcl, python, golang, containers, typescript, etc. が入っている monorepo で開発が行われている。 なので、あまり専門性はあってもどの領域でも開発を行う。 メルカリアプリ上で動いているため、 webview がベースとなりパフォーマンスは普段以上に求められている。 技術スタックはこちらを参照 ユーザーへの UX を下げないために。。 First Meaningful Paint を速くするSkeleton などでフィードバックを適切に行う => とりあえず速く結果を返却すればよい 結果を速く返すために考えること 共通な結果はすべてキャッシュし、CDN などを使い近くに置く極力、ユーザーからのアクセスを origin まで到達させない常に新鮮な結果を近くに保持することにより、上記を満たせるようにする =>
Macのdockerが遅いストレスから解放されよう - Qiita
Macのdocker遅い問題 Macで開発している時、主にRailsなのですがdockerを使うと遅くなるのが嫌でずっと避けてましたが、とあるプロジェクトでBFF構成にし開発環境とデプロイ環境をECS化したりとでdocker化の流れに抗えない状況になりました。 ただ、やはり遅い。 dockerが不慣れなこともありますが、Macのdockerなかなか遅い。 そしてMacが遅い件を調べてみてもみなさん困られるのが伺えます。 そんな中で対策としてよく見かけるのが docker-sync vagrantで別立て の2つでした。 どちらが最適なのかな？と思い悩んでると、 ありました。dockerのドキュメントにまさにこの件に対しての内容が。 ボリュームマウントのチューニング 端的にまとめるとv17.04からcachedとdelegatedというオプションが追加され、書き込み読み込みの一貫性を担保しな
Vue・React・Angularのパフォーマンス比較検証 - ICS MEDIA
ウェブのフロントエンド開発に役立つライブラリとして、VueとReact、Angularがよく取り上げられます。これらのライブラリは、SPA（シングルページアプリケーション）の開発に役立つ多くの機能を持っています。 フレームワークを選定するには、「人気だから使う」という短絡的な理由で選択をするのは望ましくありません。設計思想や機能の種類、学習コストなどの観点で、プロダクト・プロジェクトチームへの適性を検討するのがセオリーです。幸いにも、それぞれを比較した記事がウェブに数多くあり、選定のヒントを簡単に得ることができます。 一方、機能面の比較ばかりが取り上げられ、性能面で紹介されている記事が少ないように見受けられます。記事『サービスにおいて速さこそが神である｜深津 貴之』でも紹介されているように、昨今のウェブはスピードが求められる時代でもあり、ライブラリの性能評価の記事があってもよいのではないで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.reddit.com/r/PostgreSQL/comments/mi78aq/any_significant_performance_disadvantage_to_using/?rdt=61892
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
Running PostgreSQL in memory only
Core Web Vitals
MPA化するSPAとSPA化するMPA
Use Query insights to improve query performance | Cloud SQL for PostgreSQL | Google Cloud