MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
2020年現在のNewSQLについて - Qiita
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
postgresのデータを盗まれた話 - のんびりやの日記
はじめに さっぶ。どうも、だーやまんです。 この記事は、本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiitaの11日目の記事です。 これは、中途半端な知識でサービスを運用していた結果、タイトル通りの大失敗をしてしまったお話です。個人開発での出来事なので、業務で起きたことかと胃薬を握られていた方はご安心ください。 語るのもすごい恥ずかしいレベルですが、戒めのために晒しておきます。 この記事を読んでほしい人 初めてインターネット上にサービスを公開しようとしている人 喋太郎の利用者様(この場をお借りして、改めてお詫び申し上げます。本当に申し訳ございませんでした。) 背景とか Discord読み上げBot 「喋太郎」にてやらかしました www.dayaman.work 利用者が約10万人 さくらのVPSにてAppサーバ2台、DBサーバ1台で運用 各サーバの死活監視
Amazonプライムデー初日にサーバーがダウンしたのは「DBをOracleから自社製に乗り換えた」ことが最大の理由 - GIGAZINE
By 禁书 网 日本時間で2018年7月16日の正午に始まったAmazonプライムデー2018では、セール開始直後にサーバーがダウンして約1時間にわたってアクセス障害が発生しました。Amazonが内部調査を行って作成した報告書によると、この問題は取引のデータベース(DB)を従来のOracle製から自社製に乗り換えたことが最大の理由である可能性が高まっています。 Amazon move off Oracle caused Prime Day outage in warehouse https://www.cnbc.com/2018/10/23/amazon-move-off-oracle-caused-prime-day-outage-in-warehouse.html Amazonプライムデー2018は同社にとって「史上最高」となるセールス記録を樹立しました。Amazonは売上高を公表しな
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
秒間100万クエリを受け付ける大規模ソーシャルゲームのバックエンドDBシステムの設計・運用ノウハウ
2016/08/26 CEDEC 2016
ゲームエンジニアのためのデータベース設計
GameServerDevelopers Vol.1 https://gsdevelopers.doorkeeper.jp/events/42497
アプリとサーバーの通信にJSONではなくSQLiteを使うと幸せになれるかも知れない条件まとめ - アニマネ開発日誌
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はじめに · PostgreSQL Internals
本当は恐ろしい分散システムの話
RDBアンチパターン // Speaker Deck
MySQLテーブル設計入門
