並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 572件

新着順 人気順

InnoDBの検索結果41 - 80 件 / 572件

  • C言語でSQLiteのクローンを作るチュートリアルやった - valid,invalid

    2019年12月の冬休みに1週間程かけて"Let's Build a Simple Database"という、C言語でSQLiteのクローンを作るチュートリアルをやりました。この存在を教えてくれた同僚に感謝 :pray: cstack.github.io チュートリアルの内容 Richard Feynman先生の“What I cannot create, I do not understand.”という言葉が掲げられているように、データベースを作ることでデータベースをより深く理解することに主眼が置かれているチュートリアルです。 これは重要事項説明かつタイトル詐欺に関する謝罪なのですが… 残念ながらこのチュートリアルは完成しておらず、Part 13が2017-11-26に公開されたのを最後に更新が止まってしまっており、以下の13章しかありません。 Part 1 - Introduction

      C言語でSQLiteのクローンを作るチュートリアルやった - valid,invalid
    • Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり - Repro Tech Blog

      Apple Silicon の時代が来る Repro でサーバーサイドの開発をお手伝いしているうなすけと申します。 2021年10月19日に行われた Apple の新製品発表において、M1 チップを搭載した MacBook Pro が発表されました。この発表により、Intel チップを搭載した MacBook はラインナップから消え、今後は M1 チップ上で開発する機会が増えることは確実です。 ところで、私達の開発環境は M1 に対応しているのでしょうか? 社内の開発メンバーの大半は MacBook を使用しているので、もし対応していない場合、なるべく早く対応させないと新しい社内端末を購入できなかったりするので、結構影響が大きいです。 またインターネット上で、M1 Mac を使用している人々からの「全然発熱しない」だとか「ファンが回ることがない」とか「電池の持ちがすごい」とかの良い評判を目

        Repro のサーバーサイド開発環境を M1 Mac に対応させるまでの道のり - Repro Tech Blog
      • 未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却

        未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却 Inside of Blog 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦 #2/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」に登壇したのはLINE 開発Bチームの大森貴博氏。後半パートとなる今回は、現役で稼

          未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却
        • MySQLエキスパートyoku0825が目指す、DBAとしての未来像

          LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」。LINEの技術組織で働く人々に、何を重視して技術者としてのキャリアを歩んでいるのか、今LINEで何に取り組んでいるのか、今後実現していきたいことなどを聞いていきます。 今回登場するのは、MySQLエキスパートとして広く名を知られる田中翼(@yoku0825) 。日本人として3人目のMySQL分野のOracle ACEであり、2015年には「default_password_lifetime」の功績でMySQL 5.7 Community Contributor Awardに選出された田中は、2021年6月よりLINEのITSC DB

            MySQLエキスパートyoku0825が目指す、DBAとしての未来像
          • プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空

            zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体

              プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空
            • MySQL で複合インデックスを作成する際には必ず Explain の key_len を確認すべきという話

              「Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました」でちゃんと触れられてないので今更ながら key_len について補足します。発表で触れた内容については言及しないので、storage engine や B+ tree といった用語がよくわからない方は発表内容を参照してください。 なお、MySQL のバージョンは 5.7.38 です。 mysql> SELECT @@version; +-----------+ | @@version | +-----------+ | 5.7.38 | +-----------+ 1 row in set (0.00 sec) 事前準備 sample-data-railsdm-2018 の orders テーブルを少しいじって、キャンセル時刻(canceled_at)、配送予定時刻(deliv

                MySQL で複合インデックスを作成する際には必ず Explain の key_len を確認すべきという話
              • ISUCON12 予選の解説 (Node.jsでSQLiteのまま10万点行く方法) : ISUCON公式Blog

                ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCON12 予選の解説 (Node.jsでSQLiteのまま10万点行く方法) こんにちは、面白法人カヤックのacidlemonです。例年ISUCONに参加するたびにとても長い「やったこと」ブログを書いているので、もしかしたらそちらを読んだことがある人もいるかもしれません。 ISUCONの公式サイトに記事を書くのは ISUCON3の予選の解説 以来でしょうか。今回もacidlemonが解説、fujiwaraが講評を書く予定ですので、お楽しみに。あ、そういえば先日掲載していただいた 面白法人カヤックからの応援メッセージ の脳内インタビューも私が書いていますのでよく考えたらそれ以来ということになるのかもしれません。予選

                  ISUCON12 予選の解説 (Node.jsでSQLiteのまま10万点行く方法) : ISUCON公式Blog
                • MySQL即効クエリチューニング読んだ - $shibayu36->blog;

                  MySQL即効クエリチューニング ThinkIT Books 作者:yoku0825インプレスAmazon 最近クエリチューニングの仕事があったので、少し深めに知ろうと読んだ。 MySQLの内部構造がどうなっているかは置いておいて、どうすればクエリの問題を把握できるかが素早く知れる良い本だった。90ページくらいですぐ読めるのも良い。個人的にはHandler_%変数を使った調査、innotopによる状況可視化、sys.innodb_lock_waitsによるロック状況の可視化あたりが非常に参考になった。 ちなみにさらに内部構造に踏み込んで理解しようとするなら、以下の記事がおすすめ。 雑なMySQLパフォーマンスチューニング MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ Rails Developers Meetup 2018 で

                    MySQL即効クエリチューニング読んだ - $shibayu36->blog;
                  • 「MySQLのフェイルオーバーテストをする」と聞いてぼんやり思ったこと

                    TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdがmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか

                    • MySQL 5.7 to 8 check list

                      mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死

                        MySQL 5.7 to 8 check list
                      • ISUCON9の予選を突破し、失格になったのちに通過しました - akenshoの日記

                        参考:チームメイトの記録です 本番前に行ったこと 競技環境の把握 重要文献を読んでおく 盆栽(本番で使用する ansible role)に手を入れる チーム練習をする 本番で行ったこと 初期状態の把握 初回のベンチマーク実行 初期セットアップ 各種マニュアルを読む モニタリングツールを実行しながらのベンチマーク実行 pprof 導入後のベンチにおいて 完走しないベンチマーク 収集する 順位表を確認する ボトルネックの再調査とそれを潰す作業 複数台構成を考え始める 平文保存はダメです Index 関連の作業が終わり、二度目の質問 getSimpleUserByID のデバッグをする 例のアレ 再収集 再起動試験 ログを全部切る 最終ベンチを実行する 以上が純粋な競技記録です ここから先は競技終了後の話です 失格の根拠について 失格取り消しの根拠について 運営チームの取れる・果たせる責任につい

                          ISUCON9の予選を突破し、失格になったのちに通過しました - akenshoの日記
                        • MySQLでNested Loopなクエリはインデックスをどう辿っているか - $shibayu36->blog;

                          タイムライン的なものをSELECTだけで実装しようと思った時に、Nested LoopなクエリでUsing temporary; Using filesortが出るようなそこそこ遅いクエリになる。その時にMySQLがインデックスをどう辿っているかを知りたかったので調べてみた。MySQLバージョンは8.0.33。 あまり自信はないので、もし間違った話をしていたら教えて欲しい。 どのようなクエリを検証するか タイムラインの取得ができるような、ユーザー・フォロー関係・投稿の3つのテーブルを作る。スキーマは次の通り。 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL ); CREATE TABLE follows ( id INTEGER PRIMARY KEY AUTO_I

                            MySQLでNested Loopなクエリはインデックスをどう辿っているか - $shibayu36->blog;
                          • ISUCON11 予選問題実践攻略法 : ISUCON公式Blog

                            DB は以下のコマンドで確認できる通り、MariaDB 10.3 でした。$ mysqld --version mysqld Ver 10.3.31-MariaDB-0ubuntu0.20.04.1 for debian-linux-gnu on x86_64 (Ubuntu 20.04) 当日マニュアルに記載の通り、各言語実装は systemd で管理されているため、systemd に関する知識があると良いと思います。特に、アプリケーションを編集しビルドした後、 systemctl restart isucondition.go.service を実行しないと編集が反映されないことに注意しましょう。 他にも例えば、isucondition がどのように環境変数を読み込んでいるかを調べるには以下のような手順で行えます。 当日マニュアルの参考実装の項目を読み、サービス名が isucondit

                              ISUCON11 予選問題実践攻略法 : ISUCON公式Blog
                            • EmbulkでPostgreSQLをMySQLに移行した話 - LIVESENSE ENGINEER BLOG

                              こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの mnmandahalf です。 先日、マッハバイトの販売管理システムで使っているデータベースをオンプレPostgreSQLからAmazon Aurora MySQLに移行しました。 本記事では移行に至った背景、吸収する必要があった差分や苦労した点についてお話しします。 環境 移行前のバージョン: PostgreSQL 9.4 ※ドキュメントはバージョン14のものを添付しています 移行後のバージョン: Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23) 環境 MySQL移行の背景 データ移行方法の検討 Embulkの実行で考慮したポイント Embulkの設定 scram-sha-256認証への対応 タイムスタンプが9時間巻き戻る FK制約を無効化できない PostgreSQLとM

                                EmbulkでPostgreSQLをMySQLに移行した話 - LIVESENSE ENGINEER BLOG
                              • MySQLの物理削除によるパフォーマンスの悪化とその回避策について

                                ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめまして、Yahoo!ショッピングでシステム開発を担当している村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える巨大なDBの運用の中で遭遇したMySQLのアンチパターンと、回避した方法について紹介いたします。 特定のテーブルをJoinするとすごく遅くなる Yahoo!ショッピングでは商品を出品するためのツールがあります。 商品情報には「商品名」「価格」といった、任意で設定可能な項目のほか、「ブランド」「商品種別」など、製品ごとに入力する内容が決まっている項目を、マスター情報としてテーブルで管理しています。 このマスター情報を利用して、出品の際に入力情報が正確であるかどうか確か

                                  MySQLの物理削除によるパフォーマンスの悪化とその回避策について
                                • AWS Aurora MySQL Parallel Query の基礎研究 | 外道父の匠

                                  AWS Aurora MySQLには、高性能を期待できる Parallel Query という機能があります。 実際、良いモノっぽいのですが、非常に情報が少ないので私めがいつものように掘り下げて、お役に立てればという徳を積む行為であります。 目次 Parallel Query とは リンク集 速度比較 費用の仕組み 設定による有効・無効 有効にできない条件 Parallel判定されるクエリ 結合クエリ innodb_buffer_pool_size との関係 その他 実践では Parallel Query とは 詳しくは下記リンクを見たほうがいいのですが、頑張って要約してみます。 通常のDB処理は、データを可能な限りメモリ上に置いておいて処理しようとしますが、オンメモリじゃないデータはストレージから取得する必要があり、データ取得後はDB本体における1スレッドがクエリ処理を行います。 Aur

                                    AWS Aurora MySQL Parallel Query の基礎研究 | 外道父の匠
                                  • Amazon Aurora MySQLの不具合でローカルディスクが枯渇しクエリが実行出来なくなった話 - Kaizen Platform 開発者ブログ

                                    SRE Group Managerをしている前田です。今回の記事は当社で遭遇したAmazon Aurora MySQLの不具合の話になります。 3行まとめ Amazon Aurora MySQLのローカルストレージが異常な速度で消費、枯渇しクエリを実行するとエラーが発生するようになった 原因調査とAWSサポートへの問い合わせの結果、Aurora MySQL 2.10.0 の不具合と判明し、2.10.2へバージョンアップで解消 Auroraのローカルストレージは自動拡張されないので、残容量の監視をしましょう 事象発生と解決までを時系列で記載。 2021年10月、Auroraに対してクエリが実行出来なくなる 社内メンバーよりBIツールからAurora MySQLに対してのクエリがエラーになるとのことで、クエリに limit 100 を付けると実行出来、 limit 1000だと Error w

                                      Amazon Aurora MySQLの不具合でローカルディスクが枯渇しクエリが実行出来なくなった話 - Kaizen Platform 開発者ブログ
                                    • Aurora MySQL 5.7とRailsで実現する全文検索機能 - dely Tech Blog

                                      こんにちは。 クラシル開発部、バックエンドエンジニアの松嶋です。 delyに入社してから約3年間、私はSREチームに所属していましたが、昨年10月にバックエンドに転向しました。バックエンドに転向してからは、主にクラシルアプリの公式レシピおよびCGMコンテンツの検索機能に関する開発・改善に取り組んでいます。 クラシルは、2016年2月にサービスを開始してから、管理栄養士監修の「誰でも安全に・おいしい料理を作ることができるレシピ動画」を5万件以上提供してきました。 昨年12月には、クラシルのブランドリニューアルを行い、今後はシェフや料理研究家を中心としたクリエイターとともに多様化したユーザーの食の好みや課題解決に応えられるよう、幅広い食のコンテンツを提供するプラットフォームを目指しています。 ブランドリニューアルの詳細に関しては、こちらを御覧ください。 www.kurashiru.com この

                                        Aurora MySQL 5.7とRailsで実現する全文検索機能 - dely Tech Blog
                                      • 最近のMySQL 8.0 の内部一時テーブルの改善について

                                        MySQL では sort_buffer_size 以上にソート領域が必要になった場合、もしくは一部の条件に当てはまるSQLについては、内部一時テーブルを作成し処理を行うという仕組みになっています。 8.4.4 MySQL での内部一時テーブルの使用 この内部一時テーブルの仕組みに MySQL 8.0 から TempTable ストレージエンジンを利用する事ができるようになりました。 TempTable ストレージエンジンの挙動については、過去の弊社ブログ記事で説明しています。 TempTable ストレージエンジンについて TempTable ストレージエンジンはMySQL 8.0で導入されたということもあり、初期パッチバージョンに比べて改善が行われています。 今回の記事では、TempTableストレージエンジンの最近追加された機能についてご紹介します。 基本的なソートバッファと内部一時

                                          最近のMySQL 8.0 の内部一時テーブルの改善について
                                        • 表示順という属性を別テーブルに分ける - そーだいなるらくがき帳

                                          最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順)は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順

                                            表示順という属性を別テーブルに分ける - そーだいなるらくがき帳
                                          • ChatGPTを使ってDDLからER図をすばやく作成する - Taste of Tech Topics

                                            最近、酢を飲むと健康に良いという話を聞き、頑張って毎日飲んでいるkonnoです。 何となくですが、朝の目覚めは良くなっている気がしますよ! 今回はデータベース設計に欠かせないER図を、ChatGPTを使ってDDL(Data Definition Language:SQLのデータ定義言語)から簡単に作成できるのか試してみたいと思います。 サンプルとなるDDLを用意 DDLのサンプルとして、以下のMySQL公式サイトで公開されている従業員データベースを利用します。 dev.mysql.com 従業員データベースに必要なファイル類一式は、上記サイトで紹介されている以下のGithubリポジトリから、 "test_db-master.zip"としてダウンロードできます。 github.com ダウンロードしたtest_db-master.zipには、従業員データベースを設定するために必要なDDLとし

                                              ChatGPTを使ってDDLからER図をすばやく作成する - Taste of Tech Topics
                                            • Railsアプリの処理を100倍以上に高速化して得られた知見 | Recruit Tech Blog

                                              はじめまして。2019年4月から妊娠・出産アプリ『Babyプラス』の開発チームにJOINした濱田です。 『Babyプラス』のバックエンドはRailsで実装されているのですが、とあるCSV生成処理がとても遅かったので100倍以上に高速化しました。この過程でRailsアプリの処理高速化に関する以下の知見が得られたので、具体例を交えて共有します。この知見は、ActiveRecordを使用してMySQLなどのRDBMSからデータ抽出をする様々な場面で活用できると思います。 いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い pluckはjoinsと組み合わせることで他テーブルのカラム値も取得できる 前提: DBスキーマとデータ規模 今回の処理高速化に関わるモデルのDBスキーマとデータ規模は以下の通りです。なお、これらは本エントリ向けに少

                                                Railsアプリの処理を100倍以上に高速化して得られた知見 | Recruit Tech Blog
                                              • 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対応)
                                                • InnoDBのすゝめ(仮)

                                                  InnoDBの特性など考慮しつつ、ゲーム向けのDBやSQLを設計する上でのヒントや、注意するポイントなどです。Read less

                                                    InnoDBのすゝめ(仮)
                                                  • Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog

                                                    こんにちは ハタ です。 Mirrativのインフラ内で実際に開発・運用している内製のRedisサーバについてお話したいなと思っています。 前回の記事 は、今回紹介する内製Redisサーバで起きたメモリリーク対策に関するお話しとなっておりますので、もし未読であればあわせて読んでいただければと思います。 今回はなぜ Redis サーバを内製することにしたのかの経緯や実装についての簡単な紹介が出来たらなと思っています Redis 導入の経緯 課題感: 揮発しないでほしい 課題感: 生存時間が短いデータを保持したい 課題感: 日次データをなんとかしたい 候補 Redis Cluster のヨシアシ: slot 管理 Dynomite のヨシアシ: sharding/replication radisha = Raft + Redis + HA Raft クラスタ コマンドとデータストア レプリケ

                                                      Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog
                                                    • MySQLの容量とか圧縮まわり

                                                      APIdays Paris 2019 - Innovation @ scale, APIs as Digital Factories' New Machi...

                                                        MySQLの容量とか圧縮まわり
                                                      • 開発/Stg環境のための本番DBマスキングと継続的リストアの仕組みを作りました | ランサーズ(Lancers)エンジニアブログ

                                                        SREチームの安達(@adachin0817)です。今回はMENTA、Lancers Creative、Lancers Agencyでマスキングした本番環境のデータをStgや開発環境のMySQLコンテナへ毎週リストアする仕組みを実装しました。実際にここらへんは運用をしていく中で一苦労されている方も多いのではないでしょうか。それではまず背景と、実装するに当たっての活動含めてご紹介できればと思います。 背景 今回はMENTAを例にしています。各サービスの開発環境はDockerを利用しており、本番とStg環境はTerraformで管理しています。カラム追加ではマイグレーションを実行することでサンプルのスキーマファイルを投入して開発をしているのですが、たまに開発環境で動いていたソースがStgや本番で動かないといったことで開発効率が下がることが見受けられます。開発メンバーにとってはより本番環境に近い

                                                          開発/Stg環境のための本番DBマスキングと継続的リストアの仕組みを作りました | ランサーズ(Lancers)エンジニアブログ
                                                        • ストレージエンジンの話 ~InnoDBのredo logをざっくり理解する~ - shallowな暮らし

                                                          こんにちは。id:shallow1729です。最近Database Reliability Engineerというお仕事を始めたのでデータベースの勉強をしたりMySQLのソースコードを読んだりしています。仕事でMySQLが標準で用いているInnoDBのソースコードを読む機会があったのでなんかアウトプットしたいなと思いつついきなりコアな話するのもなって思ったのでざっくりとストレージエンジンの話をしようかなと思います。とはいえストレージエンジンは本当にいろいろな仕事をしていて全部を書こうとするとものすごい事になりそうだった(+僕も分かってない部分が多い)ので、とりあえず第一回はredo logというやつを中心にストレージエンジンを追っていこうと思います。なるべく一般的なデータベースの設計の話を軸に置きつつInnoDBの場合の話もしていこうと思います。読者としてはMySQLのようなリレーショナル

                                                            ストレージエンジンの話 ~InnoDBのredo logをざっくり理解する~ - shallowな暮らし
                                                          • MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する - それが僕には楽しかったんです。

                                                            はじめに MySQL をビルドする ストレージエンジンを自作する Example エンジンをベースにする handlerton の作成とインスタンス化 テーブルを作成する 余談・気になったところ テーブルを開く INSERT の実装 ha_tina の存在 テーブルスキャン store_lock の実装 external_lock の実装 rnd_init の実装 info の実装 extra の実装 rnd_next の実装 おわりに はじめに 卒論書くのに飽きてきて何かやりたくなったので急にストレージエンジンを書くことにしてみた。 MySQL のストレージエンジンを実装していく中で、色々できるかなと思っていたけど、やってみると MySQL の内部実装について色々知らないといけないことが多くインデックスとかトランザクションとかそういうところは実装できなかった。 github.com My

                                                              MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する - それが僕には楽しかったんです。
                                                            • 第1回 DBサーバの構造を知ろう! | gihyo.jp

                                                              本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる』が2019年8月26日に発売予定です。本記事と併せてご活用ください。 ゲーム開発におけるRDBMSの役割 RDBMS(Relational DataBase Management System)は業務システム(以下、業務系)で多くの実績を作ってきました。一方でゲーム分野(以下、ゲーム系)では、RDBMSはほとんど使われていませんでした。ネットゲームではなく、スタンドアローンのゲームが中心だったので、プレーンなテキストやバイナリ形式でデータを保存していたからです(スタンドアローン環境向けのSQLiteもまだ

                                                                第1回 DBサーバの構造を知ろう! | gihyo.jp
                                                              • 決済システムのマイクロサービス化に伴うデータ移行について | メルカリエンジニアリング

                                                                この記事は、 Mercari Bold Challenge Monthの16日目の記事です。 こんにちは。株式会社メルペイのPayment Platform teamに所属している @ogataka50 です。 メルペイではマイクロサービスアーキテクチャで決済システムを開発、運用をしています。 メルペイはNFC決済・QR/バーコード決済・ネット決済を提供しています。それらに加えて、メルカリ内決済のコンビニ/ATM払い、キャリア決済、クレジットカード決済等も提供しています。 メルペイの決済システムはメルカリの決済システムをマイクロサービスとして切り出されたのが始まりになっています。 メルペイはアプリとしては2019年2月13日にサービスリリースしましたが、システム的にはその少し前からメルカリ内の決済機能をマイクロサービス化するため先にリリースされていました。 今回はメルペイリリース前に行われ

                                                                  決済システムのマイクロサービス化に伴うデータ移行について | メルカリエンジニアリング
                                                                • ISUCON13で優勝しました(チーム NaruseJun)

                                                                  11月25日に開催されたISUCON13でチームNaruseJunとして参加し優勝しました。 メンバーはここ4年同じで、大学時代のサークル仲間の@sekai・@takashi・とーふとふの三人です。 昨年のISUCON12でも優勝したので、チームNaruseJunは二連覇となります。 最終スコアは468,006点でした。 スコアの推移は以下の通りです。 かなり順調にスコアを伸ばしていますね。後述しますが17時直後にめちゃくちゃ伸びているのは、ログを止めた結果です。 その他のスコアは↓ ISUCON13 受賞チームおよび全チームスコア : ISUCON公式Blog 事前準備 今年はチーム全員が忙しかったので、チームで最初に集まったのは11/14でした。 その日は30分くらいで今年の流れの確認と、素振りの日(11/18)を確定して解散しました。 ありがたいことに過去優勝チームとしてLodgeで

                                                                    ISUCON13で優勝しました(チーム NaruseJun)
                                                                  • [MySQL]AUTO_INCREMENTのidが戻る

                                                                    こんにちは、M-Yamashitaです。 今回の記事は、MySQLのAUTO_INCREMENTのidが戻ってしまう話です。 以前、RailsとMySQLを使うサービスにて、Mysql2::Error: Duplicate entry 'xxx' for keyが発生しました。このエラーの原因を調べたところ、テーブルでAUTO_INCREMENTとなっているカラムのidが戻って採番されており、その影響でエラーが発生していることがわかりました。当時の私の認識では、AUTO_INCREMENTとなっているidは、戻って採番されることはないと思っていたので非常に驚きました。 そのため、このidが戻る現象について調べて記事にしたいと思い、執筆しました。 なお、この記事ではMySQL 5.7を使用しています。 この記事で伝えたいこと MySQL再起動によりAUTO_INCREMENTのidが戻って採

                                                                      [MySQL]AUTO_INCREMENTのidが戻る
                                                                    • 不揮発性メモリでのデータベース処理最適化 〜 ヤフーにおけるデータベース技術の研究開発

                                                                      ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! ヤフーでデータベースエンジニアをしている松浦です。 インターネットサービスを作る上で、そのデータの保持・管理を担うデータベースは重要なソフトウエアコンポーネントですが、今回のTech Blogでは、ヤフーにおけるデータベース技術の研究開発についてのお話をします。 ヤフー社内では、さまざまなデータベースを運用していますが、そのデータベースを最新のハードウエアに対応させる研究開発を行っています。 具体的には、不揮発性メモリを有効に活用するMySQLのストレージエンジン「Leo」の開発に取り組んでいます。 本日は、Leoについて簡単にご紹介をします。 不揮発性メモリとは? まず、前段として、Leoのお話をする前に、不揮発性

                                                                        不揮発性メモリでのデータベース処理最適化 〜 ヤフーにおけるデータベース技術の研究開発
                                                                      • Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog

                                                                        こんにちは、バックエンドエンジニアのmakinoです。先日、LINE LIVEさんとの共催イベントにて「Mirrativを支えるバックエンド開発 ~MySQLとの向き合い方~」というテーマでLTをしました。 connpass.com speakerdeck.com 今回はLTの内容から一部抜粋して、Mirrativのバックエンド開発において遭遇したMySQLに関する問題と、その対策について紹介します。 問題 その1 データ量/QPSの増加に伴って、非効率なクエリが顕在化した サービス初期の段階ではデータ量が少なかったり、ユーザーのアクティビティが少ないために問題がなかったクエリも、サービスの成長に伴ってデータ量・QPSが増加したことによって、MySQLに負荷をかけてしまうことがありました。 具体例を以下にいくつか示します。 数千件レコードのfilesort 適切なindexが利用できればM

                                                                          Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog
                                                                        • Aurora MySQL におけるロック競合(ブロッキング)の原因を事後調査できる仕組みを作った話

                                                                          こんにちは。 DBRE チーム所属の @p2sk です。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE チーム発足の背景やチームの役割については「KTC における DBRE の必要性」というテックブログをご覧ください。 本記事では、Aurora MySQL でロック競合(ブロッキング)起因のタイムアウトエラーが発生した際に根本原因を特定することができなかったので、原因を後追いするために必要な情報を定期的に収集する仕組みを構築した

                                                                          • Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering

                                                                            こんにちは、IT基盤部の川原﨑です。 私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。 はじめに 第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。 例えば、 イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する などです。 これはWebサーバだけにとどまらず、DBサーバについても同様です。 EC2上でMySQLを運用している環境では、フェイル

                                                                              Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering
                                                                            • 一般公開された Amazon Aurora Serverless v2 を東京リージョンで試してみた | DevelopersIO

                                                                              動作確認 初期ACU 作成直後のAmazon Aurora Serverless v2 のACU値を、CloudWatchのメトリック「ServerlessDatabaseCapacity」で確認しました。 インスタンスの作成直後のACUの値は32でした。 無負荷状態では、最小ACUの指定値(今回は8)まで段階的に低下していました。 INNODB_BUFFER_POOL_SIZE CLIを利用し、ACU値「8」で稼働中のDBの状態を確認しました。 $ DBHOST='aurora-ss-v2.cluster-xxxxxxx.ap-northeast-1.rds.amazonaws.com' $ echo 'SELECT @@GLOBAL.INNODB_BUFFER_POOL_SIZE/1024/1024' | mysql -h ${DBHOST} -P 3306 -u admin -p @

                                                                                一般公開された Amazon Aurora Serverless v2 を東京リージョンで試してみた | DevelopersIO
                                                                              • なぜ「共有データの整合性」が重要なのか? ゲームにおけるサーバーサイド設計のいろは

                                                                                2019年5月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第20回となる今回のテーマは「正しいゲーミング Web サーバーの作り方」。株式会社gumi、CTOの幾田雅仁氏が、自身の経験をもとにさまざまな事例について解説します。後半パートとなる今回は、ゲーム本体のデータストア設計のコツや、言語・サービスなどの技術選定における考え方について語りました。講演資料はこちら ゲーム本体のデータストア設計のコツ 幾田雅仁氏(以下、幾田):続いて「RDBMS+NoSQL」です。 先ほどと同じ流れですが、ゲーム本体のデータストアの設計のコツを1つ挙げると「共有データの整合性を担保する」ことです。 ゲームの本体以外のマイクロサービスって、裏側はNoSQLがメインデータでぜんぜんOKなんで

                                                                                  なぜ「共有データの整合性」が重要なのか? ゲームにおけるサーバーサイド設計のいろは
                                                                                • MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開[PR]

                                                                                  MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開[PR] Kubernetesのようなコンテナ環境では、MySQLデータベースのようなステートフルで高い安定性が求められるソフトウェアを運用することは難しいと、以前は考えられていました。 しかし現在ではステートフルセットのような機能もKubernetesは搭載し、実装も安定してきていることから、ステートフルなアプリケーションをKubernetesで実行できる状況が十分に揃ってきました。 それだけではありません。Kubernetesには運用自動化を支える「Operator」と呼ばれる拡張機能が登場しました。これを用いると、Kubernetes上でさまざまなアプリケーションでの運用作業の多くが人手を介することなく自動的に行えるようになります。 そしてこのOpera

                                                                                    MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開[PR]