これはなに ども、レバテック開発部のもりたです。 今回はトランザクション分離レベルについてまとめました。トランザクション分離レベルって基本情報技術者試験とかで学ぶものの、座学だけだとあんまりピンとこずに忘れちゃいますよね。もりたも長らく曖昧な状態で生きていたのですが、よい理解の仕方があったので今回はその解説をします。 トランザクション分離レベルを構成するふたつの変数 トランザクション分離レベルとは まず初めに、概要を掴むところからいきましょう。 トランザクション分離レベルとは、あるトランザクションのデータベースに加えた変更が、他のトランザクションにどの程度影響を与えるか？ というもの（分離性、独立性）を一定基準でレベルに分けてまとめたものです。 どの程度影響を受けるか？ については三つの影響が定義され、その影響度合いに応じて分離レベルが４つ存在します。これは大体こんな図で解説されます。 よ
# 失敗から学ぶRDBの正しい歩き方 - https://amzn.to/4e0CqfH
𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ @ellnore_pad_267 みんなさぁ・・・ データベースって何で学んだ？ あんま学ぶチャンスなくね？ そんなことはないか？ 単なる SQL やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 2024-09-09 20:18:38 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ @ellnore_pad_267 > 単なる SQL やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 この部分読めてない奴が一定数おる？？？？ 2024-09-10 10:12:46
ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に
MySQL/Aurora/TiDBロック入門 – 第２回ロックモニターの読み方【動画解説付】 MySQL とその互換 DB のロックやトランザクションの挙動を紹介する入門シリーズ、「第１回 トランザクション分離レベル」 では READ COMMITTED や REPEATABLE READ でどういう挙動になるか紹介しました。 第２回目の今回は MySQL InnoDB のロックモニターの読み方、使い方について解説します。MySQL のロック機構を理解するツールとして便利なのでぜひご一読ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７
こんにちは。 AI事業本部の協業リテールメディアdivでバックエンドエンジニアをしている yassun7010 といいます。 先日、 AI 事業本部の新人研修で「データアプリケーション」の講師を同じチームの 千葉 と担当しました。 今回の記事では、主に私が担当した「データベースの歴史」の章の講義資料を公開し、資料を作成する際に考えていたこと・伝えたかったことを話します。 「データベースの歴史」で説明されている内容は、AI事業本部の新卒研修で毎年取り上げられているものです。こういった研修の資料は、同じテーマであっても講師をする人の好みが反映されやすく、今年の資料も先人が作られた昨年の資料を参考にしつつ、私が好きな話題を多く取り入れたものに仕上がりました。 SlideShare でも公開しています。 今年の構成は、データベースを RDS・NoSQL・NewSQL として分け、下記のような構成を
Table users { id integer [pk] first_name varchar last_name varchar email varchar [not null] password varchar [note: 'Hashed password'] created_at datetime [not null, default: `now()`] updated_at datetime Indexes { email [unique, name: "ui_users_email"] } Note: 'table: users' } 上記のテーブル定義を dbdiagram.io の左側のコード記載部分に張り付けると右側にプレビューが表示されます。 以下は dbdiagram.io でのプレビューをした時の表示です。(Noteの箇所は説明のため加工しています) (1) Ta
これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？ 帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなど
そうです。わずか10行しかないデータですが、 15,000列 あります。 「それデータモデリングをミスってるやん」というツッコミはあると思いますが、今回はそのあたりについてはノーコメントです。諸事情ありこのようなデータを扱うことになりました。 今回は Snowflake でもなかなか扱うことが難しい (横方向に) クソデカデータの世界 をご案内したいと思います。 クソデカテーブルを作る まずテーブルを作ります。 この時点でエラーが出てくれるならまだ良かった。。。 なんとこのクエリは問題なく実行でき、テーブルは作成できます。 作成できてしまいます。 作成できてしまったが故に、「さすが Snowflake、列数が多いテーブルも簡単に扱えるんだね!!」と高をくくってしまいます。 ちなみに PostgreSQL の場合は1テーブルあたり最大 1,600 列だそうです。まぁそれだけあれば普通は困らな
こんにちは、kenzauros です。 今月号のソフトウェアデザイン誌を読んでいて、ある言葉が気になりました。 日本の IT エンジニアの 8 割（主観）が間違えている言葉、それが「リレーション」と「リレーションシップ」です。いずれもリレーショナルデータベース (RDB; relational database) の文脈で使われます。 この 2 単語は実際に弊社の勉強会や教育の場面でも何度か話題になったことがあります。今回、出版物である雑誌でも揺らぎがあったので、あらためて調べてみました。 なお最初に断っておきますが、本記事は誤りを否定するものではなく、できるだけ正しい用語を使っていければいいな、という話題の提起が目的です。 「リレーション」と「リレーションシップ」 はじめに主題である「リレーション」と「リレーションシップ」について、この記事での理解を説明しておきます。 ざっくり言えば 「
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
2019年10月23日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第28回となる今回のテーマは「形から入ったドメイン駆動設計によるゲーム開発の光と闇」。株式会社Nextat取締役・中榮健二氏が、ドメイン駆動設計（DDD）をゲーム開発に取り入れた事例を語りました。登壇資料はこちら 10分経っても返ってこないAPIのチューニング 中榮健二氏（以下、中榮）：次にいきます。「10分経っても返ってこないガチャAPIのチューニングの話」です。 キャラクターや装備を配布するガチャのAPIがあって、POSTでやりますと。 とりあえず、ガチャAPIの修正を頼まれたので、回しちゃうぞ〜と。フロント側で見ていると、HTTP Status 500。PHPで何が起こったか見たら、「30秒過ぎちゃった」
はじめに これは ドリコム Advent Calendar 2021 の24日目です。 23日目は AnD00 さんの プロジェクトの行動規範を作ってチームの理想を描いてゆく です。 弊社内ではユーザの主要なデータの保存先としてRDBが使われるケースが多く、NoSQLを中心としたシステムを開発した経験のあるエンジニアが限られています。しかし新たなシステムを開発するとき選択肢としてNoSQLを選べることは有用だと思われるので、NoSQLを選択したときどのような課題があるか調査し、対策を検討しておくことにしました。 大小様々な課題があることは想像できますが、本稿ではAmazon DynamoDBのスキーマ設計に焦点を当て、実際に設計して直面した課題と、その解決方法を紹介します。 対象読者 RDBを使ったアプリの開発／運用経験があり、DynamoDBを使ってみたい人 背景 冒頭の通り、社内ではR
［速報］AWS、データベース性能問題を数分で検出、分析、解決までしてくれる「Amazon DevOps Guru for RDS」発表。AWS re:Invent 2021
［速報］AWS、データベース性能問題を数分で検出、分析、解決までしてくれる「Amazon DevOps Guru for RDS」発表。AWS re:Invent 2021 Amazon Web Servicesは、データベースの性能に関する課題を自動的に検出し、原因を分析し、解決してくれる新サービス「Amazon DevOps Guru for RDS」を、開催中のイベント「AWS re:Invent 2021」で発表しました。 Amazon DevOps Guruは、昨年のAWS re:Invent 2020で発表されたサービスで、設定ミスなどを機械学習によって検出してくれるものでした。 参考：［速報］「Amazon DevOps Guru」発表。DevOps関連の設定ミスやコードの問題などを機械学習が指摘してくれる。AWS re:Invent 2020 今回発表されたAmazon D
Copyright 2019 DELiGHTWORKS Inc. All Rights Reserved. Fate/Grand Orderにおける 大規模なデータベース移行と負荷試験 2019年6月14日 今井 守生 Copyright 2019 DELiGHTWORKS Inc. All Rights Reserved. 資料は公開予定です 本セッションでは以下の内容をお話します AWS Database Migration Serviceを使った大規模なDB移行事例（垂直分割→水平分割） 移行後に想定トラフィックを捌けることを検証するための負荷試験手法 弊社エンジニアが過去に2回、DB移行を主なトピックとした講演を行っています のでこちらもご参照ください これで怖くない！？大規模環境で体験するDB負荷対策～垂直から水平の彼方へ～ /甲 https://www.slideshare.n
はじめに いろんな話題が出ているコロナ予約サイトですが、横浜市の予約サイトが公開すぐに落ちたことでまず話題になりました。 ただ、最大34万人の予約者なので 1分あたり最大100万件のアクセスを想定していたが、開始直後に200万件のアクセスがあったということで33,000TPSというかなりのトラフィックが来た事が予想されます。 対応策がサーバを増やして目標値を当初設計の6倍に引き上げるとの事だったのですが、空席照会のついた予約システムってDBにある程度同期的に書き込む必要があるので、そんな簡単にスケールアウト出来ないはずです。 JSとかCSSとかも含めてるならさておき、メインのページなどのHTMLなどを含めたPVだと仮定してもDBに数千アクセスが行きますし参照だけではなく更新も入ります。どうやったのか本当に謎なんですが、特に工夫のないアプリ実装でどのくらいスケールするのか少し気になったので試
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ファントムファイル 目的：画像をはじめとする大容量のメディアファイルを格納することを目的とする アンチパターン：物理ファイルの使用を必須と思い込む 画像データを保存する際にみなさんどのように保存しているだろうか。 DBにBLOB型として保存？ 外部のファイルシステムに保存し、DBにはファイルパスを保存？ 筆者は後者の外部にファイルを保存し、DBにはファイルパスを格納していた。 おそらく多くの方が後者を採用しているのではないか。 どちらもメリット、デメリットがある。 ファイル削除時の問題 画像をDBの外に保存している場合、DBで画像のファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
