[B! DB] akahigegのブックマーク

MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス技術戦略部ブログ]

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDB DB設計インデックスこんにちは、羽山です。今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

akahigeg 2021/09/01

MySQL
DB

リンク

データベースを遅くするための８つの方法

はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。大量の逐次コミットをするバッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが1時間越えに化けることもザラにあるので原

akahigeg 2020/11/15

シーケンスナンバーあかんの

DB

リンク

理屈で考える、データベースのチューニング | Raccoon Tech Blog [株式会社ラクーンホールディングス技術戦略部ブログ]

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。パフォーマンス勉強会OracleデータベースMySQLInnoDB こんにちは、羽山です。今回はOracleデータベースのチューニングで少し踏み込んだ内容です。途中で比較対象としてMySQLも登場します。日頃からSQLチューニングの機会があってそれなりに得意としているのに、それでもなぜかパフォーマンスがでないSQLに悩んだ経験はありませんか？謎の遅い現象は特に大規模データベースになってくると発生しがちなのですが、速い場合も遅い場合も必ず理由があります。そこで本記事ではデータベースのチューニングにおいて意外と見落とされがちなローレベルな部分に着目して、さらに一歩上のパフォーマンスチューニングに必要な知識を解説します。この記事を書くきっかけとなったのは私た

akahigeg 2020/10/03

リンク

本当にあったやらかしDB設計シリーズ一覧 - Qiita

本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としていますもしここに載っていないパターンを経験したことのある方がいたら是非教えてください本当にあったやらかしDB設計①【R無しRDB】本当にあったやらかしDB設計②【囚人番号テーブル】本当にあったやらかしDB設計③【ロジカルクエリー】本当にあったやらかしDB設計④【テストチューニング】本当にあったやらかしDB設計⑤【第三正規化病】本当にあったやらかしDB設計⑥【見えない削除フラグ】本当にあったやらかしDB設計⑦【ステートフルDB】本当にあったやらかしDB設計⑧【ファンクションDB】本当にあったやらかしDB設計⑨【文字列日付】

akahigeg 2020/08/11

全体的に説明が冗長な気がする。

DB

リンク

MongoDBを始めた頃に知っていたら、と思う14のこと

Spring BootによるAPIバックエンド構築実践ガイド第2版何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

akahigeg 2020/06/17

向き不向きを把握してRDBMSと使い分けられると良いのだが

DB
MongoDB

リンク

データベース設計の際に気をつけていること - 食べチョク開発者ブログ

皆さんこんにちは、エンジニアの西尾です。新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。データベースはシステムの土台です。土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。データベース設計には”これだ！”という正解はないと思っています。サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。その他もろもろの背景により、データベース設計の仕方も変わってきます。このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。アンチパターンと呼ばれるものも時と場合によっては正解になります。

akahigeg 2020/06/16

DB
開発

リンク

2020年現在のNewSQLについて - Qiita

Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成当記事は前編でNewSQLの概要編となる。全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

akahigeg 2020/02/29

DB

リンク

crontab database ～君がしでかしてくれたもの～ - Qiita

この記事は本番環境でやらかしちゃった人のアドベントカレンダー2日目の記事です。内容的にそろそろ時効だと思うので供養のために書きました。追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み︵ヲイ︶は2017年の話ですぶっちゃけネタ記事ですｗ︵たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる TL;DR DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し1年後に再実行されてしまい、本番データが1年前に巻き戻る事故発生。 crontab は分、時、日、月、曜日を指定できるが、1年後に帰ってくるから気をつけてね。という話。惨劇はなぜおこってしまったのか結論から言えばcrontabの

akahigeg 2019/12/02

怖い

DB

リンク

DBマイグレーションツールを比較した phpmig, migrate, goose - Qiita

はじめにフレームワーク無しの環境で開発をしている場合、手動でテーブル追加などの運用をしている現場も少なくないでしょう。手動運用をしているといつテーブル・カラム追加されたか分からない本番環境、複数の開発者の開発環境で、DB環境が一致していないなどの問題が起きます。これらは、マイグレーションツールを導入することで解決します。今回は、フレームワークに依存しないDBマイグレーションツール3つを比較・検証します。

akahigeg 2017/06/24

DB

リンク

DBA考

DBA考少し元気なので久しぶりに記事を書いてみる。 DBAとは何だろうとふと考えた。 DBA = DataBaseAdministrator ってのはわかる。けど、DBAを自称する人たちは何らかのシステムにおいて例えばRDBの世界でだけモノゴトを考えてしまう傾向に縛られてはいないだろうか。 SSOの認証情報をRDBにため込む？Active Directoryと連動させる可能性を模索しただろうか。頻繁にアクセスが発生するユーザ個々のトランザクションデータを効率よく扱えるためにバッファキャッシュに乗せる策を講じる？memcachedを入れたりあるいはクラスタリングしたWebLogicのセッション情報においておけば済まないだろうか？ここまで書いて思ったけど、私は多分DA(Data Administrator, 私の今作った造語)と仕事をしたいのかもしれないと思った。それはITアーキテクト

akahigeg 2014/09/02

開発
DB

リンク

主キーはインデックスではない - 設計者の発言

仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。﹁主キーをインデックスみたいなものと勘違いしているからではないでしょうか﹂。インデックス︵キー︶というのは、レコードの並び順を規定するキーのことだ。たしかに思い当たる節がある。﹁こんな順にレコードが並んでいれば処理上都合がよさそうだ﹂という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように﹁多め﹂に項目を突っ込んでおく。つまり﹁ユニーク制約をともなう代表的インデックス﹂程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ

akahigeg 2014/08/27

自分がやってる程度の開発だと全部idで十分だな。

DB
開発

リンク

従来のデータベースをメモリに載せるだけではだめなのか？インメモリとカラム型データベースの可能性を調べる（その2）

従来のデータベースをメモリに載せるだけではだめなのか？インメモリとカラム型データベースの可能性を調べる（その2）現代のサーバは1台で複数のプロセッサを備え、数百ギガバイトから数テラバイトのメインメモリを搭載可能です。これは多くの企業で利用されているデータベースがそのままメモリに載るほどの容量です。大量のメモリを搭載したサーバを用いれば、Oracle DatabaseやSQL ServerやDB2など従来のディスクベースのデータベースでも、データベースをまるごとメインメモリのバッファキャッシュに載せることができます。そうすればディスクアクセスのボトルネックは事実上ほとんどなくせるため、高速なデータベースアクセスが実現します。だとしたら、データベースをすべてメモリに載せる機能を備えたインメモリデータベースを、わざわざ使う必要はあるのでしょうか？この疑問は、以前の記事「キャッシュの大き

akahigeg 2013/05/20

だめなのか

リンク

ウノウラボ Unoh Labs: Migrateのご紹介

こんにちは、chihiroです。今回はデータベース・スキーマのバージョン管理ツールであるMigrateを紹介します。 Migrate http://erosson.com/migrate/docs/index.html インストール開発版の方を使いますので、レポジトリからコードをチェックアウトしてインストールします。 $ svn co http://erosson.com/migrate/svn/migrate/branches/monkeypatch_removal migrate $ cd migrate $ python setup.py install もしくは、easy_installで直接インストールします。 $ easy_install http://erosson.com/migrate/svn/migrate/branches/monkeypatch_removal

akahigeg 2009/07/16

python
DB

リンク

Martin Fowler's Bliki in Japanese - トランザクションレス

http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新：Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。トランザクションがない環境というのは驚くべきことではないだろうか。データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。多くの人にとって（私もそうだが）トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ

akahigeg 2007/03/26

DBの部分がスケールアウトの足かせになる以上、DBMSのやってくれることでも負荷が高ければプログラム側で、ということなのかな

DB

リンク

PHPとデータベースに関する5つの問題、とその解決法 - GIGAZINE

IBMのサイトに、PHPから操作するデータベースに関してよく見られる5つの問題点とその解決方法が掲載されています。データベースのデザインをする際、一般的に発生する問題点についての解説です。で、肝心の5つの問題が何かというと、以下の通り。 Five commonPHP database probl ems 1つめは古いPHPのコードでは直接、データベースにアクセスしているということ。コレに代わる手段としては、PEARのDBモジュールを使うか、あるいはPHPデータオブジェクト、PDOのクラスを使え、とあります。2つめは、オートインクリメントを使わないということ。MySQLは基本的にレコード1つについてユニークなIDをオートインクリメントしているわけですが、これを活用していないというパターン。オートインクリメントを有効に使っていない場合、非効率的であるだけでなく、負荷も高くなるそうです。解

akahigeg 2006/08/04

PHP
DB

リンク

ワンランク上の負荷対策を Web アプリに実装するには・・・(Sledge編)

最近、お仕事で悩ましいのがデータベース負荷。結局のところ、Web サービスでボトルネックになるのは、バックグラウンドのＤＢ処理。特にどうしようもないのが、更新系リクエスト。つまりはマスターＤＢ。既に多くのところが採用している構成と思いますが、MySQL とかでよくやる手段といえば、参照系は、レプリケーション機能を使って参照系ＤＢを用意して負荷分散。マシンを増やせば負荷に対応可能。更新系のクエリーだけは、できる限り高スペックなマシンを用意してマスターＤＢを構築して一手に引き受ける。増設困難で悩ましい。もうちょい頭をひねれば、機能毎にマスターＤＢを分散させたり、ユーザIDとかでパーティショニングしたりと、アプリ層で振り分ける。MySQL に限らず、Oracle とかでも同じようなことが言えます。で、マシン負荷を監視という運用業務が必須な日々を送っていた︵いや、実際にはPJのメ

akahigeg 2006/02/09

リンク