AWS RDSでもDBAはparameterチューニングする - Qiita
弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 （この記憶はほんとうか？ 意訳や美化が入っているかもしれない） 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQLをメジャーアップするには、現況を把握して変更影響を洗い出す作業から始めます。 現況把握のひとつとして、postgresql.conf（AWS RDSだとparameter group） の状況調査をしました。 重点ポイント PostgreSQLデフォールト
PostgreSQLアンチパターン：インデックス関連の三本立て - Qiita
SQLプランナの過信 time_of_report に インデックスつけてあるから大丈夫だろうと思っていたら、Seq. Scan になっていたSQL です。 SELECT id FROM reports WHERE user_id = 12345 AND date_trunc('day', time_of_report) = current_date; WHERE句でdate_trunc 関数：timestampの丸めを使ったせいで、インデックスを使ってくれなかった。 それはそうですね。関数一般を適用した結果は、値の順序が変わってしまう＝index上の位置が変わってしまう、可能性があるので。 対策： 性能の欲しいWHERE句で、高頻度でその関数を使うなら、インデックスも関数値で作る USING btree(date_trunc('day', time_of_report)) date_tr
PostgreSQL Internals社内読書会やったらまさかの第2期もあったよ - Qiita
弊社ジャストシステムは、社内勉強会を奨励しています。業務に関連する（関連しそうな）勉強会は業務扱いです。 エンジニア採用ページの技術への取り組みから引用しますと TechCOLLEGE 機械学習、リーダブルコード、商品力強化などワークショップ形式で学ぶものから、グロースハック、構文解析、インメモリデータベースなどライトニングトークでの共有など、さまざまな議題で勉強会を開催しています。 多人数単発形式もあれば、少人数定期開催もあり。 1年前に「PostgreSQL篠田の虎の巻」読書会で始めた、社内勉強会復興運動、大臣以外の有志もそれぞれ初めて、定期開催が進んでいる。涙出そうに嬉しい。 — masuda kaz (@masudakz) 2017年3月3日 ; 勉強会のうち、2016/3開始でやりきった後、2017/3から第2期もやった「PostgreSQL篠田の虎の巻読書会」について、どんな感
PostgreSQLスケールアウトパターン Instagram way - Qiita
アンチパターンばかり書いてきましたけど、たまにはアンチじゃないものも出しましょう。 PGConf.Asia2016 で Tantan の Victor Blomqvistさんもやってた、Instagram方式です。 元ネタ Instagram Engineering Blog PGConf.Asia2016公開資料：TantanでのPostgreSQL事例 – 2年で0から350billion rowへ Victor Blomqvist DBのスケールアウト Webサービスが順調に成長すると、顧客当たりのデータ量が徐々に増える、顧客が増えるで、DBのデータ量も増えていきます。 Apache/Tomcatの能力不足は、セッション管理だけ最初に注意して構成しておけば10や20に台数増やしていくのは容易な話で、問題はDBをどうするかです。 1台のDBServerでは処理能力が追いつかなくなってき
PostgreSQLアンチパターン：外部キー制約の更新コストを見くびる - Qiita
このTABLE定義であやういところはどこでしょう？ サービスにどんなインシデントが発生したか想像できるでしょうか？ CREATE TABLE reports ( id bigserial NOT NULL, user_id bigint NOT NULL, time_of_report timestamp without time zone NOT NULL, previous_report_id bigint REFERENCES reports (id), elapsed_time integer NOT NULL DEFAULT 0, CONSTRAINT reports_id_pkey PRIMARY KEY(id), CONSTRAINT reports_user_id_fkey FOREIGN KEY(user_id) REFERENCES users(id) MATCH SI
ad3e04e50357a1e758fc#_reference-a1b4100c3771c36dfbe6
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
