質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh
この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。 昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。 いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの？明日AWSサポートに早速連絡してみよう… 最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ！！笑 さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。 そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。 今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
概要 前回（PostgreSQLでテーブルの定義を確認する。 - Tihiroの頭を休めるIT教室）はPostgreSQLでテーブル定義を確認する、ということでした。 今回は、テーブルの制約を確認したいと思います。 例によって環境は PostgreSQL9.6 です。 確認してみる メタコマンドで確認してみる 前回、テーブル定義を確認したのと同じく ¥d テーブル名 で確認できます。便利ですね！ SELECT文で確認してみる メタコマンドとは違って、SELECT文で制約を確認するのは少しめんどいです。なぜなら、情報スキーマ内の複数のビューを参照する必要があるからです。 めんどいことは細かく分解して解決するのが一番です。 ということで、 主キー制約 CHECK制約 外部キー制約 ユニーク制約 の４つに分けて確認してみます。 1.SELECT文で主キー制約を確認する テーブルの主キー*1を確認
PostgreSQLの運用管理にログの情報は不可欠ですが、PostgreSQLが出力するログは直接取り扱うのに適した形式とは言えません。ここではFluentdを使って運用管理に活用しやすい形にPostgreSQLのログを加工する方法を紹介します。 PostgreSQLの運用管理とログ データベースの運用管理には 死活監視、リソース監視 性能分析、チューニング バックアップ、リストア といったものが考えられますが、現状を把握しなければ何も対策できないので、まずは必要な監視を正しく行うことが重要です。PostgreSQLで監視に使える機能には稼働統計情報とログがありますが、今回はログに注目してみます。 PostgreSQLのログからわかること PostgreSQLが出力するログからは以下の様なことがわかります。 何らかの異常(エラー)が発生したこと 処理されたSQL チェックポイント、自動VA
Bill Karwin “SQL Antipatterns: Avoiding the Pitfalls of Database Programming” の読書メモ。 Jaywalking 目的 ある属性について、複数の値を持たせる。 アンチパターン : カンマ区切りリスト カンマ区切りで複数の値を 1 つの列に納める。 例では、特定の製品についての担当者を複数設定するのにカンマ区切りで、担当者のアカウントIDを記述している。 create table products ( product_id integer, product_name varchar(1000), acount_id varchar(100), -- comma separated list -- ... ); insert into products (product_id, product_name, accou
2013/6/27(木) SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加してきました。 DoorKeeper http://sqlap.doorkeeper.jp/events/4507 以下の書籍をターゲットとした読書会なのです。 場所はいつもの湯島、アルティネットさんです。 参加者は10名かな。初参加1名です。新しい風が入るのは良いですね。 『SQLアンチパターン』読書会、本日は「5章 EAV（エンティティ・アトリビュート・バリュー）」を議論します。 E・A・V！ E・A・V！ #sqlap — Takuto Wada (@t_wada) June 27, 2013 今日も相変わらず頼もしい！ ちなみに @t_wada さんがこの書籍を翻訳しようと思ったキッカケは、このEAVだったそうです。 そういう意味でも、非常に興味深い章ですね。 ■アジェン
NTT オープンソースソフトウェアセンタ 板垣 貴裕 PostgreSQL でロケール (国際化と地域化) の設定を行うと、データベース内での文字列処理、日付や通貨の表示、メッセージの言語などを変更することができます。特に PostgreSQL 8.4 では、日本語のメッセージ・カタログが追加されたため、エラーメッセージを日本語化したい場合にはロケールを設定する必要があります。 ただし、C ロケール以外を設定すると、インデックスが使われないなどの性能への影響がある場合もあります。また、特に古いバージョンの PostgreSQL では、誤った設定によりサーバが正しく動作しなくなるケースもありました。 この記事では、ロケール設定の効果を結果例を交えて解説すると共に、トラブルへの対応方法を示します。PostgreSQL で日本語を扱う際に、ロケール設定を決める時の参考にして下さい。 Postgr
JPOUG Tech Talk Night #2 で話した内容に飲み会で質問された内容を加えています。Read less
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
データベース技術の世界に新顔が次々と登場している。米Danga Interactiveの「memcached」、ミクシィの「Tokyo Cabinet」と「Tokyo Tyrant」、楽天の「ROMA」、グリーの「Flare」などだ。いずれも半導体メモリーを使って大規模データベースを高速処理する技術である。面白いのは、4社ともIT製品を開発するメーカーではないことだ。 4社は、Webを使ったサービス事業を手掛ける企業であり、本来であればメーカーが開発した製品や技術を使う立場である。ところが、こうした「ユーザー企業」が自ら基盤技術を開発し、それを利用している。 memcachedやTokyo Cabinet/Tyrant、ROMA、Flareの中では、memcachedが一番古い。Danga Interactiveが自社のブログ・サービス「LiveJournal」を改善するために2003年に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
