第5回DB側でやること、アプリ側でやることを見極めよう 生島勘富 2019-09-20
ゲームを題材に学ぶ 内部構造から理解するMySQL 記事一覧 | gihyo.jp
第5回DB側でやること、アプリ側でやることを見極めよう 生島勘富 2019-09-20
さいきんのMySQLに関する取り組み（仮）
2015年12月8日、「【ヒカ☆ラボ】さくらインターネットとMilkcocoa！年末イベント：ここだけのウラ話」で、さくらインターネット研究所所長 鷲北 賢が、「○ヶ月でできた！？さくらのクラウド開発秘話」と題し、プレゼンした際の資料です。 ■イベント詳細 http://mlkcca.connpass.com/event/22959/
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
第3回 実行計画を見てSQLの構造を理解しよう | gihyo.jp
本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。本記事と併せてご活用ください。 実行計画はSQL理解の大きな手がかり SQLはほかの手続き型言語と大幅に違います。そのため、ほかの手続き型言語と同じ感覚で使うと違和感が大きくなり、アレルギーのように嫌う人も出てきます。最近では、手続き型言語でORMを使うとSQLを意識しないでRDBMSをストレージのように扱うことが可能なため、SQLを理解する前にORMを使ってしまった人の中には、SQLをまったく理解していない人もいるようです。 しかし、正しい理解をしないまま使うとい
Why Uber Engineering Switched from Postgres to MySQL
We’ve represented the old version in red and the new row version in green. Under the hood, Postgres uses another field holding the row version to determine which tuple is most recent. This added field lets the database determine which row tuple to serve to a transaction that may not be allowed to see the latest row version. With Postgres, the primary index and secondary indexes all point directly
Assessing MySQL Performance Amongst AWS Options - Part Two
See part one of this series here. This post is part two of my series “Assessing MySQL Performance Amongst AWS Options”, taking a look at how current Amazon RDS services – Amazon Aurora and Amazon RDS for MySQL – compare with Percona Server with InnoDB and RocksDB engines on EC2 instances. This time around, I am reviewing the total cost of one test run for each database as well as seeing which data
MySQLのコネクションハンドリングとスケーリング | Yakst
MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関
MySQLのbinlogとredo logについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #１．基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスク
innodb_thread_concurrencyに関する話 | GREE Engineering
こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話（入門編）を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno
Load Balanced ProxySQL in Google Cloud
There are three different ways ProxySQL can direct traffic between your application and the backend MySQL services. Locally, on the MySQL servers. Between the MySQL servers and the application. Colocated on the application servers themselves.Without going through too much detail – each has its own limitations. In the first form, the application needs to know about all MySQL servers at any given po
RDS for MySQLで変更すべきパラメータチューニング - なからなLife
呼ばれたきがしたので soudai.hatenablog.com なお、InnoDB限定のお話ですよ。MyISAMを（システムテーブル以外で）使ったことない若輩者なので。 ちょっと余裕がないこともあり、思いつく最小限のことだけ書きます。追加で思いついたら後ほど＆温かいフォロー（というマサカリ？）歓迎。 checkpointに影響がある値 innodb_log_file_size Redoログのファイルサイズです。 生MySQLのデフォルトは「50331648 Byte（48MB）」、RDSのデフォルトは「134217728 Byte（128MB）」。大きなバッチ処理がなければ間に合うかも知れないですが、広げたほうがよいでしょう。 適切な値の範囲は、1M バイトから 1/バッファープールの N 番目のサイズまでです。ここで、N はグループ内のログファイルの数です。 https://dev.m
CloudWatch Logs Insights を使って MySQL の performance_schema を分析する | はったりエンジニアの備忘録
CloudWatch Logs Insights を使って MySQL の performance_schema を分析する freee のプロダクトは RDBMS に MySQL を使っています。これまでもさまざまな方法でパフォーマンス改善を行ってきましたが、新たに CloudWatch Logs Insights を使って MySQL の performance_schema を分析する仕組みを作りました。 具体的には CloudWatch Dashboard を使って問題のありそうなクエリを見える化しました。次のスクリーンショットは一例ですが、このリストは CloudWatch Logs Insights にクエリを投げた結果です。 当初は DWH 用の Redshift に取り込んで Redash で分析するつもりでしたが、CloudWatch Logs Insights を使うこ
フレームワークは素晴らしいけど抽象化した箇所は忘れないでねって話をします - そーだいなるらくがき帳
Laravelカンファレンスでの登壇資料です。 conference2019.laravel.jp ガッツリ、データベースの話とかPerformanceの話でロックとか内部構造の話してもいいかなって思ったけどLaravelのカンファレンスなので表題の事をテーマに資料を作りました。 この辺の話は知ってる人からすると知ってる話なので先に資料を見てから話を聴くSession決めるのがオススメです。 内容自体はフレームワークを使ってたらハマりがちなRDBMSのボトルネックについてざっくりまとめました。 30分で話するにはテーマが大きいのでこのセッションで気になることとか、その他知りたいことがあれば当日気軽にご質問ください。 Ask the Speakerでも良いし、ロビーで普通に話掛けていただいてもいいし、Twitterでも構いません。 JOINのアルゴリズムは id:ikkitang1211 の
MySQL10本ノック作ってみた！ - Qiita
2019/02/28 更新 MySQL8バージョン作りました！ https://qiita.com/yasumon/items/33579a2cb85b320f262c はじめに 皆さん、どうもです。ｋ．ｓ．ロジャースのやすもんです。 今回は、業務でそれなりによく使うMySQLを設問形式でまとめていこうと思います。 ちなみにバージョンはmysql5.7.19です。Window関数を使えないという不便な状況でがんばりましょう！ また、初級から上級編で用意しています。 事前準備 mysql公式のサンプルデータベースをimportする http://downloads.mysql.com/docs/world.sql.gz ↑からファイルをダウンロードし、gzを展開してworld.sqlというSQLファイルを実行すると、worldというDBが生成され、以下のようなデータが格納される 今回はFK周
スロークエリログを詳細化するlog_slow_extraパラメータ - 41から始めました
log_slow_extraパラメータが8.0.14から追加された 何それ？おいしいの？ スロークエリーログが有効で出力先が含まれているFILE場合、サーバーはスローファイルに関する情報を提供するログファイル行に追加のフィールドを書き込みます。セクション5.4.5「遅いクエリーログ」を参照してください。 TABLE出力は影響を受けません。 https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_slow_extra 要するにファイル形式のスロークエリの場合、ログを詳細に出力するようになったよ、ってことらしい。 でもこれだと何が出力されるようになったのかわからん。 試してみる スロークエリを出すように変更 mysql> set global slow_query_log_file = '/
MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ
MySQL のストレージエンジン（SE）を自作してみたときのメモ。バージョンは 8.0.13。 アーキテクチャをざっくりと掴むことが目的なので、ストレージエンジンの自作といっても非常に単純な操作しかできないものです。 RDB らしさとも言えるインデックスや行レベルロック、トランザクションなどの高度な処理は実装せず、簡単に入出力の流れを追っていきます。 ゴールは以下の基本的な機能を実現して、「あ、こんなもんなんだ〜」感を覚えることです。 CREATE 文でテーブルの作成 INSERT 文で行の挿入 SELECT 文で行の取得 ちなみに MySQL のコードは C/C++ です。（といっても、テンプレート等の C++ らしい拡張的な機能は使われておらず、ほぼ C で書かれています。クラスは頻繁に使われているので、俗に「クラスのあるC」なんて言われている模様。そのため、C をある程度理解していれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLの容量とか圧縮まわり
InnoDBのすゝめ（仮）
その行がマスターにINSERTされてからスレーブでSELECTされるまで
MySQLにWEBアプリのログを保存しているケースの8割くらいが幸せになる方法
