AWS設計プロンプト
シンプルかつ網羅的なAWS設計を生成するAIプロンプトの核心は： 構造化された出力フォーマット：設計書の章立てと各セクションの説明内容を明確に指定 具体的なパラメータ要求：抽象的な説明ではなく、実装に使える具体的な設定値を求める 選定理由の明確化：「なぜその選択をしたのか」の説明を求める 代替案との比較：検討した代替オプションとの比較を含める Well-Architectedの原則適用：AWSのベストプラクティスに基づく設計を促す このアプローチを活用すれば、AIの力を借りつつも、実装に直結する高品質なAWS設計書を効率的に作成できます。何より、設計者の時間を節約しながらも、その専門知識と判断を最大限に活かせるところに大きな価値があります。 ※以下を全量使用すると量が多いので、該当箇所のみの抜粋を推奨 以下の要件に基づいて、詳細かつ実装可能なAWSアーキテクチャを設計してください。各セクシ
５分で覚えるトランザクション分離レベル
これはなに ども、レバテック開発部のもりたです。 今回はトランザクション分離レベルについてまとめました。トランザクション分離レベルって基本情報技術者試験とかで学ぶものの、座学だけだとあんまりピンとこずに忘れちゃいますよね。もりたも長らく曖昧な状態で生きていたのですが、よい理解の仕方があったので今回はその解説をします。 トランザクション分離レベルを構成するふたつの変数 トランザクション分離レベルとは まず初めに、概要を掴むところからいきましょう。 トランザクション分離レベルとは、あるトランザクションのデータベースに加えた変更が、他のトランザクションにどの程度影響を与えるか？ というもの（分離性、独立性）を一定基準でレベルに分けてまとめたものです。 どの程度影響を受けるか？ については三つの影響が定義され、その影響度合いに応じて分離レベルが４つ存在します。これは大体こんな図で解説されます。 よ
医薬品検索でMySQLの全文検索機能を使った話 - KAKEHASHI Tech Blog
AI在庫管理の開発チームでバックエンドエンジニアをしている沖です。今回は、AI在庫管理の医薬品検索において、MySQLの全文検索機能を使った話を紹介しようと思います。 この記事は秋の技術特集 2024の 8 記事目です。 今までの医薬品検索では満足できないユーザーがいた なぜMySQLの全文検索機能を採用したのか 全文検索機能を導入する 全文検索インデックスを付与したテーブルを作成する パーサー 照合順序と正規化 全文検索インデックスを使用して検索する データを最適な状態に保つために おわりに 今までの医薬品検索では満足できないユーザーがいた AI在庫管理には、医薬品の在庫一覧画面など、医薬品名で絞り込む画面がたくさんあります。この絞り込み機能を実現するために、これまではSQLのLIKE検索を利用していました。 LIKE検索は、使い慣れたSQLを用いて部分一致検索を実現できる便利な方法です
インデックスとは何？MySQL(InnoDB)とPostgreSQLのインデックスの違いとは？調べてみました
はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
ITのひどい記事をみんながブクマしてキツイ
以下の記事、内容がひどくて空いた口が塞がらなかったのだが、 （はてブで）ブックマークして下手にホッテントリにでもなったら嫌だなと思いそっとブラウザのタブ閉じた。 が、しばらくすると残念ながらホッテントリ入りしてしまったので、はてブにコメントを軽く書こうとしたが100文字に収まらなかったので増田にした。 技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL まず、「特定条件下では MySQL は我々のプロダクトには不向き」を「MySQLを使うと会社は潰れる」なんて表現するのおかしいでしょ。 以下の記事からの引用だが Uber のエンジニアは「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない、MySQL＋InnoDBに変えたら全部解決した」と主張している。 UberエンジニアがブログでPostgre
はじめに こんにちは、バックエンドエンジニアのSakiです！バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL（InnoDB）についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや
MySQL is certainly a powerful open source database management system, but even the most robust engine struggles when queries take an eternity to execute. For DBAs and developers, improving MySQL query performance is an ongoing goal. Efficient query performance is crucial for ensuring the smooth operation and optimal user experience of applications powered by MySQL databases. When businesses rely h
MySQL の UPDATE で IN 句の要素が多すぎてデッドロックした話 #LayerXテックアドカレ - LayerX エンジニアブログ
この記事は、LayerX Tech Advent Calendar 2024 の7日目の記事です。 tech.layerx.co.jp こんにちは。バクラクビジネスカード開発チーム エンジニアの iwamatsu です。 何か書くことないかな〜と頭を悩ませていたところ、見たことのない不思議なデッドロックに出くわしたので、今回はそれについて書こうと思います。 実行環境 バージョン: MySQL 8.0.39 ストレージエンジン: InnoDB トランザクション分離レベル: REPEATABLE READ 発生した事象 以下のようなユーザーテーブルがあるとします。 CREATE TABLE `users` ( `id` INT NOT NULL, `name` VARCHAR(255) NOT NULL, `lucky_color` VARCHAR(255) NOT NULL, PRIMARY
こんにちは。LINEヤフー株式会社でデータベースエンジニアをしている、松浦、中園、大塚、曽根、笠井です。 データベースはLINEヤフーのさまざまなサービスを支える重要なソフトウエアですが、その安定的な運用やトラブルシューティングには、データベースに関する専門的な知識が必要です。 一方で、データベース部門に配属される新卒のエンジニアは、全員が学生時代にデータベースを専門的に勉強しているわけではありません。このような新卒エンジニアは、データベース部門へ配属後、OJTや実際のデータベースの運用業務に携わりながら、データベースに関する専門知識を深めていきます。 今回のブログ記事では、データベースエンジニアとしての専門性を高めるために、部門内で実施している専門書の輪読会、そして、MySQLを題材としたデータベースカーネルのモブプログラミング（以下、モブプロ）の取り組みについてご紹介します。 1. 輪
結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは？ MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd
はじめに 過去の古いMySQLのバージョンでは、テーブル定義の変更を伴うようなDDLを実行する際には、元のテーブルとは別に新しいテーブルを作成し、元のテーブルデータを新テーブルにコピーした後に元のテーブルと入れ替えるといった手法で行われていました。 また、その間の対象テーブルへの更新はブロックされるといった挙動であった為、アプリケーションサービスを稼働中にDDLを実行するというのが、かなり敷居が高いものでした。 それが、MySQL5.5 より Fast Index Creation が採用され、InnoDBのセカンダリインデックスの作成、削除にはテーブルコピーを伴わないで実行できるようになり、処理の高速化が図られています。 その後、MySQL5.6 ではオンラインDDLが使用できるようになり一部のDDLでは、テーブルコピーを伴わずに、更新もブロックしないということが可能となり、更に MyS
Go の ORM はどのようにして AUTO INCREMENT で採番された値を取得しているのか？ - MySQL 編 - カミナシ エンジニアブログ
こんにちは。カミナシで「カミナシレポート」の開発を担当しているソフトウェアエンジニアの佐藤です。 カミナシレポートのバックエンドは Go で開発しており、データベースには Amazon Aurora MySQL を使用しています。また、データベースアクセスには ORM ライブラリの GORM を採用しています。 ほとんどのテーブルでは、プライマリキー（ID列）に AUTO INCREMENT を利用しています。これらのテーブルに GORM の Create メソッドなどを使って新しいレコードを挿入すると、AUTO INCREMENT で採番された値が自動的に対応する Struct のフィールドに反映されます。 AUTO INCREMENT による値の採番は MySQL 側で実行されているため、Go 側の Struct のフィールドに反映させるためには、Go アプリケーション側が何らかの方法
インデックスの"正解"を探せ！決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank
はじめに サーバーサイドエンジニアの kurisu(ryomak) です。 普段は、カード決済やあとばらいチャージに関連する機能の開発・運用を行っております。 本記事でお話しすること 本記事では、インデックス追加によって決済レスポンスタイムを改善した事例をご紹介します。具体的なインデックス設計の検討や実行計画の見直しを通じて、どのようにレスポンスタイムを最適化したのか、その裏側を詳しく解説します。インデックス追加によるパフォーマンスチューニングの際の参考になれば幸いです。 はじめに 本記事でお話しすること 決済処理の遅延の検知 事の発端 実行環境 原因調査 遅くなったクエリの特定 対応検討 方針 検証項目 インデックスの「アタリ」をつける ① オーソリゼーション履歴：(オーソリゼーションID, 承認番号,受信日時) ② オーソリゼーション：(カードID, 初回受信日時) ③ オーソリゼーシ
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 | Amazon Web Services
Amazon Web Services ブログ DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 DMM.com は動画配信事業とオンラインゲーム事業、FX 等の金融サービスを主力として、オンライン英会話サービスなど 60 以上のサービスを展開している企業です。DMM.com では、オンプレミスの MySQL で稼働していたユーザーレビュー機能を、Aurora MySQL に移行しています。データの移行は AWS Database Migration Service (DMS) を使用してダウンタイムを最小限に抑えつつ、移行元への逆同期や SageMaker を使用したデータ検証の仕組みなど、様々な工夫をしながら移行を成功させることができました。本ブログでは、DMM.com でオンプレミスの MySQL
◼️ はじめに ◼️ 前提条件 マシン環境 データベースについて ◼️ データ挿入に関して ◼️ 100万レコードでLIKE検索(前後の部分一致)と全文検索の比較 LIKE検索 全文検索 ◼️ EXPLAINで実行計画を確認 LIKE検索のEXPLAIN結果 全文検索のEXPLAIN結果 ◼️ EXPLAIN ANALYZEを確認 LIKE検索のEXPLAIN ANALYZE結果 全文検索のEXPLAIN ANALYZE結果 ◼️ リソース使用状況確認 全文検索のクエリのプロファイリングを確認 ◼️ INNODB_FT_INDEX_TABLEを確認 ◼️ テストデータを修正 最初に作成したレコード内容の一部 新たに作成したレコード内容の一部 LIKE検索 全文検索 ◼️ まとめ ◼️ 最後に ◼️ はじめに こんにちは！株式会社iimonでフロントエンジニアをしているあめくです！ 本記事は
MySQL 8.4 LTS登場！！
記事を書くのが遅くなってしまったが、先日MySQL 8.4シリーズが登場したので紹介をしておこうと思う。新機能の解説については機会を改めて書くとして、今回は主にアップグレードにまつわる重要なポイントを書き記しておく。 LTS = Long Term Support 以前の記事でも紹介した通り、MySQL 8.4はLTS = Long Term Supportのバージョンとなっている。長期間サポートするために互換性を最大限保証するバージョンである。前のメジャーバージョンであるMySQL 8.0シリーズのように、シリーズの途中で互換性が破壊されるような変更が入ることは基本的に無い。「バグ修正のためにどうしても仕様を変えなければならない」というような事態が生じる可能性はゼロではない。なので絶対に互換性が保たれるとは言い切れないところであるが、基本的には仕様変更はない方向で今後リリースされていくこ
こんにちは。スマートバンクでサーバーサイドエンジニアをやっております、@moznionです。 Webアプリケーションのパフォーマンスに問題が起きている時、みなさんはどのようにアプローチしていますか？ 私はISUCONで培ったテクニックを使うことが多いように思います。 今回はそのような「ISUCONで学んだ知見」が役に立ったパフォーマンスチューニング事例があったのでそのご紹介をできればと思います。 背景と課題 スマートバンクではカード *1 決済をサービスとして提供しており、この決済が快適に行なえているかどうかはサービスの品質を捉える上で重要な指標となります。 そこで我々はこの決済処理にかかる処理時間を「決済レイテンシー」と定義して1.5秒のSLI *2 を設定し、エラーバジェットを設定して継続的な監視を行なっています。 SLI/SLOの設計・運用の詳細につきましては同僚の@maaaatoに
プログラミングのきっかけは『ゆいちゃっと』、こんな楽しいことだけやっていてお金をもらえるんだ【Rubyistめぐりvol.5 onkさん 前編】 - STORES Product Blog
Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第5回はonkさんをゲストに迎えて、お話を聞きました。こちらは前編です。 hey.connpass.com 漫画禁止、ひたすら本を読む小学生時代 藤村：今回はonkさんに来ていただきました。よろしくお願いします。 Rubyistめぐりの趣旨を改めて説明すると、Rubyist Magazineというメディアに『Rubyist Hotlinks』という記事があって、いわゆるRubyistの人たちの生い立ちから仕事、プログラミングなどいろんな話を聞くコンテンツで、僕は駆け出しのエンジニアの頃にそれをすごく読んでました。めちゃくちゃ僕は影響を受けたし、いいなと思っていたので、もっと出ないかなと思ってたんですよね。 それでふと思いついて、この『Rubyistめぐり』という企画をさせてもらいました。今回はいつ
【MySQL】メジャーバージョンアップグレードの味方: “アップグレードチェッカーユーティリティ”を理解して活用しよう - Adwaysエンジニアブログ
あいさつ こんにちは！ 技術本部 技術戦略Div. リードエンジニアの関根です！ 2024年9月にジョインして、コツコツSRE活動を進めておりますっ エンジニア3年目ながらSREにゴリゴリ関われているのは、アドウェイズにオープンなコミュニケーションの文化があるおかげです。SREに少しでも興味がある人は、お待ちしておりますよ！ 最近、Netflix、アマプラ、U-NEXTに加えてAppleTVも契約してしまいました笑 映画やドラマの話しましょうね！ あとお酒が大好きなので、社内外問わず飲みに行きましょうね！！ この記事はなに？ この記事は、MySQLメジャーバージョンアップグレード時にアップグレードチェッカーユーティリティ(以下、アップグレードチェッカー)を理解して活用することで、効率的にアップグレードを進めるための情報を記載しています。 SREとして、EOL対応屋さん的な動きをコツコツやっ
【CTO協会研修記録】 未経験エンジニアがISUCONで圧倒優勝するまでの話 - PLEX Product Team Blog
はじめに こんにちは、2024年4月に株式会社プレックスに新卒入社した佐藤祐飛です。現在は建設業界向けSaaSプロダクト「サクミル」の開発に携わっています。 2024年7月31日に、日本CTO協会主催の新卒合同研修でISUCON研修が開催され、50万点を超えるスコアで優勝することができました。 CTO協会様主催のISUCON研修優勝しました🏆 実はISUCON研修に勝つために2ヶ月間準備していたのですが、その成果が出てよかったです🔥 後日、「ISUCON 研修をガチった話」と題してテックブログを投稿する予定なのでそちらもチェックしていただけると嬉しいです‼️#ctoawakate https://t.co/fUr2hf8rkr pic.twitter.com/7FxYbmiIBu— yuhi (@yuhi_junior) 2024年7月31日 ISUCONは若手エンジニアにとってハード
Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 | Amazon Web Services
Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。 Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについて
Want to learn more about Vitess, horizontal sharding, or Enterprise options? Talk to Solutions By Benjamin Dicken | September 9, 2024 What is a B-tree?The B-tree plays a foundational role in many pieces of software, especially database management systems (DBMS). MySQL, Postgres, MongoDB, Dynamo, and many others rely on B-trees to perform efficient data lookups via indexes. By the time you finish t
MySQL/Aurora/TiDBロック入門 – 第２回ロックモニターの読み方【動画解説付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第２回ロックモニターの読み方【動画解説付】 MySQL とその互換 DB のロックやトランザクションの挙動を紹介する入門シリーズ、「第１回 トランザクション分離レベル」 では READ COMMITTED や REPEATABLE READ でどういう挙動になるか紹介しました。 第２回目の今回は MySQL InnoDB のロックモニターの読み方、使い方について解説します。MySQL のロック機構を理解するツールとして便利なのでぜひご一読ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７
この記事は、『Software Design 2024年6月号』（2024年5月17日発売）の第1特集「SQLチューニングする前に知っておきたい 実行計画＆インデックスのしくみ」の連動企画です。ぜひ本誌特集1もお読みください。 適切なインデックスを設計する インデックスの調整によるクエリの高速化は、RDBMSを使用する際の数あるチューニングテクニックの中でも最もお手軽なものです。テーブルのカラムの定義を変えるわけではないので、クエリの結果に違いが生じず、アプリケーションを変更する必要性がないからです。適切なインデックスを付与するだけでチューニングが済むというのは極めて効率的です。それでは適切なインデックスとはどのようなものでしょうか。本記事では、まずインデックスを設計する際に重要なポイントを解説します。 インデックスとSQL構文 「どのカラムの組み合わせに対してインデックスを作成すべきか」
Amebaの大規模Aurora MySQLクラスタでのサービス無停止アップグレードへの挑戦 | CyberAgent Developers Blog
この記事は CyberAgent Developers Advent Calendar 2024 9日目の記事です。 こんにちは、Serveice Reliability Group(SRG)の鬼海 雄太(@fat47)です。 SRGは主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事ではアメーバブログを中心としたサービスの大規模Aurora MySQLクラスタを、サービス無停止でアップグレードするためにどのような取り組みをおこなってきたかをお伝えします。 Amebaの大規模Aurora MySQLクラスタについて アメーバブログは2004年にオープンしたブログサービスであり、今年20周年を迎えた長期間運用されているサービスです。Amebaは、このアメーバブログを中心に様々なサービスで構成され
はじめに 新卒エンジニア研修を担当しました ugo です！ 今年も新卒エンジニア研修を実施し、全カリキュラムが無事終了しました。 この記事では、各研修の講師を担当したメンバーが、新卒エンジニア研修のカリキュラムの内容と研修資料をまとめました。ぜひご覧ください。 2024年度新卒エンジニア研修概要 新卒エンジニア研修のコンセプトは 「サービスを作るための技術要素や観点について、現時点で良いやり方を一通り学ぶ」 と設定しました。 サービスを運用していくために必要なオブザーバービリティといった領域も今年から研修に盛り込みました。 研修に参加した新卒エンジニアは3名です。 オフィス内はフリーアドレスとなっていますが、研修のためオフィスに固定席を設け、1ヶ月に1回程度の頻度でオフィスの別に席に移動する形態で実施しました。講師も新卒エンジニアの近くに座ることで、相談をしやすい環境づくりを行いました。
MySQL/Aurora/TiDBロック入門 – 第４回 INSERTを止めるインテンションロック【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第４回 INSERTを止めるインテンションロック【解説動画付】 MySQL とその互換 DB のロックの挙動を紹介する入門シリーズ、第４回はギャップロックとインテンションロックによって INSERT をブロックする仕組みについて解説します。 第１回 トランザクション分離レベル で解説したように、MySQL の特徴でもある REPEATABLE READ によるファントムリードの防止に関わっているところですので、ぜひお手元でも観察してみてください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回
Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 | Amazon Web Services
Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 2 を翻訳したものです。 最初のパートでは、 Amazon Aurora MySQL互換エディション v2 から v3 へのアップグレードの事前チェックが失敗する原因となる最も一般的な問題を説明しました。この投稿ではアップグレードが長引いて失敗する最も一般的な原因について説明します。 クラスターにプリ
私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】 - Findy Tools
公開日 2024/05/24更新日 2024/07/25私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】 近年データベースが急速に進化し、開発にも大きな影響を与えています。そこでファインディでは「私たちはなぜNewSQLを使うのか TiDBを選定・導入した5社が語る選定と活用」と題したイベントを開催。PingCAPの日下さん、LINEヤフーの佐伯さん、アイスタイルの鈴木さん、DMM .comのpospomeさん、コロプラの曽我さん、さくらインターネットの江草さんをお招きし、NewSQLの一つである TiDBについて語っていただきました。 ■パネリスト日下 太智さん / @ksk_tic PingCAP株式会社 プロダクトマネージャー / シニアソリューションアーキテクト SIerにて国内外問わずEC/小売/製造/サービス/メディア/出版など様々
念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 前のエントリでは、MySQL 8.0は、clangのPGO+LTOでビルドしないと本来の性能が出ない。ということを証明しました。その後、PGO+LTOといってもプロファイリングをどうしたらいいのかと、デスクトップマシンの空き時間でひたすらビルドとtpcc(ramfs)を繰り返した結果、興味深いことがわかりました。 tpccのようなある程度複雑なベンチマークは、 ベンチマークそのもの（この場合tpcc）をプロファイリングするよりも、 mysql-testのスクリプトを組み合わせて工夫したほうが性能が出る ということです。（少なくとも私の環境で、ではですが） つまり、 ビルドしてテストスクリプトが流せる環境であれば、総合的に最適に近いバイナリが生成できるということです。誰でもビルドできま
MySQL/Aurora/TiDBロック入門 – 第５回 WHERE 条件と違うロック読取り【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第５回 WHERE 条件と違うロック読取り【解説動画付】 第５回は REPEATABLE READ と READ COMMITTED の分離レベルの違いによって変わったり、WHERE 条件で感じる直感的な範囲とは一致しない範囲でかかるなど、MySQL のロック読取りの挙動について解説します。 ロック読取りは実戦でよく使われている重要な手法で、細かい挙動も重要なポイントになります。動画と合わせて是非ご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロックと消えるロック ★ 第
Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL | Amazon Web Services
AWS Database Blog Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL Purge is a housekeeping operation in a MySQL database. The InnoDB storage engine relies on it to clean up undo logs and delete-marked table records that are no longer needed for multiversion concurrency control (MVCC) or rollback operations. While our applications pursue a database design that aims
MySQLのInnovation ReleaseとなるMySQL 9.0が2024年7月、MySQL 9.1が2024年10月にリリースされました。今回は、その中から気になる新機能をいくつかピックアップして、簡単に紹介したいと思います。 MySQL 9.0の新機能 ここでは、MySQL 9.0の新機能について紹介します。 EXPLAIN ANALYZEのJSONフォーマット結果をユーザー変数へ格納可能に EXPLAIN ANALYZEのJSONフォ−マット結果をユーザー変数に格納することができるようになりました。 EXPLAIN ANALYZEのJSONフォーマットを利用するには、システム変数explain_json_format_versionを2に変更してから実行する必要があります。デフォルトは1になっています。 INTO句後に格納するユーザー変数を指定します。 mysql> SET
Aurora MySQLとRedshiftのゼロETL統合が本番導入出来るか検証しました - クラウドワークス エンジニアブログ
Aurora MySQL Zero ETL Integrations クラウドワークスのSREチームに所属しています@ciloholicです。 2023年11月にAurora MySQLとRedshiftのゼロETL統合がGAされました。この度、ゼロETL統合が本番導入可能かを検証する機会があったので、その検証結果を記載します。 aws.amazon.com 2024年7月時点での検証結果ですので、時間経過によって内容が変わっている可能性があります。その点は十分ご注意ください。 背景 まず、ゼロETL統合の検証しようと考えた背景について軽く説明したいと思います。クラウドワークスでは、MySQLのテーブルをDMS経由でRedshiftにニアリアルタイムで同期し、データ分析を行なっています。3年前は約30億レコードでしたが、現在では古いレコードの削減を行なったため、約25億レコードになりました
Binary logging optimizations in Amazon Aurora MySQL version 3 | Amazon Web Services
AWS Database Blog Binary logging optimizations in Amazon Aurora MySQL version 3 The binary log (binlog) in MySQL is used to capture database modifications on a MySQL server in a logical format known as “events”. These database modifications can include DCL statements (such as CREATE USER or GRANT), DDL statements (CREATE TABLE, ALTER TABLE) and DML statements (INSERT, UPDATE, DELETE). When such a
目次[非表示] 1.はじめに 2.SQLとElastic Searchの違いとは？ 3.Elastic Searchの環境構築(Mac) 4.何を検証するのか 4.1.レコード数での比較 4.1.1.テストデータの準備 4.1.1.1.SQL側の準備 4.1.1.2.Elastic Search側の準備 4.1.2.検証 4.1.3.結果 4.2.文字数の速度比較 4.2.1.テストデータの準備 4.2.2.検証 4.2.3.結果 4.3.重複文字で比較 4.3.1.テストデータの準備 4.3.2.検証 4.3.3.結果 5.まとめ 5.1.結果の分析 5.2.結果 6.お悩みご相談ください はじめにこんにちは、株式会社divxでエンジニアをしている清水です。 以前、私はプロジェクト内でElastic Searchを導入するか、あるいはSQLのフルテキストインデックスを使用して全文検索を行
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog
MySQLのロックに起因するブロックタイムアウト撃退記 - inSmartBank
explainだけじゃわからない！MySQLのindexの考え方 - BASEプロダクトチームブログ
Ultimate Guide to Improving MySQL Query Performance
データベースエンジニアのスキルアップ 専門書輪読会とMySQLモブプロの取り組み
RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)
MySQLでオンラインでDDLを実行する際の注意点について | スマートスタイル TECH BLOG
MySQL 8.0 は遅くなってきてる？何故？（１）
MySQLで全文検索機能を試したら実行速度が遅かったので調査してみた - iimon TECH BLOG
ISUCONが業務に役立つ瞬間 - 決済処理時間の悪化を解決するまでの軌跡 - inSmartBank
B-trees and database indexes — PlanetScale
［Software Design連動企画］ 実践クエリチューニング | gihyo.jp
2024年度新卒エンジニア研修を実施しました! - Pepabo Tech Portal
MySQL 8.0 の速いバイナリを作ってみよう
第233回 MySQL 9.0と9.1の新機能について | gihyo.jp
SQLのFULLTEXT INDEXとElastic Searchの速度比較 | 株式会社divx（ディブエックス）