サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
qiita.com/masudakz
この投稿は、PostgreSQL Advent Calendar 2019 の12日目で公開する記事です。 今日はCollation、照合順序についての記事です。 なぜこのテーマ 10年ほど業務でPostgreSQL使ってきましたが、今年会社を変わって、MySQLだけ使うようになったのです。 PostgreSQLとMySQLのユーザ会は合同勉強会もあって、知らない仲でもなかったのですが、今年からMySQL CasualやMyNAでも勉強してます。 そこで不思議に思ったのが、MySQLの勉強会ではしばしばCollationの話題が出るのですよ。 とみたさんの令和の記事とか https://tmtms.hatenablog.com/entry/201904/mysql-reiwa2 普通の「令」U+4EE4ともうひとつの「令」U+F9A8 異体字セレクタ U+4EE4 U+E0102 令和と合
RDBMS といっても、SQLiteをシングルユーザで使ってたり、ORMやRESTful APIでWrapされた状態で使っていると、SQL問い合わせのできる「ファイル」という感覚になるかもしれません。 その感覚で PostgreSQL を使うとしばしば落とし穴にはまります。 DBMSは大変なのだ DBMSは昔から同時多発の更新要求を矛盾無くさばくトランザクション処理が要件でした。 この要求の苛烈さ・複雑さに思いを馳せるには、"Transaction Isolation Level", "トランザクション隔離性水準", "トランザクション分離レベル" あたりをキーワードにググってみるのがいいでしょう。 たとえばこんなページ http://language-and-engineering.hatenablog.jp/entry/20110104/p1 DBの「トランザクション分離レベル」が必要
弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 (この記憶はほんとうか? 意訳や美化が入っているかもしれない) 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQLをメジャーアップするには、現況を把握して変更影響を洗い出す作業から始めます。 現況把握のひとつとして、postgresql.conf(AWS RDSだとparameter group) の状況調査をしました。 重点ポイント PostgreSQLデフォールト
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
技術書典4に遊びにいってきました。 イベント概要 2018-04-22 日曜 一般入場11:00-17:00 場所 秋葉原UDX 参加者数5880名、サークル入場者500名、合計6380名 ざっと前回の2倍 ゆるふわ参加 twitterで #技術書典 タグをチェックして、「うげ、一般待機列すごいな」 【速報】一般参加者は一旦解散するようスタッフさんから指示がありました #技術書典 — かおらべ (@kaorabe) 2018年4月21日 11:00入場なのに08:32にこのtweetですよ。機先を制して新刊コンプリートを目指すのは早々にあきらめました。 昼過ぎて、整理券番号と入場可能番号の差がだいぶ小さくなってから出立。 4700番台の整理券をもらってから、UDXの3Fで遅いランチ(少しビールも入れた)。 入口に戻ると5300番台まで入場可能になっていて、入場後しばらくしたら、全番号に開放
弊社ジャストシステムは、社内勉強会を奨励しています。業務に関連する(関連しそうな)勉強会は業務扱いです。 エンジニア採用ページの技術への取り組みから引用しますと 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を利用しているので、その活用状況や社内でのノウハウ共有状
11/5にオープンソースカンファレンス 2016 Tokyo/Fallに行って、PostgreSQL中心に聴いてきました。 総合ハッシュタグは #osc16tk 「生誕20周年を迎えたPostgreSQLを使ってみよう」 JPUG中国支部長、曽根壮大氏 Speaker Deckのスライド 実況tweet拾い上げ データ分析やるならPythonでしょ。で、PythonとPostgreSQLはPL/Pythonあって使いやすい。例えばPythonの機械学習LibraryをPL/Pythonから呼べる。パラレルクエリもある。 Pythonでストアド書いてSQLで関数呼ぶだけでデータ分析 バックアップ・可用性でもPostgreSQLはOracleに追いついたんじゃない? PostgreSQLと商用DBの違い。RDBの基本的な部分ではだいたい追いついた。パラレルクエリ、SQL構文、バックアップや冗長
アンチパターンばかり書いてきましたけど、たまにはアンチじゃないものも出しましょう。 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では処理能力が追いつかなくなってき
2016-07-30 05:30起床して、終電新幹線で帰ってくる強行遠征で岡山の丸一日「SQLアンチパターン」漬けの勉強会に参加してきました。 @razon さんの togetter から自分用にさらに抜粋しておきます。 データベース大臣だけど、これは出張扱いにならず、プライベート参加。登壇するにしても首都圏限定とか縛られてるのよね。 プライベートのほうが発表内容の事前査定とか、事後のレポート義務とか面倒事が発生しないから、お気楽なもんだ。 新幹線のIC早割21の使えるタイミングで、@mako_wis さんが増席してくれて、キャンセル待ちから繰り上がったのもありがたかったなあ。 SQL Server のプロジェクト指向オフライン データベース開発を採用してみた話・実践編 @kiyokura さんによる、ディプロマティック・イミュニティ(外交特権)の対策。 "SQL を書くときに入力補完して
最新版マニュアル(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%ですが、インクリメント傾向だったら、最後尾ばかりが分割してい
この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
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万行を越えるような巨大テーブルだと、主キーインデック
このページを最初にブックマークしてみませんか?
『@masudakzのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く