MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭
今回答えを出したい問いはこちら！！ インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ！！！！それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな！ indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
後輩エンジニアを絶望させるDB設計方法4選 - Qiita
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
Cloudflare D1 がヤバい
まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto
PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita
PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」（ヴィテス）を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
ポケモンを題材に「SQLアンチパターン」を実践してみる - kanayamaのブログ
@tkanayama_です。「SQLアンチパターン *1」 という本を読みました。「ポケモンを題材に因果推論を実践してみる」のように、仮想的なストーリ上で実際に使ってみた感を出すことにより、自分の記憶に定着させることを狙います。 前提として、何をアンチパターンとするかは状況（ベンダーフリーである必要があるかどうか、どの程度の頻度で更新されるか・・・など）によって大きく異なるので、下記で紹介するアンチパターンは実は状況によっては問題にならないケースもあるかと思います。この投稿はあくまで「SQLアンチパターン」に忠実に従うことが目的です。 www.oreilly.co.jp 追記 登場人物 ストーリー フシギダネへの対応 ヤミカラスへの対応 ディグダへの対応 誤登録でポケモントレーナーになってしまったユーザーの削除 最後に 謝辞 追記 このブログを公開後、「外部キー制約はレコードロック周りのト
外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
進まない、マイグレーション - Qiita
Railsで運用していた本番環境を、マイグレーションの加減で止めてしまいました。 経緯 AWS上にRailsで作ったプロジェクトがありまして、環境管理をElastic Beanstalkで行っていました。毎週1回、人の少ないタイミングに更新を行っていたのですが、あるときに反映したところで、マイグレーションが全く進まなくなってしまいました。 原因 もちろん、開発環境で同じマイグレーションは回していたので、マイグレーションの記載ミスではなかったのですが、本番環境にアクセスがあった中でマイグレーションを動かしてしまったこと、そして作成するマイグレーションが新しいテーブルを作るようなものではなく、既存のテーブルの定義を書き換えるものだったがために、ロックが絡み合って一向に進まなくなってしまったのでした。 その場での対応 ひとまず、強引にデータベースサーバを再起動して元の状態に戻して、古いバージョン
スイッチ交換でMySQLのレプリケーションが壊れた顛末
2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「スイッチ交換でデータベースがすごく苦労した話」に登壇したのは、株式会社アイスタイルのsuzukito氏。講演資料はこちら スイッチ交換でデータベースがすごく苦労した話 suzukito氏：レイヤ3スイッチの交換でデータベースがすごく苦労した話をしたいと思います。 自己紹介です。鈴木と申します。アイスタイルのデータベースエンジニアをやっています。 お話しすることは、スイッチ交換でMySQLのレプリケーションが壊れました。その顛末を共有したいと思います。 まず、ある日、インフラのほ
交差テーブルには関連の意味を表す名前をつけよう - Qiita
問題 多対多の関連を作るときの交差テーブル（中間テーブル、関連テーブルなどとも呼ばれる）にどのような名前をつけていますか？ 2つのテーブル名を単純につなげた users_magazines のような命名を見かけますが、これはあまり良い名前ではありません。 実体関連モデル - Wikipedia 実体 (entity) は名詞に対応すると考えることができる。例えば、コンピュータ、従業員、楽曲、数学的定理といった名詞である。 関連 (relationship) は2つの実体間の関係を捉えたものである。関連は2つ以上の名詞句を結び付ける動詞に対応すると考えることができる。例えば、企業とコンピュータの間の「所有する」(owns) という関連、従業員と部門の間の「監督する」(supervises) という関連、アーティストと楽曲の間の「演奏する」(performs) という関連、数学者と定理の間の「
O/Rマッピングは百害あって一利なし！ - Qiita
O/Rマッピング(Object-relational mapping)について、Wikipediaには以下のように書かれています。 データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。 O/Rマッピングを実現する仕組みを、O/Rマッパーと言います。（両者を区別しなくても私が言いたいことは伝わると思いますので、ORMと統一して記述します）（また、個人的な理由で、プログラミング初学者向けに語りかける口調にしていますが、初心者向けの記事というわけではありません） 最近はWEBアプリ開発をするにあたって、WEBフレームワークに標準で何らかのORMが組み込まれていることが多いため、その存在を知らない人はまずいないでしょう。 私も何度かORMと向き合ってきましたが、そうこうしているうちに気がつきました。 ORMはめんどうくさい！ …ってことに。 みん
データーベースをCPだのAPだのと分類するのはやめて下さい - suzuki79のブログ
Please stop calling databases CP or AP (2015-4-11) by Martin Kleppmann 元の記事は上のリンクよりご覧になれます。こちらの記事は 本人の許可を得て、翻訳・掲載したものです。翻訳へのフィードバックはコメントよりお願いいたします。 Jeff HodgesのNotes on Distributed Systems for Young Bloodsという優れたブログで、CAP定理を使ってシステムを評価することが推奨されています。多くの人はこのアドバイスを真摯に聞き、自分たちのシステムをCP（ネットワークの分割のもとでは一貫性はあるが可用性がない）、AP（ネットワーク分割のもとでは可用性があるが一貫性がない）、あるいはまれにCA（これの意味するところは「自分はまだ５年前のCodaの投稿を読んでいません」です）と表現するようになりまし
時系列データベースに関する基礎知識と時系列データの符号化方式について - クックパッド開発者ブログ
こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。 普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。 そもそも時系列データ・時系列データベースとは？ 時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。 timestamp1,key,value1 timestamp2,key,value2 timestamp3,key,value3 : 時系列データベースとは、上記のような時系列データの保存・処理に
SanrioTownのデータベース露出についてまとめてみた - piyolog
2015年12月19日、CSO Onlineで取り上げられたSanrioTownのデータベースが露出していた問題についてここでは関連情報をまとめます。 公式発表 2015年12月22日 Security Advisory: Corrected a vulnerability involving personal information of SanrioTown.com members SanrioTownとは何か 次のURLよりアクセスできるWebサイトよりサービスが提供されている。 http://www.sanriotown.com/ 公式のFacebookページの説明によれば、2002年よりサービスが提供されている主に海外のサンリオファン向けのソーシャルネットワークサービス。オンラインゲームであるHello Kitty Online(SanrioTown中ではHKOと略されている)も
データベース アーキテクチャーの動向と使い分け
QConTokyo ( http://www.qcontokyo.com/KotaUENISHI_2015.html ) の発表スライド
そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記
WEB+DB PRESS Vol.75の「理論で学ぶSQL再入門/履歴データとの上手なつきあい方」が面白かったと感想を書こうと思っていたらもうVol.76が出そうなのでいい加減慌てて書きます。 さてこの記事では、リレーショナルモデルが苦手とするデータ構造の1つとして履歴データを挙げています。 もしかすると「履歴データ」であるということを気づかずにデータベースの設計、クエリの記述をしたことがあるかもしれません。 この記事ではショッピングサイトの価格表を例としています。 価格表が常に現在の価格のみを扱うのであれば問題ありませんが、ある期間に価格を変えたことも価格表に含めるのであればそれは「履歴データ」となります。記事から一部引用するとこんな感じ item price start_date end_date 懸垂マシーン 18000 2010-01-01 2011-12-31 懸垂マシーン 20
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴を持つデータの設計
