並び順

ブックマーク数

期間指定

  • から
  • まで

201 - 240 件 / 557件

新着順 人気順

innodbの検索結果201 - 240 件 / 557件

  • InnoDB Performance Optimization Basics

    This blog is in reference to our previous ones for ‘Innodb Performance Optimizations Basics’ 2007 and 2013. Although there have been many blogs about adjusting MySQL variables for better performance since then, I think this topic deserves a blog update since the last update was a decade ago, and MySQL 5.7 and 8.0 have been released since then with some major changes. These guidelines work well for

      InnoDB Performance Optimization Basics
    • MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみました

      MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみましたー 対象のMySQLのバージョンは5.7と8.0です。 結論としては、 INSERTはMyISAMの方が早い SELECT・UPDATE・DELETEは 8.0ではInnoDBの方が早い 5.7ではSELECT・DELETEはMyISAMの方が早い。UPDATEはInnoDBの方が早い という結果でしたー! なお、MySQLのバージョンごとのサポート期限は以下のようになっています。 MySQLバージョン MySQL AWS RDSのMySQL AWS AuroraのMySQL 5.7 2023年10月31日 2023 年 10 月 2024 年 10 月 31 日 (Aurora バージョン2) 8.0 2026年4月30日 未定 未定 (Aurora バージョン3) 検証条件 MySQL5.7-MyISAMで、1万件

        MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみました
      • 第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp

        使用されず役に立たないインデックスを定義するのは、SQLアンチパターンの1つ「インデックスショットガン」として知られています。使用されていないインデックスを定義するのは、ディスク容量を圧迫して、さらに更新コストも掛かるという良いこと無しな状態です。 ただ実際には、あなたが使用されていないインデックスを見つけたとしても、安易にドロップするのは非常に危険です。ドロップするのは時間がかかりませんが、インデックスを再構築するまでには時間がかかります。 もしも万が一そのインデックスが使用されているクエリが存在するとしたら、その時点から障害につながってしまう可能性があります。ドロップはしたくないけど、使わないようにして影響を確認したい……、今回はそんな時に便利なMySQL 8.0の新機能「Invisible Indexes」を使ってインデックスを外した時の影響を調べてみましょう。 検証環境 今回はDo

          第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp
        • 週刊Railsウォッチ(20200601前編)Active Recordに新機能「delegated typing」追加、RuboCopのデフォルト設定アンケートほか|TechRacho by BPS株式会社

          2020.06.01 週刊Railsウォッチ(20200601前編)Active Recordに新機能「delegated typing」追加、RuboCopのデフォルト設定アンケートほか こんにちは、hachi8833です。この記事↓にどよめきました👍🎉😂。 ⚓オープニングつっつき: 経産省のnpmモジュールが素晴らしい 元記事: 経産省発の npm モジュール!住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した! - Geolonia developer's blog サイト: IMI 情報共有基盤 コンポーネントツール 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴ら

            週刊Railsウォッチ(20200601前編)Active Recordに新機能「delegated typing」追加、RuboCopのデフォルト設定アンケートほか|TechRacho by BPS株式会社
          • PostgreSQL と MySQL の決定的な違い

            基本: PostgreSQL と MySQL の概要 PostgreSQLとMySQLの基本的な概要と歴史から始めましょう。すでに基本的なことを知っている場合は、このセクションは飛ばしてください。初心者の方はこのセクションをお読みください。 MySQL とは MySQLは、世界で最も一般的に使用されているリレーショナルデータベース管理システム(RDBMS)です。2023年に開発者の間で2番目に高い使用率を誇るこのオープンソース RDBMS は、高速で信頼性が高く、安定したセキュアでスケーラブルなデータ管理を組織に提供することで知られています。 MySQLは、スケーラブルな Web アプリケーションに最適な選択肢です。MySQLはLAMPスタックに標準搭載されています。LAMPスタックはウェブ開発で非常に人気があります。これは、Linux、Apache HTTP Server、MySQL、P

              PostgreSQL と MySQL の決定的な違い
            • 第108回 MySQLのコスト見積もりを調整する | gihyo.jp

              MySQLでは実行計画を生成するために、コストモデルを採用しています。オプティマイザーは実行計画を生成するために、さまざまなオペレーションからコストを見積もります。その際にベースとなる推定値が、mysqlデータベースのserver_costとengine_costテーブルに格納されていています。MySQL 5.6とそれ以前はコストパラメータの値は定数としてハードコードされていましたが、MySQL 5.7とそれ以降からはコストパラメータの値を変更することが可能になりました。 今回はMySQL 8.0.17を使用して、コスト見積もりを調整する方法について紹介したいと思います。 server_costテーブル server_costは、一般的なサーバー操作のオプティマイザーの見積もりが格納されているテーブルです。SELECTしてみると、以下のようになっています。 mysql >SELECT *

                第108回 MySQLのコスト見積もりを調整する | gihyo.jp
              • MySQL :: MySQL Shell 8.0 :: 11.6 Dump Loading Utility

                MySQL Shell's dump loading utility util.loadDump(), introduced in MySQL Shell 8.0.21, supports the import into a MySQL HeatWave Service DB System (a MySQL DB System, for short) or a MySQL Server instance of schemas or tables dumped using MySQL Shell's Section 11.5, “Instance Dump Utility, Schema Dump Utility, and Table Dump Utility”. The dump loading utility provides data streaming from remote sto

                • 今週のはてなブログランキング〔2021年4月第4週〕 - 週刊はてなブログ

                  はてなブログ独自の集計による人気記事のランキング。4月18日(日)から4月24日(土)〔2021年4月第4週〕のトップ30です*1。 # タイトル/著者とブックマーク 1 「愛のあるセックス」はなぜ必要か(読書メモ:『性と愛の脳科学』) - 道徳的動物日記 by id:DavitRice 2 日本のソフトウェア開発はなぜ世界から落伍したのか。中国人エンジニアの見方 - 中華IT最新事情 by id:tamakino 3 ティム・オライリーが「シリコンバレーの終焉」について長文を書いていたのでまとめておく - YAMDAS現更新履歴 by id:yomoyomo 4 国内約200組織へ行われたサイバー攻撃と関係者の書類送検についてまとめてみた - piyolog by id:piyokango 5 テイエムオペラオーのオペラトークを解析する - ウマ娘考察 - 世界観警察 by id:syl

                    今週のはてなブログランキング〔2021年4月第4週〕 - 週刊はてなブログ
                  • エンティティの識別子に ULID を使ってみよう

                    エンティティの識別子の生成タイミング問題 DDD[1]では,一意な識別子を持ち,その識別子によって識別できるモデルをエンティティ (Entity) として表現します.このエンティティの識別子の生成方法には様々な種類がありますが,大きく分けて永続化前に生成する早期生成と永続化後に生成する遅延生成の2種類に分けられます. エンティティの識別子の生成に遅延生成を用いると本来 Not Null な識別子を Nullbale として扱う必要性が生じてしまいます.これを避けるのであれば,早期生成を採用すると良く,IDDD本[2]などではUUIDやGUIDをアプリケーション側で生成し識別子に用いる例が紹介されています. しかし,技術的な問題でUUIDなどのランダムな値を識別子として採用しづらいケースも存在します.たとえば,MySQL (InnoDB) ではプライマリキーにランダムな値を用いるとINSER

                      エンティティの識別子に ULID を使ってみよう
                    • こんなデータベース用ライブラリを誰か作ってほしい(Go) - のんびり精進

                      Go2 Advent Calendar 2019 の 6 日目の記事です。 Go の database/sql って使いにくくないでしょうか。 二年ちょっと前にもっと楽にできないかなと思って調べました。 欲しかったもの database/sql を使いやすくしたもの ORM は要らない ただし、SELECT と INSERT は楽をしたい ORM を必須とする人もいると思いますが、そのときは直に SQL 文を書きたかったので、それに合ったライブラリだけを試しました。 試したライブラリ sqlx Connect()、MustExec() など database/sql とのメソッド名の違いが大きくて、感覚的に避けてしまいました。 gorp 割と近い感じで使えて好感触でした。 というわけで gorp を選び、そのときに書いた記事が下記二つです。 【Go】gorp を使って DB 操作を少し楽に

                        こんなデータベース用ライブラリを誰か作ってほしい(Go) - のんびり精進
                      • Amazon Aurora のローカルストレージについて調べてみた - Link and Motivation Developers' Blog

                        こんにちは。リンクアンドモチベーション SRE グループの綿引と申します。 今回 Amazon Aurora の「ローカルストレージ」に関して調べる機会がありましたのでご紹介したいと思います。 背景 先日CloudWatchメトリクスを眺めていたのですが、RDSに「FreeLocalStorage」という項目があることに気づきました。 「Aurora のボリュームは自動拡張するのにストレージのメトリクスってあるんだ」と驚き、次に「このLocalStorageとは何だっけ?」ということが気になり、調べてみたということが背景になります。 Amazon Aurora とは まず簡単に Aurora についておさらいですが、フルマネージド型のリレーショナルデータベースサービスで以下のような特徴があります。 (参考:「Amazon Aurora の特徴」) ----------------- MyS

                          Amazon Aurora のローカルストレージについて調べてみた - Link and Motivation Developers' Blog
                        • NAND Flash から InnoDB にかけての話(仮) | GREE Engineering

                          こんにちわ。せじまです。 2021-07-09、日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会- でお話させていただくことになりました。勉強会等でお話させていただくのはずいぶん久しぶりで、オンラインイベントでは初となります。 資料を読み返してると「興味のある方は、予め、関心のある補足資料等にざっと目を通しておいていただいた方が、よりわかりやすくなるかも」と感じたので、イベント開催一週間前ですが、事前に資料を公開させていただくことにしました。

                            NAND Flash から InnoDB にかけての話(仮) | GREE Engineering
                          • ダンプが楽しくなる mysqldump の後継ツール mysqlpump の話 | 株式会社ビヨンド

                            こんにちは。 開発チームのフリー素材担当、まんだいです。 かなり出遅れてますが mysqldump の後継ツールとなる mysqlpump を使ってみたので、まだ使ったことがない人向けにオススメポイントをまとめてみました。 さすが後継というべきか、基本的なオプションの使い方はそのままで mysqldump から移行してきた人にも優しい設計になっていましたので、ぜひ使ってみてほしいと思いました。 MySQL に同梱されているのがポイント高いですよね。 これだけでも乗り換える価値がある、進捗表示 今回試したデータベースはせいぜい 200MB 程度のものなのであまり恩恵はなかったですが、 mysqlpump はダンプの進行具合を逐一表示してくれます。 mysqlpump -uroot -p --databases xxxxx > xxxxx_20XX0X0X.sql Enter password

                              ダンプが楽しくなる mysqldump の後継ツール mysqlpump の話 | 株式会社ビヨンド
                            • ISUCON13にチーム「ウー馬場ーイー222」で参加して最終スコアは 49,344 でした - Gマイナー志向

                              TL;DR 2023年11月25日に開催されたISUCON13に参加しました。最終スコアは49,344でした。実装言語はGoです。今回のチーム名の由来は申し込み時のチームIDが222だったためです。 追記:30位でギリギリTOP30チームに入りました。やったね。 今回スコアが思ったほど奮わなかったのですが、敗因はN+1を甘く見ていたことだと思っています。MySQLのスロークエリーログ(トータル実行時間順)を見ているだけではだめで、実行回数をもっと重視する必要があるなと思いました。うん、そうだね。 今回はDNSが課題に組み込まれており、インフラエンジニア3人態勢の我々のチームの得意分野とする領域のはずだったのですが、DBのボトルネックを解消できずDNS周りに着手できませんでした。くやしー。 運営の皆様、ことしもよい問題をありがとうございました。来年こそはリベンジして上位入賞を目指したいと思い

                                ISUCON13にチーム「ウー馬場ーイー222」で参加して最終スコアは 49,344 でした - Gマイナー志向
                              • S3へ出力したCloudWatch LogsのデータをS3 SelectとAthenaで確認してみた | DevelopersIO

                                Kinesis Data Firehose介し、S3へ出力したCloudWatch LogsのデータをS3 SelectとAthenaで確認してみました。 Kinesis Data Firehoseを使いCloudWatch LogのデータをS3に出力することが可能です。S3をデータソースにしたデータの確認方法は多々あると思いますが、ここではS3 SelectとAthenaを利用しログデータを確認してみたいと思います。本エントリでは、環境構築については割愛していますので、構築については以下ブログを参考にしてください。 CloudWatch LogsのログデータをKinesis Data Firehose経由でS3に出力する なお、ここではS3へ出力されたログデータはAurora監査ログを利用しています。 S3 Select 構成 Kinesis Data Firehose設定 配信ストリー

                                  S3へ出力したCloudWatch LogsのデータをS3 SelectとAthenaで確認してみた | DevelopersIO
                                • MySQL でメモリ不足が発生したときのパラメータチューニング - Qiita

                                  $ mysql Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug 上記のエラーが発生して MySQL に接続できなくなった場合、MySQL がメモリ不足となっている可能性があります。 メモリ使用量の計算 MySQL のメモリ使用量は、以下のような計算式で調べることができます。 このメモリ使用量が物理メモリサイズを超えると、メモリ不足が発生する可能性が高まるので、 物理メモリサイズを超えないように、バッファサイズとコネクション数を調整します。 グローバルバッファの設定 MySQL のバッファには、グローバルとスレッドの2種類があります。 グローバルバッファは MySQL

                                    MySQL でメモリ不足が発生したときのパラメータチューニング - Qiita
                                  • MySQL8.0.21の「Redoログ無効化」で大量書込処理を加速する - なからなLife

                                    7/13 に MySQL 8.0.21 がリリースされました。 リリースノートを読んでいて「Functionality Added or Changed」の3つ目に InnoDB: Redo logging can now be enabled and disabled using ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG syntax. This functionality is intended for loading data into a new MySQL instance. Disabling redo logging helps speed up data loading by avoiding redo log writes. The new INNODB_REDO_LOG_ENABLE privilege permit

                                      MySQL8.0.21の「Redoログ無効化」で大量書込処理を加速する - なからなLife
                                    • MySQL InnoDB Cluster 反省会 - ASMのきもち

                                      この記事は「MySQL Advent Calendar 2019 21日目」です。 これまた大遅刻となってしまって申し訳ございませんでした;(´◦ω◦`): これも言い訳はダメだぞ自分! さて、今年中にどうしても書き残して置きたかった内容があったのですが、ありがたくも「Adovent Calenderに書いていいよ!」というお話しをいただいたので…書かせていただきます。 題して「MySQL InnoDB Cluster 反省会」。 何もMySQLを知らない人間が、いきなり MySQL InnoDB Cluster Group Replication を導入した、そんなお話です。 前提 InnoDB Clusterを採用した理由 採用する前にやったこと 反省会(マネジメントチックな話) MySQLはコミュニティのものである 複数バージョン間レプリケーションがサポートポリシー変更 反省会(技術

                                        MySQL InnoDB Cluster 反省会 - ASMのきもち
                                      • RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)

                                        結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは? MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd

                                          RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)
                                        • 機械学習システムアーキテクチャ入門 #1

                                          機械学習システムのアーキテクチャを検討する上で考慮すべき課題について調査しまとめた資料です。Money Forward 社内で開かれた MLOps についての勉強会のために作成しました。 ## Reference ### 大規模なデータを扱う難しさ - Architecture Evolution in Repro https://speakerdeck.com/joker1007/architecture-evolution-in-repro - Sidekiq to Kafka ストリームベースのmicro services https://speakerdeck.com/joker1007/sidekiq-to-kafka-sutorimubesufalsemicro-services - ReproのImport/Exportを支えるサーバーレスアーキテクチャhttps://spe

                                            機械学習システムアーキテクチャ入門 #1
                                          • Troubleshoot low freeable memory in Amazon RDS for MySQL

                                            How can I troubleshoot low freeable memory in an Amazon RDS for MySQL database? I run an Amazon Relational Database Service (Amazon RDS) for MySQL instance. I see that my available memory is low, my database is out of memory, or low memory is causing latency issues in my application. I want to identify the source of the memory utilization and troubleshoot. Short description In Amazon RDS for MySQL

                                              Troubleshoot low freeable memory in Amazon RDS for MySQL
                                            • MySQL のロックについて補足(注:すでに語りつくされている内容です) - Qiita

                                              これは インフラ勉強会 Advent Calendar 2018 19 日目の記事です。 書いているうちに日付が変わってしまいました。 同カレンダーの 17 日目に、 「MySQL8.0 で起こる謎のデッドロックの条件を調べてみた」を data_locks・data_lock_waits テーブルで確かめてみた という記事を書きましたが、そもそも MySQL(InnoDB)のロックについて何も解説していないので、おそらく MySQL 初心者には全く意味の分からない記事になってしまったと思います(すみません)。 というわけで、すでに語りつくされている内容ですが、先の記事を理解するのに最低限必要になりそうなことを補足していきます。 ※MySQL に慣れている人にはいまさら解説不要な内容です。 MySQL(InnoDB)とトランザクション分離レベル 細かいことは説明しませんが、MySQL を含む

                                                MySQL のロックについて補足(注:すでに語りつくされている内容です) - Qiita
                                              • 2022 年振り返り - yoheimuta’s blog

                                                あけましておめでとうございます。 2022 年は、生活全般と専門的なソフトウェアエンジニアリングを分けて、振り返りをまとめました。 この記事は生活全般についてです。 私生活 体調管理 風邪症状は何度かありましたが、仕事に支障が出るほどではありませんでした。 どちらかというと、予防接種や自宅待機、保育園休園によってリズムが崩れることが多い一年でしたね。 子どもの予防接種全三回が 2023 年の 4 月までに終わるので、それで多少は落ち着いてくれるのを祈る日々です。 コミケ 2022 年は夏コミ(C100, 8/14)と冬コミ(C101, 12/31)の二回手伝いに行きました。人も徐々に戻ってきているような気がして、C99 ほど寂しい感じではなかったです。 冬コミは二スペだったのでスペースが広く使えて、いつもより余裕を持って望めました。毎回こうだと長時間緊張を強いられなくて済みます。 設営をは

                                                  2022 年振り返り - yoheimuta’s blog
                                                • オラクル、インメモリDBのMySQL HeatWaveに機械学習機能を追加。SQL文だけで学習、推論、説明の取得を実現

                                                  オラクル、インメモリDBのMySQL HeatWaveに機械学習機能を追加。SQL文だけで学習、推論、説明の取得を実現 オラクルは、MySQLにインメモリデータベースエンジンを搭載することで高速なOLAP機能を提供する「MySQL HeatWave」の新機能として、機械学習機能を提供する「MySQL HeatWave ML」を発表しました。 同時に、無停止でのHeatWaveのノード拡張と、ノードあたりのデータ格納量の倍増も発表されました。 [プレスリリース抄訳] オラクル、MySQL HeatWave MLを発表 - 開発者が簡単、迅速、経済的に利用可能なMySQL アプリケーション向けの強力な機械学習機能を提供 - Oracle Cloud Infrastructure(OCI)の東京と大阪を含む37のリージョンでご利用可能です https://t.co/ly7qGP8CZ5 #mys

                                                    オラクル、インメモリDBのMySQL HeatWaveに機械学習機能を追加。SQL文だけで学習、推論、説明の取得を実現
                                                  • 「“2ちゃんねる”は事業アイデアよりも設計の部分で流行った」 元管理人が語る、落ちない掲示板を支えた構造設計

                                                    技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。ここで登壇したのは、元2ちゃんねる管理人のひろゆき氏。エンジニアを目指す学生からの質問に答えました。全3回。2回目は、ひろゆき氏が思う「2チャンネル」がブレイクスルーした理由と、サービスを運営するうえで気をつけていたことについて。前回はこちら。 ノーコードが普及してもノーコードエンジニアとはならない 楓博光(以下、楓):ありがとうございます。それでは、先ほどから何個かチャットで質問をいただいているので、それを拾いたいと思います。「なぜノーコードは日本で普及しないのでしょうか。私はノーコードエンジニアというポジションが将来できると思うのですが、ひろゆきさんはどうお考えでしょうか?」 ひろゆき氏(以下、ひろゆき):コメントで「ノーコードエンジニア何?」と書いてありますが、それをエンジ

                                                      「“2ちゃんねる”は事業アイデアよりも設計の部分で流行った」 元管理人が語る、落ちない掲示板を支えた構造設計
                                                    • デッドロックおじさん戦記 | メルカリエンジニアリング

                                                      Mercari Advent Calendar 2017 の18日目です。 こんにちは。メルカリJPのサーバーサイドエンジニアの@Hirakuです。最近はメルカリNOWの立ち上げに関わっておりGoとPHPを行ったり来たりしています。 今回はネタとしては地味ですが、2017年に遭遇した、MySQLのデッドロックの話をしようと思います。 これまでも何度か話されている通り、メルカリのコア部分は今でもPHP + MySQLで構成されており、複雑なトランザクションを含む処理が各所に存在しています。そのため、意図せずしてデッドロックを作ってしまうことがあり、場合によっては重大な問題につながります。 今年は本当にデッドロックに関するトラブルに多く遭遇し、すっかり「デッドロック絶対に許さないおじさん」みたいになっていました。 事例1)出品者と購入者 デッドロックと言われてもピンと来ない方もいらっしゃるでし

                                                        デッドロックおじさん戦記 | メルカリエンジニアリング
                                                      • とあるパブリッククラウドで稼働していたメディアサービスを AWS に移行した話 - WILLGATE TECH BLOG

                                                        はじめに これまでのメディアサービス AWS に移行するメリット AWS に移行するために行ったこと 負荷試験の実施 IaC の刷新 移行時に起こった問題 RDS のコネクション数が瞬間的に飛び抜ける メンテナンス明けのキャッシュない問題 切り戻しが発生した 移行プロジェクトが終わってみて おわりに はじめに こんにちは!インフラチームの高畑です! ついに夏到来で遊びたい気持ちを必死に抑え込みつつ日々活動をしている私ですが、皆さんはいかがお過ごしでしょうか。 今回はウィルゲートのメディアサービスをとあるパブリッククラウドから AWS に移行した際の出来事をブログに書き綴ろうと思います! これまでのメディアサービス これまでのメディアサービスはとあるパブリッククラウドで運用を行なってきたため、サーバ負荷増加などの影響でスケールアウト、スケールアップをしようにも多少手間と時間がかかっていました

                                                          とあるパブリッククラウドで稼働していたメディアサービスを AWS に移行した話 - WILLGATE TECH BLOG
                                                        • オラクル、インメモリー分散DB「MySQL HeatWave」の運用をマシンラーニングで自動化 | IT Leaders

                                                          IT Leaders トップ > テクノロジー一覧 > データベース > 新製品・サービス > オラクル、インメモリー分散DB「MySQL HeatWave」の運用をマシンラーニングで自動化 データベース データベース記事一覧へ [新製品・サービス] オラクル、インメモリー分散DB「MySQL HeatWave」の運用をマシンラーニングで自動化 2021年8月11日(水)日川 佳三(IT Leaders編集部) リスト 米オラクルは2021年8月10日(米国時間)、クラウド型データベース「MySQL HeatWave」に運用自動化機能「MySQL Autopilot」を追加したと発表した。MySQL HeatWaveのチューニングをマシンラーニング(機械学習)で自動化する。MySQL HeatWaveユーザーは追加費用なく利用できる。 米オラクル「MySQL Database Servic

                                                            オラクル、インメモリー分散DB「MySQL HeatWave」の運用をマシンラーニングで自動化 | IT Leaders
                                                          • Performance InsightsのカウンターメトリクスをCloudWatchに連携してみた | DevelopersIO

                                                            こんにちは、崔です。 RDSのPerformance Insightsは、データベースインスタンスを監視しパフォーマンスを分析する機能です。 Amazon RDS Performance Insightsの使用 Performance Insightsは、システムパフォーマンスの監視に役立つように様々なOSとDBのカウンターメトリクスを収集します。 また、各RDSデータベースエンジンには、独自のカウンターメトリクスのセットがあります。 パフォーマンスインサイトのカウンター:Aurora パフォーマンスインサイトのカウンター:RDS Performance Insightsのこれらのメトリクスはマネジメントコンソール上のダッシュボードで確認可能ですが、提供されているAPIを使えばそのデータを取得できます。 今回は、Performance Insightsが提供しているAPIである GetRe

                                                              Performance InsightsのカウンターメトリクスをCloudWatchに連携してみた | DevelopersIO
                                                            • Percona LIVE 2019参加してきた (2日目) - tom__bo’s Blog

                                                              Percona LIVE 2019に参加してきました。 前回の続きで初日(Tutorial Day)から Session Day 1, 2の3日間のうち2日目(Session Day 1)の内容です。 おそらく発表のスライドが公開されることと思いますが、全体が非公開になるものや非公開になるページがあるかもしれないので、ここではあえて概要だけと会場の雰囲気や僕の感想を書こうと思います。 また、英語の聞き取り能力が高くないため、勘違いした内容を書いている可能性が多分にあります。あくまで参考程度に読んでください。 各発表ごとのサブタイトルは発表中のものもあれば、メモを忘れて僕が勝手に書いたものもあります。 (メモからの校生も面倒なので、ここで丁寧語は終了です) Session Day 1 (2日目) 1日目のスケジュール -> https://www.percona.com/live/19/sc

                                                                Percona LIVE 2019参加してきた (2日目) - tom__bo’s Blog
                                                              • MySQLのオンラインDDLでレプリケーション遅延を回避する方法 - Qiita

                                                                この状況でサイズの大きいテーブルに対してDDLを行うと、Replica でのレプリケーション遅延を招いてしまう恐れがあります。 遅延が発生すると Replica を参照しているサービスで Source に書き込まれた最新のレコードが取得できない状況になってしまい、サービスに影響が出ます。 本記事ではオンラインDDLでレプリケーション遅延を回避する方法について記述します。 ※ Source/Replica = Master/Slave です。慣れましょう 方法 MySQLのバージョンに応じて 2種類。そしてツールを使う方法があります。 INSTANT DDL (MySQL 8.0.12 ~) 特定のDDLに限る Rolling Schema Upgrade (RSU) (MySQL 5.6 ~) オンラインDDLに限る ツールを利用する 今回は紹介に留めて割愛します 1. INSTANT D

                                                                  MySQLのオンラインDDLでレプリケーション遅延を回避する方法 - Qiita
                                                                • Dive into InnoDB from redo logs

                                                                  DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? - Matthew Skelton, Conflux

                                                                    Dive into InnoDB from redo logs
                                                                  • Mroongaの全文検索がいい感じだった - Qiita

                                                                    tl;dr InnoDBの全文検索自体は遅くない ただしブール全文検索を行い別項目でソートを行うと、とたんに遅くなる LIMITで取得件数を絞ってもあまり変わらない Mroongaには全文検索特化の最適化がありレスポンスが早い! ことのはじまり 地味に溜めていたテキスト情報が1000万レコードを超え、そろそろLIKE検索も限界なので、MySQL5.7から使えるようになったMeCabプラグインを使い全文検索機能を実装してみました。実装当初はそこまでレスポンスが悪くないと思っていたのですが、それなりのレコード数のあるワードを入力し、ソート条件を指定するとソートキーがたとえPKやインデックスが貼られているカラムでも劇重に!(おそらく1テーブルに使えるインデックスは1つまでというMySQLの制約) 別の方法がないか模索していたところ、Mroongaエンジンの全文検索を使ってみたらいい感じだったので

                                                                      Mroongaの全文検索がいい感じだった - Qiita
                                                                    • ISUCON9 予選で Cloud Trace 使った - 恋しい日々

                                                                      id:hitode909 と id:tkzwtks と「ミッシングマグネティックストレージ」チームで出たけど予選敗退となった。最終スコアは5110点で、瞬間最大風速でも6700点ぐらい。 今回は Cloud Trace を投入してあれこれやってて悪くなかったのでそれについて。 練習のときにつかってみて悪くないねということになったので投入した。Express だと import するだけでそれっぽく使えるのだけれど、8 の予選問題をみたところ fastify が使われているようで、一工夫必要だった。一工夫っていうのは // setup cloud trace const tracer = require('@google-cloud/trace-agent').start() const fastify_connect = function(method: string, path: str

                                                                        ISUCON9 予選で Cloud Trace 使った - 恋しい日々
                                                                      • atc proceedings

                                                                        Rethink the Sync Edmund B. Nightingale, Kaushik Veeraraghavan, Peter M. Chen, and Jason Flinn Department of Electrical Engineering and Computer Science University of Michigan Abstract We introduce external synchrony, a new model for local file I/O that provides the reliability and simplicity of syn- chronous I/O, yet also closely approximates the perfor- mance of asynchronous I/O. An external obse

                                                                        • MySQLのREPEATABLE READとREAD COMMITTEDのロック状況をdata_locksから観察する - $shibayu36->blog;

                                                                          前回MySQLのREPEATABLE READとREAD COMMITTEDの違いを知るために色々試した - $shibayu36->blog;という記事を書いたところ、yoku0825さんにMySQL 8.0以降だとperformance_schema.data_locksが使えると教えてもらったので試した。 ちなみに、後ろからロックがぶつかるクエリを実行しなくても、MySQL 8.0だとSELECT * FROM performance_schema.data_locksでロックの範囲を確かめることができます。 ギャップつきロックがInnoDBのスタンダードで、X lockがレコードとギャップのロック、X not gapが単なるレコードロックになります— yoku0825 (@yoku0825) February 27, 2024 テーブル定義 CREATE TABLE `posts`

                                                                            MySQLのREPEATABLE READとREAD COMMITTEDのロック状況をdata_locksから観察する - $shibayu36->blog;
                                                                          • MySQL 8.0 で SELECT COUNT(*) が失速する

                                                                            MySQL 8.0 では、テーブル全件に対するSELECT COUNT(*)がパラレルスキャンによって高速化されましたが、MySQL 5.7 以前よりも遅くなるケースが発生したので、少し調べてみました。 タイトルの元ネタ テストの内容 インスタンスを再起動してバッファプールをクリアした状態から、3 つあるテーブルの全件SELECT COUNT(*)を続けて実行し、実行時間を計測 ①〜④ ではテストデータのサイズ>バッファプールのサイズ ⑤ ではテストデータのサイズ<バッファプールサイズ テストケースは 5 つ ①:test_short[1]→test_long[2]→test_long_uk[3]の順に、SELECT COUNT(*) FROM テーブル名をそれぞれ 10 回以上連続で実行する test_short→test_long→test_long_ukを 1 セットとして 10 回

                                                                              MySQL 8.0 で SELECT COUNT(*) が失速する
                                                                            • 【PHP】メール認証を利用した会員登録機能の作成方法|Koushi Kagawa

                                                                              今回はPHPにてメール認証を利用した会員登録機能の作成方法を記載します。 概要機能概要としてはこんな感じです。 ※ごめんなさい、ちょっと細かくて見辛いので画像クリックして拡大してみてください...!!それぞれ詳しく説明しますと、 1.会員仮登録画面 - メールアドレスを登録します。 2.会員仮登録完了画面 - メールアドレスを登録したというお知らせの画面です。 - この時にpre_userテーブルにデータを登録します。 3.メール送信 - 登録されたメールアドレスに登録フォームのURLを記載したメールを送信します。 4.会員本登録画面 - 会員本登録のフォームを表示します。 5.会員本登録確認画面 - フォームの登録内容の確認画面です。 6.登録完了 - 登録完了を報告する画面です。 7.メール送信 - 登録されたメールアドレスに、会員登録完了のメールを送信します。 DBの作成まずはDBを

                                                                                【PHP】メール認証を利用した会員登録機能の作成方法|Koushi Kagawa
                                                                              • Fixing bug 109595 makes MySQL almost 4X faster on the Insert Benchmark

                                                                                MySQL 8.0.35 includes a fix for bug 109595 and with that fix the QPS is almost 4X larger on the read+write benchmark steps compared to MySQL 8.0.34. Thank you to MySQL for fixing this quickly. I reported the bug in January of 2023. I have been aware of the performance problem for years, but didn't spend time debugging it until this year. I assume this problem was limited to InnoDB because I did no

                                                                                  Fixing bug 109595 makes MySQL almost 4X faster on the Insert Benchmark
                                                                                • データセンター単位の大規模障害に見舞われたとき、 mysqld で error log を見る前に確認していることなど | GREE Engineering

                                                                                  HOMEInfoデータセンター単位の大規模障害に見舞われたとき、 mysqld で error log を見る前に確認していることなど こんにちわ。せじまです。今回は、実際役に立つケースは限られていますが、備忘録として書いておきます。 はじめに 私は(たしか)2003年くらいから、しごとでMySQL使っていたので、もうかれこれ18年くらいは使ってるんですが、それだけ長いこと使っていると、大規模な障害というものにも何度か出くわしたりしました。 ざっくりとした規模感で言いますと、データセンターでラック一本まるごと異常が発生するケースとか、ラック一本にとどまらず、データセンター内のサーバの何割かが異常に見舞われる、といった規模で発生した障害です。物理的な故障で障害が発生したこともあれば、ネットワーク機器の不具合により、ラック一本まるごと切り離す必要性が発生したこともありました。 ラック丸ごと一本

                                                                                    データセンター単位の大規模障害に見舞われたとき、 mysqld で error log を見る前に確認していることなど | GREE Engineering