型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
こんなデータベース用ライブラリを誰か作ってほしい（Go） - のんびり精進
Go2 Advent Calendar 2019 の 6 日目の記事です。 Go の database/sql って使いにくくないでしょうか。 二年ちょっと前にもっと楽にできないかなと思って調べました。 欲しかったもの database/sql を使いやすくしたもの ORM は要らない ただし、SELECT と INSERT は楽をしたい ORM を必須とする人もいると思いますが、そのときは直に SQL 文を書きたかったので、それに合ったライブラリだけを試しました。 試したライブラリ sqlx Connect()、MustExec() など database/sql とのメソッド名の違いが大きくて、感覚的に避けてしまいました。 gorp 割と近い感じで使えて好感触でした。 というわけで gorp を選び、そのときに書いた記事が下記二つです。 【Go】gorp を使って DB 操作を少し楽に
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
userテーブルはマスターテーブル？DBのTABLEをいくつかの種別に分ける目的について - INNOBASE技術ブログ
新規WEBシステムのデータベース設計を軽く眺めていたところ、不思議な定義を見つけました。 user テーブルがマスターテーブルの扱いになっています。 設計者に聞いてみると「業務系システムではユーザーテーブルはマスタですよ？」とのこと 業務系ではそれもありうるな、と一定納得しつつ そもそも何故マスターとトランザクション(ユーザー) テーブルを分ける必要があるのか？ という辺りから振り返り、ユーザーテーブルが何に分類されるべきか再考してみました。 テーブルを分類する目的について まずはググってみる マスターデータとは - IT用語辞典 Weblio辞書 マスターデータとは、主に企業が社内向けや業務向けなどで構築する情報システムにおいて、製品や顧客や会計など多くのデータベースで共通となる、基本的な情報のことである こちらのページのようにマスターテーブル（あるいはマスターデータ）とトランザクション
JPAのサンプルは、たいていデータ構造が手抜き - 極北データモデリング
O/Rマッパーに対してネガティブな意見を見つけた。 O/Rマッパーの話 - 工夫と趣向と分別と。 http://d.akinori.org/?date=20060926#p01 一般に、テーブル設計をクラス設計に擦り寄せれば、リレーションを駆使する必要は減る。この罠にはまると、 オブジェクトクラスにそのまま対応させたテーブルを作ってしまい、コードの見かけはきれいでもデータは ぐだぐだな代物ができがちだ。 オブジェクトグラフの構造をそのままデータ構造にしたらグダグダになりますよ、ということだな。 これ読んで思い出すのが、ちょっと前にJPAの正しい使い方を知ろうと思ってサンプルを漁ってみた時のこと。 実戦で使えるデータ構造を作っているサンプルが無くて、結局JPAてどうやって使えばいいのか分からなかった。 焦点は event の扱いで、サンプルは以下の３パターンに分かれる。 1. そもそも ev
【ScalaMatsuriセッション当選御礼】ドワンゴ秘伝のトランザクションモナドを解説！ - Qiita
このたびはScalaMatsuriのセッションに投票していただき、ありがとうございました。 今回はそのScalaMatsuriのセッションで発表予定の内容の一つであるドワンゴ秘蔵のトランザクションモナドについて解説したいと思います。 このトランザクションモナドは基本的な機能だけなら30行ほどの短いコードで記述できてしまうのですが、なかなか説明が難しい代物でして、 ScalaMatsuriの自分の発表時間内に聴衆のみなさんに理解していただくのは難しいだろうということで、先に解説記事を書くことにしました。 このトランザクションモナドは作者の名前から通称Fujitaskと呼ばれているのですが、作者の方は周りから「天才」と言われてまして、彼は常人が思いつかないようなコードを書かれるんですね。 Fujitaskは短いながらも、モナドと、サブタイピング(変位指定)と、アドホックポリモーフィズムの三つの
トランザクションをSerializableにする4つの方法
2015年12月18日に行われたビッグデータ基盤勉強会で発表する際に使った資料です。Read less
sql-protobuf
sql-protobuf Convert a SQL CREATE TABLE statement into a protobuf schema. Parsing SQL with regex has been called 'almost impossible' -- but I like to think we can cover over 90% of the cases. There might be bugs. If this has trouble with a functioning SQL CREATE TABLE statement, let's try to fix it. $ npm install -g sql-protobuf Yes, this successfully handles: Multiple CREATE TABLE statements in o
在庫のデータ構造を考える | タイム・コンサルタントの日誌から
「わたし」は新米のエンジニアである。最近、先輩からオフィス備品類の在庫管理を手伝うようにいわれた。ペンだとかノートだとかフォルダとかいった文具類が中心である。これまである意味、ルーズな管理だったが、経費節減の折、きちんと在庫数量を管理した方がいい、と部長が方針を出したとのことだ。今まで、各人が勝手にネットからモノを注文して取り寄せ、請求伝票だけが部の庶務係に回される。これをやめて、部で必要数量を考え、集中的に購入し、部のキャビネに保管しておく。そして各人が必要時に庶務係に申請して受け取る、という管理方式にかえることになった。その、キャビネの在庫管理の仕組み作りが、「わたし」の仕事だ。 在庫管理の仕事ははじめてだ。だからいきなり部の仕組みを作り始める前に、たとえば自分の家のモノを在庫管理するとしたらどうするかを考えてみることにした。題材は何でも良いが、出入りの多い食べ物にしてみよう。 在庫管
scheman-rails - ✘╹◡╹✘
沖縄開発合宿2日目: Rails用のDBスキーマ管理ツール scheman-rails を開発した。 使い方 db/schema.sql に理想的なスキーマをSQLで記述する rake db:schema:diff で現在のDBのスキーマとの差分を確認する rake db:schema:apply でSQLを適用して差分を埋める 基本的にはこれの繰り返しで、開発者は理想的な db/schema.sql を保つことに集中していれば良いという世界観。 DBスキーマどういう構成だったったっけという場合にもこのファイルを見れば良いのでちょっと楽。 導入時に既にDBが存在するときは、いちいちdb/schema.sqlを書くのはだるいので適当に mysqldump --no-data --compact の結果を貼り付けとけば良いかもしれない。 解決されそうな問題 この辺が解決できそう。 複数ブランチ
PostgreSQL Internals
本コンテンツは、2014年1月30～31日に筑波大学で開講された「情報システム特別講義D」における講義「Inside PostgreSQL Kernel」の内容を再構成、加筆・修正したものです。 はじめに 本コンテンツについて 本コンテンツへのフィードバックについて アーキテクチャ概要 PostgreSQLの構成要素 PostgreSQLの基本的なアーキテクチャ SQL文の処理される流れ トランザクション管理 トランザクション処理におけるACID特性 各レコードの可視性の管理 Atomicity（原子性）の実装 Consistency（一貫性）の実装 Isolation（分離性）の実装 トランザクション分離レベルの定義 Durability（永続性）の実装 チェックポイント メタデータ管理 pg_controlファイル OID/XID/TID システムカタログ MVCCとストレージ構造 テ
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
(PgDay2012発表資料) SQLにとって、なぜO/Rマッパーが重要かを説明した資料です。Read less
削除フラグのはなし
6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - codemix/ts-sql: A SQL database implemented purely in TypeScript type annotations.
GitHub - MasahikoSawada/pg_simula: A database system failure simulation tool for PostgreSQL
ついに解禁！Amazon Aurora徹底検証！
