【AWS Summit Tokyo 2019 セッションレポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit | DevelopersIO
AWS Summit Tokyo 2019 Day2 （本日6/13）のセッション、「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」をレポートします。面白かったです！ ライブストリーミングでのセッション参加のレポートです。 セッション概要 このセッションでは、クラウドの技術革新を活用するためにゼロから設計された、クラウドネイティブデータベースサービスであるAmazon Auroraについて詳しく説明します。 Auroraはその記憶域として分散型マルチテナントログ構造化ストレージサービスを使用するなど、モノリシックデータベーススタックをサービス指向アーキテクチャに移行しています。 Auroraは、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、
InnoDB はどうやってファイルにデータを保持するのか
Extended outer memory module for my poor native memory. Posts: 2022/02/13 クラビスの CTO になりました 2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った 2020/09/13 ISUCON10 の予選を 7 位で通過した 2019/12/01 Puma の内部構造やアーキテクチャを追う 2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む 2019/04/29 InnoDB の B+Tree Index について 2019/04/29 InnoDB における index page のデータ構造 2019/04/28 InnoDB はどうやってファイルにデータを保持するのか 2019/01/06 Designing Data-Intens
なぜUber EngineeringはPostgresからMySQLに切り替えたのか | POSTD
はじめに Uberの初期のアーキテクチャは、Pythonで書かれたモノリシックなバックエンドアプリで構成されており、データの永続性のために Postgres を使っていました。当時から比べて今のUberのアーキテクチャはかなり変わっており、 マイクロサービス のモデルや新しいデータプラットフォームになりました。特に、以前Postgresを使っていたケースの多くで、今は Schemaless 、つまりMySQLの上で構築された新しいデータベースのシャーディングレイヤを使います。今回の投稿では、私たちが見つけたPostgresの欠点を探り、MySQLの上でSchemalessと他のバックエンドサービスを構築するに至った経緯について説明していきます。 Postgresのアーキテクチャ 私たちはPostgresで以下のような多くの制約に直面しました。 書き込みでの非能率的なアーキテクチャ 非能率的
MySQL 5.7 をインストールしたら最初に行うセットアップ |
前稿では「MySQL 5.7 を CentOS 7 に yum インストールする手順」について解説しました。 本稿では、MySQL 5.7 をインストール後に行うべきセットアップについて解説します。 MySQL 5.7 の root ユーザーの初期パスワードを知る MySQL 5.7 では、初回起動と同時に root ユーザーにランダムな文字列がパスワードとして設定されます。 設定されるパスワードはインストールを行う度に全く違うものです。 それでは設定されたパスワードは何なのでしょうか？ 初期パスワードは MySQL のログファイルに出力されています。 ログファイルは、CentOS だと /var/log/mysqld.log です。 ログを開くと次のようにパスワードが記載されています。 [Note] A temporary password is generated for root@l
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 - エンジニアHub｜Webエンジニアのキャリアを考える！
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 MySQLの最新版「MySQL 8.0」正式版が2018年4月にリリースされました。数多くの機能や設定が追加・変更されているMySQL 8.0の「知っておきたい便利な機能」や「危険なハマりどころ」などを、My SQLの専門家に教えてもらいました。 2018年4月、世界中のエンジニアが待ちに待ったMySQL 8.0の正式版がリリースされました。本リリースに伴い、数多くの機能や設定が追加・変更されており、MySQLがより便利なものへと進化しています。 MySQL 8.0で積極的に利用すべき目玉機能や、知っておかなければ危険なハマりどころなど重要な変更点を、MySQLの保守サポートやコンサルティングなどを専門とする株式会社スマートスタイルの中野真也さんと成田優隆さんに解説してもらいました。 中野真也（な
Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました
Rails Developers Meetup 2018: Day 1 で「MySQL/InnoDB の裏側」と題して SELECT クエリの実行フローや InnoDB のインデックス周りの発表しました。MySQL with InnoDB のインデックスの基礎知識とありがちな間違い + α の内容です。 Nested Loop Join のスライドは無理やり差し込んだ感が溢れてますがご了承ください＞＜ 追記: 動画も公開されたので貼り付けておきます。1 key_len について発表で全然触れなかったんですが、重要な内容なので次のエントリーにまとめました。 MySQL で複合インデックスを作成する際には必ず key_len を確認すべきという話 補足 サンプルデータ MySQL のサンプルデータとしては world や employee が有名だと思うんですが、前々から world は物足り
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
MySQL でテーブルやカラムの情報を確認する方法まとめ :: by and for engineers
Sep 1, 2015 MySQL で作成済みのテーブルやカラムの定義を調べる方法をまとめました。知っておくといろいろ捗るかも。 DESC +-------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+-------+ | id | int(11) | NO | PRI | 0 | | | name | varchar(64) | NO | UNI | NULL | | | age | int(11) | NO | | NULL | | | photo | varchar(255) | YES | | NULL | | +-------+--------
Top 20+ MySQL Best Practices | Envato Tuts+
Database operations often tend to be the main bottleneck for most web applications today. It's not only the DBA's (database administrators) that have to worry about these performance issues. We as programmers need to do our part by structuring tables properly, writing optimized queries and better code. In this article, I'll list some MySQL optimization techniques for programmers. Before we start,
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
「WHERE 1=1」は条件付きSQL文が書きやすくなる魔法の言葉 | キノコログ
今回で10記事目の投稿になります。 最初は検索エンジンに少しでも多くインデックスしてもらいたく、頑張って記事を量産している段階です！ 話は変わりまして、今回はMySQLの記事になります。 仕事でも趣味でもＷＥＢサービスを開発している僕ですが、基本的にＬＡＭＰ環境の構築が多いです。 LAMPとは、データベース連動型のWebアプリケーションを開発するのに人気の高いオープンソースソフトの組み合わせ。OSにLinux、WebサーバにApache、データベースにMySQL、プログラミングにPHPかPerlかPythonを用いたシステムのこと。 IT用語辞典 ユーザーから送られてきた命令を、ＰＨＰで受け取り、MySQLに接続してデータベースから情報を取っています。 今回取り上げたいのは、「ユーザーの命令によって変わるＳＱＬ文の処理」。 例えば、以下のような検索フォームがあったとします。 住民検索として
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
RDS for MySQLのスロークエリーログをAWS LambdaでElasticsearchに取り込む | DevelopersIO
はじめに 藤本です。 Elasticseachに取り込むネタが続いています。 前回のELBのアクセスログをAWS LambdaでElasticsearchに取り込むに続いて、今回はRDS for MySQLのスロークエリログをElasticsearchに取り込む実装をご紹介します。 概要 MySQL Serverはスロークエリーログにより指定した秒数を超えるクエリを記録することができます。スロークエリログはパフォーマンス劣化の解析、クエリの適切性、DBのマシンパワーの適切性のチェックに役立ちます。RDS for MySQLも例外ではありません。パラメータグループを設定することにより、スロークエリログを有効にすることができます。それに加えてRDS for MySQLの場合、AWSのAPIによりデータベースに接続せずともスロークエリログを取得することができます。 スロークエリログフォーマット
[ActiveRecord]activerecord-import-0.15系で気をつけること - Qiita
最近DBのBulk Insert用に、activerecord-importを使用してるのですが、Rails5対応で最新版のactiverecord-importにupdateし使用したところ、思いがけないところでハマってしまったので、備忘録として残しておきます ハマってた内容 Insert用に用意したActiveRecordのModelインスタンス数とimport後のレコード数に差分が生じていた 原因 0.15系だとvalidationがデフォルトでtrueの状態になっており、validationで引っかかっていることに気づかなかった 対策 optionにfalseを渡すのも考えたが、validation通ってないデータが保存されるべきデータではないので、エラーメッセージ等、補足できないかなと調べた どうやらreturn instanceに以下のものがあるっぽい failed_insta
![[ActiveRecord]activerecord-import-0.15系で気をつけること - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/05a3826baf79f4d55dbbe56b2e40a1a5c9f02983/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCQWN0aXZlUmVjb3JkJTVEYWN0aXZlcmVjb3JkLWltcG9ydC0wLjE1JUU3JUIzJUJCJUUzJTgxJUE3JUU2JUIwJTk3JUUzJTgyJTkyJUUzJTgxJUE0JUUzJTgxJTkxJUUzJTgyJThCJUUzJTgxJTkzJUUzJTgxJUE4JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0xYjczMTI3YjZjZWVkNDM3Njk2ZjUyZTY1YmU0MzcwNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdGFuaXNoLWtyJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iNjIxZGM3NzllNTM3ZjQzYTVjOWYyNWJmMmY4MTEzOQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Df15c0411449485919775ea78e660cd27)
OSSデータベースのMySQLとPostgreSQLは「次の段階」へ進む
OSSデータベースのMySQLとPostgreSQLは「次の段階」へ進む：Database Watch（2016年9月版）（1/2 ページ） オープンソースデータベースの両雄、MySQLとPostgreSQLはどちらも近々大きく変化を遂げそうです。まだ公式発表前ですが、現在入手できる情報から「来たるべき進化」を考えます。 連載バックナンバー かつて、新しい技術を生み、育てることは商用製品が主導していました。しかし近年では、すっかりオープンソースのコミュニティーが新技術をリードするようになっています。事実、先進的な考えを持つ多くの参加者が、オープンな場で議論や評価を重ねて技術を研ぎ澄ましていった結果、最終的に商用製品へ実装されていくケースが多数あります。 2016年現在、「MySQL」と「PostgreSQL」は、そうしたオープンソースリレーショナルデータベースソフトウェア（RDB）の両雄で
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
書籍発行のお知らせ：詳解MySQL 5.7 〜進化したMySQLをよく知るためのテクニカルガイド〜
既に昨日のdb tech showcaseのスライドでご存じの方も多いだろうが、この度MySQL 5.7の新機能を解説するための書籍を発行させていただくこととなった。8月23日発売予定である。 MySQL 5.7の新機能については、これまでブログでは紹介してこなかった。というのも、あまりにもボリュームが多すぎて、ブログという媒体でカジュアルに紹介するには向いていないと思ったからだ。とはいえ、MySQL 5.7を皆さんに使っていただくには、誰かが新機能をしっかりと解説しなければならない。どうするべきか考えた結果、書籍としてまとめて出させていただくことになった。 新機能について真面目に解説しようとすると、新しいポイントがどこなのかということを言及するために、結局のところ元々の機能についてもある程度解説が必要になってしまう。そういうわけで、この書籍では、MySQLが持つ機能の基本的なコンセプトや
ActiveRecordで行ロックをかける方法
行ロックとは 行ロックとは、テーブルの同一レコードに対して、複数同時に更新できないように制限する仕組みのことです。 Ruby on RailsのActiveRecordには２種類のロック方法があります。 楽観的ロック（Rails依存） 悲観的ロック（DBMS依存） それぞれの違いや使い方について解説していきたいと思います。 楽観的ロック 楽観的ロックとは、DBMSの機能に頼らずロックバージョンをレコードに保存しておくことで、取得時と変更時にロックバージョンに変更がないか確認し、変更があった場合は例外を発生させる方法です。 ロックするタイミング データ更新時 データを複数同時に取得することができるが、途中で更新されていた場合は、更新できない 仕組み テーブルにlock_versionフィールドを追加する lock_versionが書き換わっていたらActiveRecord::StaleObj
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysqlのuserログイン時に`ERROR 1524 (HY000): Plugin is not loaded`が出たときの対応法 - Qiita
オラクル、“3倍高速”な「MySQL 5.7」一般提供開始
