はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? RDBMS といっても、SQLiteをシングルユーザで使ってたり、ORMやRESTful APIでWrapされた状態で使っていると、SQL問い合わせのできる「ファイル」という感覚になるかもしれません。 その感覚で PostgreSQL を使うとしばしば落とし穴にはまります。 DBMSは大変なのだ DBMSは昔から同時多発の更新要求を矛盾無くさばくトランザクション処理が要件でした。 この要求の苛烈さ・複雑さに思いを馳せるには、"Transaction Isolation Level", "トランザクション隔離性水準", "トランザクション

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 （この記憶はほんとうか？　意訳や美化が入っているかもしれない） 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQ

WHERE句でdate_trunc 関数：timestampの丸めを使ったせいで、インデックスを使ってくれなかった。 それはそうですね。関数一般を適用した結果は、値の順序が変わってしまう＝index上の位置が変わってしまう、可能性があるので。 対策： 性能の欲しいWHERE句で、高頻度でその関数を使うなら、インデックスも関数値で作る USING btree(date_trunc('day', time_of_report)) date_trunc() のように、元の値のindex順でも十分に絞込可能な関数は、SQLプランナの替わりに人間が評価式を置き換える time_of_report >= current_date AND time_of_report < current_date + interval '1days' pg_stats_reporter や postgres log で

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術書典4に遊びにいってきました。 イベント概要 2018-04-22 日曜 一般入場11:00-17:00 場所 秋葉原UDX 参加者数5880名、サークル入場者500名、合計6380名　ざっと前回の2倍 ゆるふわ参加 twitterで #技術書典 タグをチェックして、「うげ、一般待機列すごいな」 【速報】一般参加者は一旦解散するようスタッフさんから指示がありました #技術書典 — かおらべ (@kaorabe) 2018年4月21日 11:00入場なのに08:32にこのtweetですよ。機先を制して新刊コンプリートを目指すのは早々に

弊社ジャストシステムは、社内勉強会を奨励しています。業務に関連する（関連しそうな）勉強会は業務扱いです。 エンジニア採用ページの技術への取り組みから引用しますと TechCOLLEGE 機械学習、リーダブルコード、商品力強化などワークショップ形式で学ぶものから、グロースハック、構文解析、インメモリデータベースなどライトニングトークでの共有など、さまざまな議題で勉強会を開催しています。 多人数単発形式もあれば、少人数定期開催もあり。 1年前に「PostgreSQL篠田の虎の巻」読書会で始めた、社内勉強会復興運動、大臣以外の有志もそれぞれ初めて、定期開催が進んでいる。涙出そうに嬉しい。 — masuda kaz (@masudakz) 2017年3月3日 ; 勉強会のうち、2016/3開始でやりきった後、2017/3から第2期もやった「PostgreSQL篠田の虎の巻読書会」について、どんな感

2017-01-21 第34回 PostgreSQL 勉強会 自己紹介 増田和弘 Twitter: @masudakz 所属：株式会社ジャストシステム 中途入社で一太郎Ver.4開発中（1987）から 当時の主力機　NEC PC-9801VX 5インチFDD、80286/8MHz+V30/10MHzを搭載。VX4（SASI HDD、容量20MB） PostgreSQL歴 2000年代初めのエンタープライズ製品での利用から接触 実装・運用経験は2013年から PostgresSQL 9.2〜 CentOS on AWS 本日の内容紹介 ユーザ視点の事例発表 株式会社ジャストシステムのWebサービスはスマイルゼミをはじめとしてほとんどがPostgreSQLを使っています。 Webサービスのヘルスチェックにpg_stats_reporterを利用しているので、その活用状況や社内でのノウハウ共有状

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 11/5にオープンソースカンファレンス 2016 Tokyo/Fallに行って、PostgreSQL中心に聴いてきました。 総合ハッシュタグは #osc16tk 「生誕20周年を迎えたPostgreSQLを使ってみよう」 JPUG中国支部長、曽根壮大氏 Speaker Deckのスライド 実況tweet拾い上げ データ分析やるならPythonでしょ。で、PythonとPostgreSQLはPL/Pythonあって使いやすい。例えばPythonの機械学習LibraryをPL/Pythonから呼べる。パラレルクエリもある。 Pythonでス

アンチパターンばかり書いてきましたけど、たまにはアンチじゃないものも出しましょう。 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では処理能力が追いつかなくなってき

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2016-07-30 05:30起床して、終電新幹線で帰ってくる強行遠征で岡山の丸一日「SQLアンチパターン」漬けの勉強会に参加してきました。 @razon さんの　togetter から自分用にさらに抜粋しておきます。 データベース大臣だけど、これは出張扱いにならず、プライベート参加。登壇するにしても首都圏限定とか縛られてるのよね。 プライベートのほうが発表内容の事前査定とか、事後のレポート義務とか面倒事が発生しないから、お気楽なもんだ。 新幹線のIC早割21の使えるタイミングで、@mako_wis さんが増席してくれて、キャンセル待

最新版マニュアル(9.4/9.5)では、親切に書いてあるんですが、ググったときに、9.3以前のページが真っ先に目に入るかもしれないし、担当しているサービスが9.3のままだからマニュアルも9.3しか見ないという人もいるかもしれない。 B-tree の充填効率 生きてるTABLEについている INDEX の B-tree 各ページの充填率は、最密充填とはいきません。DELETEされたところ、UPDATEで値が変わったところが抜けていても、近いキー値でのINSERTがこないと、空いたところが埋まりません。 ページがあふれたときの新ページとの分割戦術と、その後に続いてINSERTされてくるキー値の変化傾向が合致しないと、スカスカのUnbalanced-treeになるケースもあります。ランダムケースなら、分割戦術50:50で全体充填率75%ですが、インクリメント傾向だったら、最後尾ばかりが分割してい

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 SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE ); CREATE INDEX

pg_dumpはPostgreSQLデータベースをバックアップするユーティリティです。 データベースを使用中であっても、他のユーザによるデータベースへのアクセスをブロックしませんし、運用に欠かせないツールです。 それでも濫用はいけません。運用の巨大DBなら極力回避したいものです。 ページキャッシュ総入れ替え データベース全体をひとなめするので、サービス実需ではアクセスしなくなったような古いデータまで、一度読み込んでしまいます。それによって、実需側のキャッシュヒット率が下がるリスクがあります。検索範囲の局所化効果で、サービスのスループットを保っていたなら、一時的にスループットが低下します。 データ量比例の処理 データベース全体を、ポータブルな形式で外部出力するので、データ量に比例してIO/CPUに負荷がかかります。 アクセスピークと重なったりすると、DBServerの過負荷でパンクのリスクが

SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック