作って理解する RDBMSのしくみKaigi on Rails 2024「作って理解する RDBMSのしくみ」の発表スライド。 #kaigionrails https://kaigionrails.org/2024/talks/ydah/
PostgreSQL and UUID as primary key
UUIDs are often used as database table primary keys. They are easy to generate, easy to share between distributed systems and guarantee uniqueness. Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide. This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently. P
CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
3. 2 Agenda 1. 自己紹介 2. RDBMSで履歴データを扱う スナップショットデータモデル トランザクション時間データモデル 有効時間データモデル バイテンポラルデータモデル 3. Javaからバイテンポラルモデルを容易に扱うReladomoの紹介 hashtag: #ccc_g3 4. 3 自己紹介 趣味：ドラム演奏 JavaOneコミュニティバンド Null Pointersで演奏経験あり（日本人初） Tech Lead @ FOLIO 伊藤 博志 Eclipse Collections：共同プロジェクトリード兼コミッター Reladomo：コントリビューター OpenJDK：コントリビューター JJUG CCC、Java Day Tokyo、JavaOne San Francisco登壇 2017年5月17日に株式会社FOLIO入社。 hashtag:
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
【SQL】ちょっとしたパフォーマンスチューニングまとめ - Qiita
SELECT table_a.id, table_a.name FROM table_a INNER JOIN table_b ON table_a.id = table_b.id; メリットとしては、 どちらかのテーブルのid列のインデックスを使用可能 サブクエリがないことで中間テーブルが作成されない しかし、インデックスがない場合はEXISTSの方が良い場合があります ソートの回避 SQLでは暗黙的にソートが発生する演算が存在するので、 パフォーマンスにも影響するため、ソートが必要ない場合は考慮する必要があります ソートが発生する演算 GROUP BY句 ORDER BY 句 集約関数（SUM, COUNT, AVG） DISTINCT 集合演算子（UNION, INTERSECT, EXCEPT） ウィンドウ関数（RANK, ROW_NUMBER 等） メモリ上でのソートだけではなく
MySQLとOracleの実行計画を比較してみた - ASMのきもち
まいえすきゅーえりたい ぽすぐれない おらくるってる（狂ってる）tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな！というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません
マイクロサービス化による「DB分割」で開発、運用が難しくなるこれだけの理由
大きく変化した「人とシステム」の関係 企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。 マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。 「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWe
Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識 - CARTA TECH BLOG
みなさん、おはようございます！ CARTA fluct エンジニア の なっかー@konsent_nakka です。 CARTA TECH BLOG アドベントカレンダー 12/14ということで、普段DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識をざっとまとめてみました。 とりあえずこれだけ読んでおけば最低限は困らない、もし何か困った時にはあそこで出てきた内容をもう少し深く調べて見るか、というきっかけになれば良いなと思います。 厳密な定義よりも普段DBを扱う中でロックについてあまり意識したことがないような人にもすっと入ってくるように簡単な表現を優先して書いていますがご了承ください。 目次 留意事項 排他ロックと共有ロック トランザクション分離レベル SELECTのロックレベルを変更する 共有ロック: LOCK IN SHARE MODE 排他ロ
単一インデックスの組合せ機能と、複数列インデックスの速度の違いを計測してみる
Postgreで単一インデックスでの組合せ機能というものがあることを知りました。 幸いにも、PostgreSQLは、単一のインデックススキャンでは実装できない場合を扱うために、複数のインデックス（同じインデックスの複数回使用を含む）を組み合わせる機能を持ちます。 システムは複数のインデックススキャンを跨がる、AND条件およびOR条件を形成できます。 疑問： 単一インデックスの組合せ機能と、複数列インデックスってどっちが早いの？ たとえば、以下のようなお店が扱う商品コードとその値段を管理するテーブルを作ります。 CREATE TABLE shop_item1 ( shop_id TEXT NOT NULL, -- お店コード item_id TEXT NOT NULL, -- 商品コード price INTEGER NOT NULL -- 値段 ); このテーブルは、shop_idとitem
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DMMプラットフォームがTiDB Cloudを採用した背景
履歴データテーブルとの向き合い方_PHPerKaigi2024
やさしいActiveRecordのDB接続のしくみ
WEB+DB PRESSと私
DBやめてみた / DNS water torture attack and countermeasures
図解 DB インデックス
