PostgreSQLのデータを削減できた話 | PR TIMES 開発者ブログ
はじめまして、PR TIMESの開発本部でインターンをさせて頂いている永井と申します。 現在はパフォーマンス改善のタスクをしています。 はじめに 自分は今回のタスクをやるまでSQLをあまり書いたことがありませんでした（ORマッパーしか使っていませんでした）。しかし、今回のタスクをやることで直接SQLを書くことが多くなりSQLはもちろんPostgreSQLの構造はどうなっていて、何がメモリを消費しているかなどについての理解も深まりました。本当に良い経験をさせて頂きました。 なぜ削減することになったのか PostgreSQLのストレージがとても逼迫していました。さらにPostgreSQLはオンプレの物理サーバーで動いていてストレージの増設も難しいため、AWSに移行するまでの延命措置としてデータ量を削減することになりました。 まずは状況確認 一番容量を使っているテーブルはどれか 以下のクエリで、
MySQLに初めてINSERTするとアクセスが発生するファイルは何かという質問をどう調べるのか - oranie's blog
yokuo825さんのカッコいいインタビュー記事を t.co 読んで、この部分ですね ──例えばどのような話をしましたか？ 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 でこんなツイートしたんですが 全国のDBAは「特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」これ明日から職場で
MariaDB 10.5 の性能は不正？
普段は基本的にMariaDBの動向は全く追って無いです。 でも先日、MariaDB 10.5 のfsync()発行が少なく性能が良いのは何故なのかちょっと見てほしいと言われて、 mariadb-10.5.9.tar.gz をざっと見たらあっという間に原因特定。 「fsync()を待つべきなのに待ってないから」 只の不正と判明。 動作としては、 innodb_flush_log_at_trx_commit = 1 でも innodb_flush_log_at_trx_commit = 2 でも 並列度が上がると多くのトランザクションが innodb_flush_log_at_trx_commit = 0 の動作と同等となってしまうようです。 待たないのだから速いに決まってる。こんな不正なものと比較されるのは腹立たしいです。 指定のLSNまでのwriteやflushを終わらせる log_wri
MySQL 8.0 vs 外部キー制約 vs ALTER TABLEでメタデータロック待ちになったら疑うこと
TL;DR MySQL 8.0(細かくは8.0.4っぽい)とそれ以降は「外部キー制約を持っているテーブルにSELECTするとそのテーブルの親テーブルにもメタデータロック(MDL)を置くようになった」 MDLであるがゆえに foreign_key_checks をOFFにしようが 無効化はできない MySQL :: WL#6049: Meta-data locking for FOREIGN KEY tables WL#6049 “Meta-data locking for FOREIGN KEY tables” and WL#11059 · mysql/mysql-server@6626f76 これ以降にもいくつかコミットが続いている 論より証拠。 サンプルスキーマはこんなかんじ。 CREATE TABLE `item` ( `item_id` int NOT NULL, `registe
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
