Partitioning GitHub’s relational databases to handle scale
EngineeringPartitioning GitHub’s relational databases to handle scaleIn 2019, to meet GitHub's growth and availability challenges, we set a plan in motion to improve our tooling and ability to partition relational databases. More than 10 years ago, GitHub.com started out like many other web applications of that time—built on Ruby on Rails, with a single MySQL database to store most of its data. Ov
データベースの文字数制限が191文字になっている理由とは？
世の中のデータベースを見ていると、格納するデータの文字数に「191文字以内」という制限が課されている場合があります。一体なぜ191文字という中途半端な数字で制限が行われるのかについて、オープンソースのデータ同期ツールを展開するGrouparooのCTOを務めるエヴァン・ターラーさんが解説しています。 Grouparoo Blog: Why do database columns have a character length of 191? https://www.grouparoo.com/blog/varchar-191 ターラーさんはまず、現代のデータベースシステムでは無制限に文字を格納する設定も可能だとした上で、文字数の制限で検索速度が向上すると説明しています。例えば、メールアドレスの行が「[email protected]」となっているユーザーを見つけたい場合、なんの工夫も無い状
MySQL のロックについて補足（注：すでに語りつくされている内容です） - Qiita
これは インフラ勉強会 Advent Calendar 2018 19 日目の記事です。 書いているうちに日付が変わってしまいました。 同カレンダーの 17 日目に、 「MySQL8.0 で起こる謎のデッドロックの条件を調べてみた」を data_locks・data_lock_waits テーブルで確かめてみた という記事を書きましたが、そもそも MySQL（InnoDB）のロックについて何も解説していないので、おそらく MySQL 初心者には全く意味の分からない記事になってしまったと思います（すみません）。 というわけで、すでに語りつくされている内容ですが、先の記事を理解するのに最低限必要になりそうなことを補足していきます。 ※MySQL に慣れている人にはいまさら解説不要な内容です。 MySQL（InnoDB）とトランザクション分離レベル 細かいことは説明しませんが、MySQL を含む
大規模データベースを安全にマイグレーションする仕組み - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Yakumo兼コネクト支援チームの@ueokandeです。 サイボウズには体験入部という制度があり、数週間〜数ヶ月の期間、他チームの業務を体験できます。 自分もこの制度を使い、1ヶ月ほどGaroon開発チームを体験してきました。 自分はこの期間で、Garoonの大規模なデータベースを安全にマイグレーションするための仕組みの設計と、そのプロトタイプを実装しました。 背景 Garoonはサービスのアップデートと同時に、データベースのマイグレーションを実行します。 ここでいうマイグレーションは、主に2つの処理があります。 テーブルスキーマの更新。ALTER TABLEによるカラムの追加、削除など。 データの変換。既存レコードのデータ編集など。 Garoonはメンテナンスウィンドウを設けてバージョンアップを実施します。 このバージョンアップが毎回確実に成功すればいいのですが、実際はそれ
MySQLでredis storage engineを作った - tom__bo’s Blog
MySQLのストレージエンジンはplugableになっていて、APIを実装すれば自作のストレージエンジンを組み込むことができる。 ということで、試しにRedisをストレージエンジンとして使うRedis Storage Engineを作りました。 github.com 途中で飽きてしまった ちまちま実装するよりC++の勉強とInnoDB読んだほうが良さそうと思ったので、お蔵入りするつもりでしたが、Yahoo! Japanでストレージエンジンを研究開発しているという話で個人的に盛り上がったので、改めて作ったところまでを見直して、整理しておこうという趣旨です。 実装したものはCREATE TABLEとDMLがある程度カバーされたおもちゃですが、自作ストレージエンジン開発のためのドキュメントはなくなっていく一方なので(MySQL internal documentを含む既存のドキュメント・ブログ・
MySQLの物理削除によるパフォーマンスの悪化とその回避策について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめまして、Yahoo!ショッピングでシステム開発を担当している村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える巨大なDBの運用の中で遭遇したMySQLのアンチパターンと、回避した方法について紹介いたします。 特定のテーブルをJoinするとすごく遅くなる Yahoo!ショッピングでは商品を出品するためのツールがあります。 商品情報には「商品名」「価格」といった、任意で設定可能な項目のほか、「ブランド」「商品種別」など、製品ごとに入力する内容が決まっている項目を、マスター情報としてテーブルで管理しています。 このマスター情報を利用して、出品の際に入力情報が正確であるかどうか確か
MySQL (MariaDB) でハマった仕様 - kamocyc’s blog
以前，MySQL (正確にはMariaDB) を使った際，いろいろはまったので記載します． 使ったバージョンが古い（MariaDB 10.1.37, MySQL 5.7くらいに相当）なので，最新版では治っているところもいくつかあります． sql_modeをデフォルトの設定で使わない これはよく言われていることですが，sql_modeがデフォルトでは変な値が入ったりエラーになって欲しいところがスルーされたりしてまずいので，適切なsql_modeを設定します． 第18回 MySQL5.7のデフォルトのSQLモードを確認してみる：MySQL道普請便り｜gihyo.jp … 技術評論社 MySQLのSQLモードをstrictモードで設定する。 - Qiita ただ，MySQL 5.7以降はデフォルト設定が改善されたようです．（でも確認すべきですが） MySQL :: MySQL 8.0 Refer
雑なMySQLパフォーマンスチューニング
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi
MySQLデータベースパフォーマンスのためのLinux OSチューニング | Yakst
Percona Database Performance Blogの翻訳。Linux上でMySQLサーバを運用する際の、カーネル、ファイルシステム、メモリなどのチューニングのポイントをまとめた記事。 [MySQL][Linux]原文 Linux OS Tuning for MySQL Database Performance - Percona Database Performance Blog (English) 原文著者 Spyros Voultepsis 原文公開日 2018-07-03 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー taka-h 原著者への翻訳報告 1868日前 原文へのコメントで報告済み 編集 この記事では、MySQLデータベースサーバーのパフォーマンスチューニングと最適化のために調整する重要なLinuxの設定を復習します。OSのチューニングに使う
Replication from Percona Server for MySQL to PostgreSQL using pg_chameleon
Replication is one of the well-known features that allows us to build an identical copy of a database. It is supported in almost every RDBMS. The advantages of replication may be huge, especially HA (High Availability) and load balancing. But what if we need to build replication between 2 heterogeneous databases like MySQL and PostgreSQL? Can we continuously replicate changes from a MySQL database
さいきんのMySQLのJSONまわり | GREE Engineers' Blog
こんにちわ。せじまです。 さいきん、しばしば庭園や日帰り登山に行って風景写真を撮っているのですが、カメラで写真を撮るという行為は（中略）実行計画を考えながらSQLを書く行為に近しいことだと思いますので、エンジニアの方にはけっこうオススメです。 今日は軽めの話をさっくりさせていただこうかと思います。 はじめに 皆さんは最近のMySQLがJSON型をサポートしているのをご存知でしょうか。「なぜ正規化されていないJSONをRDBMSに格納するのですか！正規化しましょう正規化」という至極ごもっともなご意見もあるでしょうが、 MySQLは5.7からJSON型のサポートをはじめ、8.0でかなり開発が加速している印象を受けます。JSON型がネイティブでサポートされるようになったのは、MySQL5.7のRelease Candidate以降です。5.7 RCがリリースされた2015年あたりから、MySQL
【MySQL】最低限の??デッドロック対策メモ - とりあえずphpとか
今まであまり気にしてこなかったけどちょっと問題になったのでメモ 今回は同じ様な内容のバッチ処理を多重でいくつも回す実装としたため、更新するテーブル・レコードも同じになってデッドロックが発生しました 今回の原因となったのは以下 複数テーブルへの更新処理は処理するテーブルの順番をそろえること ロックをかける(かかる可能性がある)場合は、検索結果が0件となるwhereは避けること 外部キーが貼ってあるレコードをinsertすると親レコードにもロックがかかることを意識すること 複数テーブルへの更新処理は処理するテーブルの順番をそろえること 処理A begin; update tableA set xxx where id = 1; update tableB set xxx where id = 2; commit;処理B begin; update tableB set xxx where id
MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
MySQLのメモリー使用量を最適化する設定のベストプラクティス | Yakst
Percona Data Performance Blogの翻訳。Percona CEOのPeter Zaitevによる、MySQLのメモリー使用量をどのように決めるべきか、またそれを決める時に気にするべきことは何かについてのまとめ。 この記事では、最適なMySQLのメモリー使用量を設定するためのベストプラクティスを扱おうと思います。 使用できるメモリーのリソースをどのように使うか正しく設定するのは、MySQLを最適なパフォーマンスでかつ安定して使うために最も重要なことのひとつです。MySQL 5.7では、デフォルトの設定では非常に少ない量のメモリしか使いません。デフォルトのままにしておくのは、最も良くないことのひとつでしょう。しかし、不適切に設定してしまうと、パフォーマンスを更に悪くする(あるいはクラッシュする)ことにもなりかねません。 MySQLのメモリ使用量を設定するにあたっての最初
第66回 MySQL準同期レプリケーションについて | gihyo.jp
MySQLのレプリケーションはデフォルトでは非同期で行われます。そのため、マスターの更新が必ずスレーブへ転送されたか保証はしません。 これを実現するしくみとして、MySQL5.5とそれ以降からは準同期レプリケーション機能を使用できます。今回は準同期レプリケーションについて紹介します。MySQLのバージョンは最新の5.7.21を使用しています。 準同期レプリケーションとは 準同期レプリケーションは、マスターの更新がスレーブに適用ではなく、伝搬されたことを保証する仕組みです。 コミットしたトランザクションはマスターから1台以上（オプションで変更可能）のスレーブに伝搬し、受け取ったスレーブ（I/Oスレッド）が通知をマスターに返したところでコミットが完了となる仕組みです。よって、スレーブ側で適用されたことまでは保証されないので、完全同期ではなく準同期と呼ばれます。 更新データの伝搬後にSQLスレッ
InnoDBのログとテーブルスペースの関係
InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
`PDO::ATTR_EMULATE_PREPARES => false`は必要か？
MySQLのALTER TABLEについて少々
WHERE id=? AND owner_id=? に天罰を - Qiita
GitHub - Percona-Lab/mysql_random_data_load: MySQL random data loader
