Webアプリケーションのパフォーマンス・チューニングの勘所 / web tuningperformance
# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-application-tuning-guildline - https://speakerdeck.com/soudai/basic-of-rdb - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726 - https://fortee.jp/phperkaigi-2021/proposal/1d
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
トランザクション分離レベルのケースと対応方法 - Carpe Diem
背景 トランザクションの分離レベルで出てくる用語がぱっと頭に浮かぶよう、問題が発生するケースと対応方法をまとめます。 起きうる問題 基本的にどのDBも単一オブジェクトの原子性と分離性は保証します。 つまりデータ送信の途中でネットワーク接続が切れたら断片のみ保存するのではなく、全て破棄します。 また同時に更新処理があったとしてもデータを混ぜて保存するといったことはありません。 （{id: 1, name: alice},{id: 1, name: bob}があったとして{id: 1, name: aliob}にはならない） 分離性で問題になるケースは主に複数のオブジェクトを並行で同時に操作する際に起きます。 ダーティリード あるクライアントが他のクライアントのコミット前の書き込みを読み込むことです。 この例ではBobは新規メールがあるにも関わらず、未読件数は0のままです。 対応策 Read
2020年版 モダンアプリケーションでのDB選定 | DevelopersIO
目的別データベース選定 それぞれのDBの特徴や特性を軽く紹介していきます。 リレーショナル（Amazon Aurora） RDSに管理されるMySQL/PostgreSQL互換のRDBです。 RDSのMySQL/PostgreSQLと比較したAuroraのメリット 対障害性 並列クエリ Global Database パフォーマンス: MySQLの最大5倍, PostgreSQLの最大3倍高速 RDSでは特段理由がなければ、Auroraを選択することになるかと思います。 適しているユースケース ERP CRM 財務・銀行 SaaS(マルチテナントアプリケーション) 構成要素 DBCluster DBInstance プライマリインスタンス(Writer)（書き込み/読み込み） Auroraレプリカ(Reader) エンドポイント クラスターエンドポイント 読み取りエンドポイント カスタムエ
フレームワークは素晴らしいけど抽象化した箇所は忘れないでねって話をします - そーだいなるらくがき帳
Laravelカンファレンスでの登壇資料です。 conference2019.laravel.jp ガッツリ、データベースの話とかPerformanceの話でロックとか内部構造の話してもいいかなって思ったけどLaravelのカンファレンスなので表題の事をテーマに資料を作りました。 この辺の話は知ってる人からすると知ってる話なので先に資料を見てから話を聴くSession決めるのがオススメです。 内容自体はフレームワークを使ってたらハマりがちなRDBMSのボトルネックについてざっくりまとめました。 30分で話するにはテーマが大きいのでこのセッションで気になることとか、その他知りたいことがあれば当日気軽にご質問ください。 Ask the Speakerでも良いし、ロビーで普通に話掛けていただいてもいいし、Twitterでも構いません。 JOINのアルゴリズムは id:ikkitang1211 の
UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
N+1問題におけるORMの重たさについて - Atsuo Ishimoto's blog
SQLで木と階層構造のデータを扱う――入れ子集合モデル