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
SQLの実行計画の読み方 |
今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。 実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。 表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。（このため A5:SQL Mk-2でもツリービューで実行計画を表示します。） ツリーのリーフ（端）から処理が行われ、ルート（根）に向かっ
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
Azure でのミッション クリティカルなワークロードに関するデータ プラットフォームに関する考慮事項 - Microsoft Azure Well-Architected Framework
効果的なアプリケーション データ プラットフォームの選択は、他の設計領域に広範囲に及ぶ影響を及ぼす、さらに重要な決定領域です。 最終的に Azure には、多数のリレーショナル、非リレーショナル、分析データ プラットフォームが用意されており、機能が大きく異なります。 そのため、重要な非機能要件を、一貫性、操作性、コスト、複雑さなどの他の意思決定要因と共に完全に考慮することが不可欠です。 たとえば、複数リージョンの書き込み構成で動作する機能は、グローバルに利用可能なプラットフォームの適合性に重大な影響を及ぼします。 この設計領域では 、アプリケーションの設計が拡張され、最適なデータ プラットフォームの選択を通知するための重要な考慮事項と推奨事項が提供されます。 ビッグ データの 4 対 "Four Vs of Big Data" は、高可用性データ プラットフォームの必要な特性と、データを使
Overview of Serialization Technologies
Overview of Serialization Technologies Jim Pivarski Princeton University – DIANA-HEP March 28, 2018 1 / 24 45 years of serialization formats in (and out of) HEP 1970 1980 1990 2000 2010 2020 ZEBRA (1983) YBOS (CDF r1) ZOO proposal (1994) Objectivity (c.1994‒1998) HYDRA (1973) ZBOOK (1974) BOS (1975) ROOT (1995) CWN in PAW (1989) FORTRAN C++ MonetDB (2002) C-Store (2005) Dremel (2010) Parquet (2013
【レポート】パフォーマンスチューニングの強い味方！Aurora PostgreSQL Performance Insightsのご紹介 #AWSSummit | DevelopersIO
DA事業本部の春田です。 AWS Summit Online絶賛開催中！ということで、本記事では「Architecting and Building - 突然データベースのパフォーマンスが悪化、あなたならどうする？【前半】」の内容についてまとめていきます。 セッション情報 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 内山 義夫 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 新久保 浩二 ある日突然データベースのパフォーマンスが悪化した際に皆さんはどのように対処しますか? また、突然悪化させないためにどのような運用をしていますか? 本セッションでは過去から現在にいたるまでデータベースでどのようなワークロードの状況だったかを捕捉し、パフォーマンス悪化の状況や原因を分析します。また、日々の運用でパフォーマンスを
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
[misc.] Tech Deep Dive #0
Oracle Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します（オリジナルのエントリを投稿することもあります）。厳密性をご所望の方は原文をどうぞ。よい内容でしたら原文に対し、"Good Entry, thanks!"でもいいので、是非コメントお願いします（Typoや誤訳はコメント欄からどうぞ）。なお、このエントリは個人の見解であり、所属する会社の公式見解ではありません。また、エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。 Good entries on Oracle Blogs are put into Japanese. Mainly this blog covers technology products. Opinions expressed in this blog is my personal one and d
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
ISUCONで学ぶ Webアプリケーションのパフォーマンス向上のコツ 実践編 完全版
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi
1 Aerospike server X 1 Amazon EC2 instance = 1 Million TPS for just $1.68/hour - High Scalability -
** DI = On Demand Instances ** RI = Reserved Instances ** All cost analysis is for a single instance of the given type. For Reserved Instances, the 1 year and 3 year terms have been calculated with heavy utilization (100% utilization). NB: These instances sometimes show better or worse performance. These numbers are based on typical results seen over many runs over a month. * Core Bottleneck : We
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Parquet, Avro or ORC?
Comparison of different file formats in Big Data
TPC-Homepage