MySQLの大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
運用5年を迎えた「ジョーカー〜ギャングロード〜」で60%レイテンシ改善した話
ジョーカー~ギャングロード~(以下ジョーカー)でサーバーエンジニアをやっている嶋です。 ジョーカーは、最大25 vs 25の計50人で戦う抗争というGvGがメインのカードゲームです。 参加人数、行動回数が多いチーム同士の対戦(以下、アクティブな対戦)では、レイテンシがかなり高くプレイ体感が悪いことが発覚し、調査及びレイテンシ改善を行いました。 その結果、最大約60%のレイテンシ削減に至ったので、その時のことを書かせて頂きます。 まずはジョーカーのインフラ構成、GvGにおける排他制御の方法を説明します。 ジョーカーのインフラ構成 ジョーカーではAWSを使っており、GvGにおける構成は下記のようになっています。 APIサーバー50台(EC2) user用DB guild用DB(各4台) gvg用DB(元々各4台、集約後Amazon Aurora1台) Redis 4台 GvG関連のデータの更新
「SQLアンチパターン」を避けるためのチェックリスト（サマリー版） - log4ketancho
これまで「SQLアンチパターン」本のまとめを書いてきました。 「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト④（アプリケーション設計編） - log4ketancho この記事は、自分用のチェックリストとして、これまでの記事をサマライズしたものになります。本にこのチェックリストが書かれているわけではなく、個人的に解釈したものになりますが、もしよろしければ DB 設計の一助にしていただければ幸いです。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
SELECTをアスタリスクと列指定したときの速度差 - kagamihogeの日記
SQLアンチパターン18章 インプリシットカラム（暗黙の列）では、SELECT,INSERT,UPDATEするときは、*（アスタリスク）を使わず、必要な列のみを列挙したほうが良い、といったことが書かれている。その理由については色々書かれているが、このエントリでは実行速度について考える。 検証内容について。同一長の列を二つ持つテーブルを作成し、1つはアスタリスク、1つは1列だけを指定するSELECT文を実行する。このとき、二つのクエリに速度差がどのくらい出るかを確認し、その理由について考える。 環境 Oracle Database Express Edition 11g Release 2をCentOS 6.4 x86_64上で動作 Oracle SQL Developer 3.2 SQL*Plus: Release 11.2.0.2.0 Production 準備 同一長の文字列型を二つ持
SQLの基礎 「SELECT」文を覚えよう
本記事のおもな内容 いろいろあるSQLの規格 サンプルデータベースを操作してみる SELECT文の基本的な使い方 WHERE句の使い方 条件の指定方法 リレーショナルデータベースシステム（RDBMS）も、今や、システムの構築には不可欠なものとなりました。皆さんが目にしているシステムや、管理しているシステムでも、RDBMSが使われていないシステムを探すほうが大変ではないでしょうか。RDBMSの普及にともない、RDBMSへのアクセス手段であるSQLも、日常的によく見かけるものとなりました。 このSQL実践講座では、SQLの効率的な使い方をエッセンスにしてお伝えしていこうと考えています。SQLは、データを操作するために非常に簡単な構文で構成されているように見えます。ところが、実際に使い込んでいくと、一見簡単に取得できるように見えるデータが取得できない場面にぶち当たることがあると思います。また逆に
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース設計徹底指南
ソーシャルゲームのためのデータベース設計