こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか？ データベースの内部実装はどうなっているのか？ トランザクションとはどのようなアルゴリズムで実現されているのか？ NoSQLが遅いのはなぜか？ 古典的なデータベースとは内部的にどのように違うの？ データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU（カーネギーメロン大学）のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義

PlantUML + ERDでPlantERDです github.com モチベーション PlantERDの特徴 使い方 出力するテーブル数の制限について 技術的に頑張ったこと テストのこと Foreign keyで隣接している別のテーブルを探す方法 複数DB対応のつらみ 追記：2019/12/13 9:45 モチベーション 既存プロダクトへの不満が一番大きいです。 https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい そもそもRails前提なので他言語とかでは使えない https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する 僕は初め

Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）

つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO

分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html Read less

PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ

#DataMigrationNight にて発表したスライドです

なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ

4月にMySQL 8.0のUnicodeと日本語対応についてManyi Luさんとディスカッションする会があって、かなりいろいろ話してとてもよい会だった。その後いろいろ考えて感じてる懸念を端的に書き記しておく。 デフォルトのcollationがutf8mb4_0900_ai_ciになった これに関して僕は強い懸念を持っている。MySQL 8.0以前において、ふつうのWebアプリケーションなどで日本語を扱う場合、実用上デフォルトのutf8mb4_general_ciかutf8mb4_binの2択であったと思う。デフォルトがutf8mb4_general_ciなので新しく作られるアプリケーションは通常は濁点半濁点が区別される状態で世に出てくることになる。けどMySQL 8.0.1のデフォルトのutf8mb4_0900_ai_ciは濁点半濁点を区別しないので、将来ユーザー名を登録するところでバイ

こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。 普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。 そもそも時系列データ・時系列データベースとは？ 時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。 timestamp1,key,value1 timestamp2,key,value2 timestamp3,key,value3 : 時系列データベースとは、上記のような時系列データの保存・処理に

JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転

はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC

岡山にはオープンセミナー岡山と言う最高のイベントがあります。 okayama.open-seminar.org 昨日は id:t-wada さんや id:naoya さんの資料がホットエントリー入りしてました。 この登壇はそれと同じイベントになります。 その他の方も超豪華講師陣の中で、私が出来る精一杯の経験も踏まえたお話をさせていただきました。 speakerdeck.com この中で出て来る、データベースリファクタリングは本当に素晴らしい本です。 OracleベースなのですがMySQLだろうがPostgreSQLだろうが必ずためになる本です。 ですが、この本は既に廃刊になっており再販の予定もありません… 僕は後世に絶対必要な本の一つだと思っているので再販のためにも皆さんの要望の声を上げていただけるとうれしいです。 そしたらもしかしたら本が世に復活するかもしれません。 またSQLアンチパタ

こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

最近、CourseraのArgorithms, Part1という講義を受けている。そこでソートの講義を受けて、そういえばMySQLのORDER BYでfilesortになったときってどのソートが使われているのだろうと気になってきたので調べてみた。 調べてみると非常に難解で、結局いまいち分からなかったが、今の段階の調べた内容をひとまず書いておく。MySQLのコードを読んだのも初めてで、しかもちゃんと読み解くことができなかったので、情報が間違っている可能性も非常に高い。間違ってたら指摘してもらえるとうれしいです。 調査結果 最初に調査結果を書いておく。たぶんこれは非常に単純化したもので、詳しく見るともっといろいろチューニングされてそう。 sort_buffer_size以内のメモリ量でソートが可能な場合、メモリ内でのみソートされる ソートにsort_buffer_size以上のメモリが必要な場

中国地方DB勉強会っていう控えめに言っても最高の勉強会があるんだけどそこで排他制約について教えてもらいました。 ikkitang1211.hatenablog.jp 排他制約って雑に説明すると重なりを拒否する制約です。 僕は使った事なかったのですが勉強会の中で事例紹介を受けて、めっちゃ便利だったのでここでご紹介します。 どんなときに使うの？ 実際にはどんなときに重なりを制御したいかというとよく使うのは次の2つ。 図面の重なり 時間の重なり 1つ目は幾何学的な図面を表現するときです。 実際にPostgreSQLは円や四角をSQLで表現できます。例えば地図上で特定の座標から半径100メートルの円を書き、その中に特定の円(場所)があればErrorにするような制約が書けます。 そもそもSQLで位置計算もめっちゃ便利なので是非使ってみてください。 soudai1025.blogspot.jp そして

こちらの本をご恵贈いただきました。 ビッグデータ分析・活用のためのSQLレシピ 作者: 加嵜長門,田宮直人出版社/メーカー: マイナビ出版発売日: 2017/03/27メディア: Kindle版この商品を含むブログを見る 一般的なSQLの本というのはDB管理の一環としてのインフラエンジニア向けの技術書であることが多く、意外にもデータ分析を主目的としたSQLの使い方やクエリの工夫の仕方について書かれた本というのはあまり多くないんですよね。故に、多くのデータ分析者は難解なテーマを実現するクエリを書きたくても参考になる資料が乏しく、途方に暮れるわけです。僕もHive / Redshift / BigQueryのクエリを書きながら「こんな分析がしたいんだけど、それを実現できるクエリってないよなぁ。。。」と何度天を仰いだことか。 そんなところに突然降って湧いてきたのがこちらの新刊書。もう目次を見ただ