質問されることが多いので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}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
はじめに Androidアプリケーションを作成する上でSQLiteを使用してデータベースを扱うことは多々あります。データの永続化や検索といった処理を容易に実装することができるので、多くのアプリケーションで使用されています。しかし、AndroidにはSQLiteを使用するための方法が以下のようにいくつか用意され、それぞれファイル作成時のパーミッションの挙動が異なっています。 SQLiteDatabase#openOrCreateDatabaseを使用して作成する Context#openOrCreateDatabaseを使用して作成する SQLiteOpenHelperクラスを使用して作成する もし、開発者がこれら方法の挙動を十分に理解していない場合、知らずのうちに脆弱性を作り込んでしまいます。 実際に、いくつかのアプリケーションではSQLiteDatabase#openOrCreateDa
中古マンション購入の際に一番大きな悩みは、購入価格が適正かどうかということです。不動産屋はなんとかしてマンションの売買を成立させたいというモチベーションがあるので、そもそも完全に信用出来ないですし、かと言って市場調査を素人がすることが難しいのが現状でした。しかし、以下の記事で紹介されている「住まいサーフィン」でなんと過去のマンションの中古の売買記録が公開されており、そちらを見ればだれでも過去の中古マンションの価格を確認できるようになりました。 http://business.nikkeibp.co.jp/article/opinion/20111007/223066/ マンションの適正価格・資産価値・査定情報｜住まいサーフィン (「マンション検索」で該当マンションを検索して、「中古事例」の一覧をクリックで確認可能です。) このDBが信じらないくらいデータが詰まっており、試しに近くのマンショ
弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 本番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元／管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
