タグ: #database

← すべての記事

• SQL実行計画完全ガイド: オプティマイザはどのように計画を選ぶのか

  PostgreSQL 18のプランナーの立場から実行計画を説明します。統計情報がどのように収集され、選択度がどう計算され、costの数値がどんな定数から組み立てられるのか、結合順序の探索がいつ遺伝的アルゴリズムに切り替わるのか、推定がずれたときに拡張統計でどう補正するのか、そして準備された文の一般計画(generic plan)がなぜ突然遅くなるのかまで、文書に記載された既定値とともに整理します。

  2026-08-15 · 32 分で読めます #database#postgresql#execution-plan#query-optimization#optimizer

• DB性能チューニング完全ガイド: パラメータを触る前に測定する順序

  PostgreSQL 18を基準に、性能チューニングをパラメータの一覧ではなく診断の順序として整理します。pgstatstatementsでワークロードをプロファイリングし、待機イベントでボトルネックの性質を切り分け、キャッシュとI/Oの指標を読み、そのあとでメモリ予算とチェックポイントとautovacuumを調整する順序です。PostgreSQL 18で変わった既定値と、変更前後を比較する方法まで扱います。

  2026-08-15 · 32 分で読めます #database#postgresql#performance-tuning#monitoring#operations

• データベースキャッシュ戦略完全ガイド:結局は無効化がすべてだ

  PostgreSQL 18を基準に、キャッシュをデータベース側から順に積み上げて整理します。sharedbuffersとOSキャッシュというすでに存在するキャッシュ層、マテリアライズドビューという計算キャッシュ、その上に外部キャッシュを載せるかどうかを判断する基準、そしてキャッシュ導入の本当の難所である無効化の4つの失敗モードと書き込みパスの順序問題、キャッシュスタンピード対策までを扱います。

  2026-08-15 · 32 分で読めます #database#postgresql#caching#performance-tuning#architecture

• トランザクション分離レベル 完全ガイド: データベースではなくアプリケーションが担う部分 ♪ 聞けます

  PostgreSQL 18の四つの分離レベルを文書どおりに整理したうえで、その上でアプリケーションが必ず実装すべきことを扱います。40001直列化失敗の再試行層、FOR UPDATEからFOR KEY SHAREまでの行ロックのはしごとSKIP LOCKEDキューパターン、アドバイザリーロック、長時間トランザクションがVACUUMを妨げる本当のコスト、そしてMySQL 8.4 InnoDBと異なる動作をする点を、実際のSQLとともに取り

  2026-08-15 · 33 分で読めます #database#postgresql#transaction#isolation-level#concurrency

• パーティショニングとシャーディング完全ガイド: 一つのノードの限界を超える順序

  PostgreSQL 18の宣言的パーティショニングを基準に、パーティショニングが実際に何を解決し何を解決しないかを整理したうえで、パーティショニングの限界からシャーディングへ移る判断基準を扱います。パーティションプルーニング、パーティションキーが一意制約に課す制限、パーティション数とプランナーコスト、無停止のパーティション運用、そしてシャーディングした瞬間に壊れるクロスシャードジョインとグローバル一意性の問題まで扱います。

  2026-08-15 · 32 分で読めます #database#postgresql#partitioning#sharding#scalability

• コネクションプール完全ガイド: プーリングモードがアプリケーションと結ぶ契約

  PostgreSQL 18とPgBouncerを基準に、コネクションプールを契約という観点から整理します。セッション・トランザクション・文プーリングの三つのモードがそれぞれ何を保証し何を諦めるのか、トランザクションプーリングでプリペアド文やSET、LISTEN/NOTIFY、アドバイザリーロックがなぜ壊れるのか、アプリケーションプールとPgBouncerとmaxconnectionsの間で三重の予算をどう配分するのか、そしてタイムアウト

  2026-08-15 · 27 分で読めます #database#postgresql#pgbouncer#connection-pool#operations

• 無停止スキーマ変更 完全ガイド: DDLが取るロック等級と安全な実行手順

  PostgreSQL 18の文書を基準に、各DDLが実際にどのロックを取るのかを等級別に整理します。八つのテーブルロックモードと衝突関係、ALTER TABLEの形態別ロック等級、テーブル再作成を引き起こす変更とそうでない変更、NOT VALIDとVALIDATE CONSTRAINTで制約を二段階に分ける方法、そしてlocktimeoutと再試行を組み合わせた安全な実行手順を扱います。

  2026-08-15 · 29 分で読めます #database#postgresql#schema-migration#zero-downtime#locking

• PostgreSQL インデックス完全ガイド: 設計から廃止までのインデックスのライフサイクル ♪ 聞けます

  PostgreSQL 18を基準に、インデックスを一つの運用資産として扱います。どのカラムをどの順序で入れるかを決める設計、六つのインデックス方式から一つを選ぶ判断、CONCURRENTLYで安全に作成する手順と失敗時の復旧、本当に使われているかを確かめる検証、膨張したインデックスを作り直す運用、そして元に戻せる形で廃止する方法まで、ライフサイクルの順序でまとめます。

  2026-08-15 · 33 分で読めます #database#postgresql#index#performance-tuning#operations

• データモデリング完全ガイド: 論理モデルからPostgreSQL物理モデルまで ♪ 聞けます

  PostgreSQL 18を基準に、論理モデルを物理スキーマへ移すときに下すべき決定を整理します。代理キーと識別子の型の選択、textとnumericとtimestamptzを選ぶ根拠、制約をコードとして扱う方法、jsonbを使う境界線、履歴と有効期間と論理削除の表現、正規化を崩すべき瞬間とその代償、そして列の並び順やTOASTといった物理配置まで文書の根拠とともに扱います。

  2026-08-15 · 35 分で読めます #database#postgresql#data-modeling#schema-design#constraints

• 大規模データ処理完全ガイド:COPY、チャンクバッチ、そして元に戻せる作業 ♪ 聞けます

  PostgreSQL 18で数億行を投入・更新・削除する作業を安全に行う方法をまとめます。COPYのオプションと既定値、ドキュメントが推奨する初期ロード手順、ONERRORで不良行を許容する方法、大量のUPDATEとDELETEをチャンクに分割する設計、削除後のデッドタプル処理とVACUUM FULLを避けるべき理由、そして再開可能なバックフィル作業を作る方法までを扱います。

  2026-08-15 · 33 分で読めます #database#postgresql#batch-processing#data-loading#operations

• データストアとキューの世代交代 — ライセンス、フォーク、そしてAtticへ行ったプロジェクト

  データ層で場所を譲った、あるいは配布条件が変わったプロジェクト10個を、公式発表とApache Atticの記録だけを根拠に整理します。Redis、Elasticsearch、MongoDBのライセンス変更とそこから生まれたValkey、OpenSearchのフォークを事実だけで扱い、KafkaからZooKeeperが外れた経緯、Apache Atticへ移管されたSqoop、Oozie、Giraph、Tajo、会社の終了後にLinux

  2026-08-12 · 17 分で読めます #open-source#database#kafka#redis#elasticsearch

• いま注目のオープンソース (3) インフラとデータベース

  データベースとインフラの領域は、ライセンス変更とフォークが勢力図を描き直した分野です。分析エンジン、組み込みデータベース、Postgres拡張、Kubernetesオペレーター、IaCまで、実際に定着したオープンソース11個を、スター数の順位ではなく解決する問題ごとにまとめて紹介します。何を代替するのか、どの程度成熟しているのか、いつ使ってはいけないのかも一緒に書きました。リポジトリのパスとライセンス、スター数、最近のプッシュは2026

  2026-08-12 · 8 分で読めます #open-source#database#infrastructure#postgresql#kubernetes

• 韓国の開発ブログ名文キュレーション 2 — 障害振り返りとトラブルシューティング、直接開いて確認した12本

  韓国の開発者がもっとも得意とするジャンルは障害の振り返りです。p6spyがDBルーティングを無力化した事件、HTTPタイムアウトがDNS解決を覆えなかった理由、TCPハーフクローズが重複例外に偽装された事例、MetalLBの設定ひとつが生んだクラスタの遅延スパイク、ヒープダンプでOOMを追跡した記録、JITウォームアップでデプロイ直後のCPUスパイクを抑えた過程、外部キーが招いたデッドロック、HikariCPのコネクション枯渇、MySQ

  2026-08-12 · 22 分で読めます #curation#큐레이션#troubleshooting#postmortem#incident

• 300倍はPostgreSQLをチューニングして出た数字ではない — 火山モデルとベクトル化実行

  pgrust 0.2のリリースとともに公開された300倍という数字を正確に解剖します。この数値はPostgreSQLの設定を変えて出たものではなく、Rustで新しく実装したデータベースをClickBenchで測定した結果であり、著者本人が別に提示したSUMクエリの実験は火山モデルの1.3秒からSIMDの135ミリ秒まで9.6倍を示します。バッチ、演算子融合、SIMDがそれぞれ何を取り除くのかをコードのレベルで追い、著者が自ら明かした限界

  2026-08-09 · 15 分で読めます #postgresql#database#performance#query-engine#simd

• SQL インジェクションとパラメータバインディング — ORM を使っても破られる箇所

  SQL インジェクション対策として最初に検索されるのはエスケープ関数ですが、正解はパラメータバインディングです。エスケープは値を文字列リテラルの中で安全にしようとする試みであり、バインディングは値が SQL テキストにそもそも入らないようにする構造的な分離だからです。この記事ではプリペアドステートメントがサーバー側で実際にどうパースされ実行されるのかをログで確認し、ORM を使っているのに破られる三つの箇所、そして ORDER BY や

  2026-07-26 · 25 分で読めます #security#sql#database#orm#python

• コネクションプールを大きくすると損をする理由 — 待ち行列をどこに立てるか

  コネクションプールを大きくしたらかえって遅くなる現象の原理を整理します。PostgreSQLのプロセスモデルでコネクションがなぜ高価なのか、ディスクとCPUの並列性が有限である以上、待ち行列をデータベースの中ではなくプールに立てるほうが良い理由、よく引用されるコア数ベースの公式の根拠と限界を扱います。マイクロサービスでインスタンス数とプールサイズの積が最大コネクション数を超える典型的な事故、PgBouncerの三つのモードとトランザクシ

  2026-07-26 · 25 分で読めます #database#postgresql#connection-pool#pgbouncer#performance

• トランザクション分離レベルと実際の異常現象 — 標準の定義が実装と食い違う地点

  トランザクション分離レベルの四つと、dirty read、non-repeatable read、phantom readを整理しますが、教科書の表一枚で終わらせません。PostgreSQLのRead Committedがなぜ最初からdirty readを作れないのか、Repeatable Readがなぜ実はスナップショット分離であり、直列化失敗をアプリケーションが再試行しなければならないのか、MySQL InnoDBのRepeatab

  2026-07-26 · 22 分で読めます #database#postgresql#transaction#isolation-level#mysql

• デッドロックの診断と予防 — ログから二つのクエリを特定する方法

  deadlock detectedエラーに出会ったとき何を見るべきかを順番に整理します。PostgreSQLのデッドロックレポートとMySQLのSHOW ENGINE INNODB STATUSの出力を一行ずつ解釈して、どの二つのクエリが絡んだのかを特定する方法、そして実務で繰り返される三つのパターンである更新順序の不一致、インデックス不在によるロック範囲の拡大、外部キーが引き起こす親行のロックを扱います。deadlocktimeout

  2026-07-26 · 25 分で読めます #database#postgresql#deadlock#locking#mysql

• インデックスを作ったのに使われない理由 — オプティマイザが正しく自分が間違っている場合

  インデックスを作ったのに実行計画にSeq Scanがそのまま残る理由を、原因別に整理します。選択度が低くてオプティマイザがわざと無視する場合、カラムに関数や演算がかかってsargableでない場合、型の不一致で暗黙のキャストが起きる場合、LIKEの先頭ワイルドカード、OR条件、複合インデックスの先頭カラム規則、統計情報の老朽化、NULLの扱いまで、実際のSQLと実行計画で確認します。部分インデックスと式インデックスが答えになる地点、そし

  2026-07-26 · 21 分で読めます #database#postgresql#index#query-optimization#mysql

• EXPLAIN ANALYZEの読み方 — 実行計画から本当のボトルネックを見つける順序

  EXPLAIN ANALYZEの出力を最初から最後まで読む方法を整理します。ノードをどの順序で読むべきか、costがなぜ時間の単位ではないのか、予想行数と実際の行数の乖離が何を教えてくれるのか、loopsが掛け算される罠をどう避けるかを、実際の出力とともに説明します。Nested Loop、Hash Join、Merge Joinがそれぞれ選ばれる条件と、BUFFERSでキャッシュヒットを判断する方法も扱います。Seq Scanが常に悪

  2026-07-26 · 22 分で読めます #database#postgresql#explain#query-optimization#performance