Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
データベースを自動でチューニングしてくれるサービス「OtterTune」
現代のデータベースには設定可能な項目が数百単位で存在しており、その全てを適切に設定して最高のパフォーマンスを導き出すのは並大抵のことではありません。そうした人間には難しいチューニングをデータベースの使用状況を把握して自動で行ってくれるサービスが「OtterTune」です。 OtterTune - Database optimization. On autopilot. | OtterTune.com https://ottertune.com/ OtterTuneを使う時に特殊なソフトウェアのインストールやコードの変更は不要で、OtterTuneをデータベースに接続して何を目標にするかを選べばOK。目標には例えばクエリパフォーマンスやコストなどを設定可能です。接続が完了すると自動で接続時点での設定や統計情報を読み取り始めます。このとき、テーブル情報やクエリなどデータベースの中身に関する情報
Schedule - CMU 15-721 :: Advanced Database Systems (Spring 2020)
Course Introduction and History of Databases (No In-Class Lecture) M. Stonebraker, et al., What Goes Around Comes Around, in Readings in Database Systems, 4th Edition, 2006 (Optional) A. Pavlo, et al., What's New with NewSQL?, in SIGMOD Record (vol. 45, iss. 2), 2016 (Optional) In-Memory Databases (No In-Class Lecture) X. Yu, et al., Staring into the Abyss: An Evaluation of Concurrency Control wit
SQLite4の開発物語
SQLiteの歴史 2000年 リリース1 HashベースのGDBMストレージエンジン SQLite1はGPLのGDBM(GNU Database Manager)エンジンを使ったので、その流れからライセンスはGPLで始まります(現在はパブリックドメイン)。この時からServerlessとSinglefile databaseがSQLiteの基本方針です。しかし、元となったGDBMはHashテーブルでありレンジスキャンができないので、Berkeley DBのドキュメントを2日ほど読んでからB-Treeストレージエンジンの開発を始めました。 2001年 リリース2 B-Treeストレージエンジン SQLiteが携帯電話や自動車、冷蔵庫などに搭載され広がり始めたのです。今はもうなくなりましたが携帯大手のモトローラから「バイナリーデータをサポートしてほしい」と言われてSQLite3の開発が始まり
Optimistic Concurrency Controlについて - Qiita
コミットまでロックを獲得せずに実行する方式の並行制御方式。 まず、更新のたびにバージョン番号が増加する複数のデータを読む際、読んだデータのバージョン番号とデータのペアで手元で保持しておけば、再度読んだ時にバージョン番号の変動を確認すれば値が書き換わっていないかを検出できる。 この図の中の緑色の領域の中で値が変わっていない事をバージョン番号から保証できる。 これは対象となるデータがいくつに増えても同様である。 こうすれば複数の値を論理的に一瞬で読めた事になる。これを一般にスナップショット読み出しと言う。 これに2PLを組み合わせる事で、トランザクション中で読み書きする値に一切ロックをかけずにコミット時のバージョン比較で代用できることになる。 Optimistic Concurrency Control(OCC)はこの考え方を拡張したもので、トランザクション実行中は 値を読み出す時はバージョン
バッファ管理とWAL - Qiita
データベース内のデータはページ単位でHDD内に配置され、ページ単位でメモリにバッファ及びキャッシュとして複製される。 HDD内のデータにアクセスする際は一旦メモリにページごと複製してからアクセスするわけだが、メモリ内におけるページの量は一般にHDDに置けるページ量より小さい（そうでない前提での話題はまた後日）。 LRU どのページをメモリに写し、どのページをHDDに置くかというのは、基本的にディスクアクセスの量を最小化する方向に最適化をする。 その際にはLeast Recently Used(LRU)という方法でキャッシュを管理する事が常套手段である。 それは「一番最近からみて使われた頻度が一番少ないページを解放して、そのメモリ領域を新たなディスクページの為に使いまわす」という戦略である。 具体的な実装方法としては双方向線形リストを使う。 新たにページをメモリに複製した際、双方向線形リスト
A Critique of ANSI SQL Isolation Levels | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic A Critique of ANSI SQL Isolation Levels – Berenson et al. 1995 udpate: 2 minor corrections in the section on A5A per the comment from ‘banks’ – thanks! The ANSI SQL isolation levels were originally defined in prose, in terms of three specific anomalies that they were designed to p
トランザクション分離レベルの古典的論文 A Critique of ANSI SQL Isolation Levels を読む - Hatena Developer Blog
こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー
カーネギーメロンのDBに関する講義が面白いのでおすすめ - だいたいよくわからないブログ
ここに書くことによって途中でやめられなくするメソッドです。 ハッカーニュースを眺めていたら以下のようなCS系講義動画のまとめリポジトリが流れていました。 GitHub - Developer-Y/cs-video-courses: List of Computer Science courses with video lectures. へーっと思いながら何個かポチってみたところ以下に出くわしました。 15721.courses.cs.cmu.edu 英語が（自分にとって）聞き取りやすく、動画の品質（画質やスライドがちゃんと見えるかどうかといった部分）も良いものでかつ興味のある内容で出来ればスライドもおしゃれで・・・となるとなかなか少ないですが、これはかなり見やすいです。 スライドも概念図が頻繁に登場したりして、これだけでも聞き取れなかった部分などをかなり補完できます。 スケジュールページ
論文紹介: In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか - 備考欄に感想を書くタイプのエンジニア
※これは システム系論文紹介 Advent Calendar 2016: ADVENTAR 1 日目の記事です。 昨今話題に事欠かない In-Memory DBMS ですが、暇に任せて Hekaton 関連で何か（←忘れました）を調べていたときに出くわした論文がこちらです。タイトルは Larger-than-Memory Data Management on Modern Storage Hardware for In-Memory OLTP Database Systems 一応和訳しておくと In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか、という感じでしょうか。 先に結論を言うと後述する通り、今日では HDD だけではない、さまざまなストレージ技術を利用したストレージデバイスが利用
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
象のジレンマ：データベースの未来はどうなる？
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 70歳を超えたMichael Stonebraker氏は気楽になってもよさそうなものだが、どうやらそうではないようだ。データベース研究のパイオニアである同氏は、いまだに週の大半をマサチューセッツ工科大学（MIT）で過ごし、残りの時間は自身で立ち上げたスタートアップ企業の仕事をしている。 その上、同氏は最近、「現代のデータベースシステムの基盤となる概念や慣行に対して基礎的な貢献をした」として、毎年計算機科学に貢献した人物に与えられるチューリング賞を受賞したところだ。 現在この賞はGoogleの協賛を受けており、受賞者には100万ドルの賞金が与えられる。過去の受賞者には、Alan Kay氏（オブジェクト指向プログラミングとSmalltalk
SQL Feature Comparison
Last updated: 2023-11-04 Items with (*) have a comment (or explanation) that is shown as a tooltip when hovering the mouse over them This comparison focuses on SQL features that can be used in SQL statements or self-contained SQL scripts that don't require additional software (e.g. a compiler) to be usable. Features for database administration or deployment are also not the focus of this compariso
)
定義域 (データベース) - Wikipedia
定義域（ていぎいき、ドメイン、英: domain）は、データ管理およびデータモデリング、データベース設計の文脈では、あるデータ要素が値としてとる可能性のある一意な値すべてから構成される、名前つきの有限集合をいう。 データ型と同じ意味と考えてよい。 現在は単に型（タイプ、type）と略されることも多い。 定義域の境界を決定する規則は、数え上げ（列挙）リストで定義されるデータ型と同じくらいに簡潔である可能性もある。 例として、関係データベース（リレーショナルデータベース）で人物についての情報を収める関係（リレーション、テーブル、表）を考える。 この関係では、一人の人物につき一つの組（タプル、行）が対応する。 組は、0以上の属性の集合からなるデータ構造である。 この関係は、ジェンダーという属性（列、カラム）をもつ。 属性は、属性名と定義域の名称のペアである。 属性は、その定義域に適合するなんらか
論理削除が奪うもの
論理削除が奪うもの JPOUGのAdvent Calendar 12/10担当です。 12月 - 忘年会シーズンです。酒で記憶を失っている際に、怒ったとか、近くにいた人にカラんだとか、脱いだとか、毛を燃やしたとか、エレベーターホールにズボンが脱ぎ捨てられていたとか、会議室で靴が発見されたとか、そういう事件が多発する月ですね。皆様いかがお過ごしでしょうか。 微塵も記憶がない状態で、やらかした内容を色々な人から聞かされるにつけ、穴を掘って蓋してセメントで埋めてもらいたくなるのは常ですが、こういう時はどんな対処を取ればいいんでしょう。 得てしてロクでもない行動を取った時の翌日における参加者の記憶力の良さと来たらFlight Recorderも真っ青です。 なんとか失敗を無かったことにしたいと立ち回りたいですが、まあ無理です。各所にヒアリングを重ねれば重ねるほど確度と精度が高まります。エビデンスま
主キー問題を整理する - A.R.N [日記]
だいぶん前から延々とくすぶっているIDキー問題あるいはサロゲートキー問題なのですが、一時期下火になっていたのですが、また再燃している感もあります。それだけ奥深い問題なのかもしれません。 複合主キー「否定派」と「許容派」の論争 IDの設計についてのさらに突っ込んだ議論 生きているうちに自然キーvsサロゲートキー問題に決着を付けたい(1) ただ、読んでみると同じような話題のように思えても意外に論点が錯綜しており、交通整理が必要なのではないかと感じます。私が見たところ 有意キー vs 無意キー グローバルキー vs ローカルキー 公開キー vs 非公開キー 複合主キーあり vs 複合主キーなし というところが論点かな、と感じています。あまり一般的な用語法ではないところもありますが、個々人で微妙に定義が異なる気もするので、一旦この名前で呼ぶことにします。 まず、第一の論点「有意キー vs 無意キー
![主キー問題を整理する - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2a57bf9a169ef03727217721c13ed52a4c192feb/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064257215%2F1555804233)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
杉本啓 on Twitter: "多次元集計も例のひとつ。1件のデータを5種類のキーで集計する。集計階層が５階層なら集計パターンは5の5乗。そのデータを保持すればDBがパンクする。これは昔から「多次元DBでのデータ爆発」として、その筋では知られている。これを回避す… https://t.co/6nAtHKWn9f"
theory in practice
トランザクションの設計と進化
xRef - Database