タグ

katsushのブックマーク (533)

  • MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]

    株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

    MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
  • https://d1.awsstatic.com/webinars/jp/pdf/services/20200929_BlackBelt_HowToScale_Aurora_MySQL_pub.pdf

  • 第66回 MySQL準同期レプリケーションについて | gihyo.jp

    MySQLのレプリケーションはデフォルトでは非同期で行われます。そのため、マスターの更新が必ずスレーブへ転送されたか保証はしません。 これを実現するしくみとして、MySQL5.5とそれ以降からは準同期レプリケーション機能を使用できます。今回は準同期レプリケーションについて紹介します。MySQLのバージョンは最新の5.7.21を使用しています。 準同期レプリケーションとは 準同期レプリケーションは、マスターの更新がスレーブに適用ではなく、伝搬されたことを保証する仕組みです。 コミットしたトランザクションはマスターから1台以上(オプションで変更可能)のスレーブに伝搬し、受け取ったスレーブ(I/Oスレッド)が通知をマスターに返したところでコミットが完了となる仕組みです。よって、スレーブ側で適用されたことまでは保証されないので、完全同期ではなく準同期と呼ばれます。 更新データの伝搬後にSQLスレッ

    第66回 MySQL準同期レプリケーションについて | gihyo.jp
    katsush
    katsush 2021/08/09
    Loss-Less Semi-Synchronous Replication
  • VOICEVOX | 無料のテキスト読み上げ・歌声合成ソフトウェア

    オープンソースVOICEVOX は OSS(オープンソース・ソフトウェア)版 VOICEVOX をもとに構築されています。 製品版と OSS 版の違いやモジュール構成は VOICEVOX の全体構成 をご参照ください。 ソフトウェア部分は Electron + Vue音声合成エンジン部分は Python + FastAPI です。 追加したい・改善したい機能があれば、ぜひ開発にご参加ください。

    katsush
    katsush 2021/08/01
  • RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々

    RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

    RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
  • WHERE id=? AND owner_id=? に天罰を - Qiita

    $item = $query->fetch(); if (!$item) { throw new NotFoundException(); } owner_id と一致しない者がアクセスしたときは 403 Forbidden にして欲しいと顧客が求める可能性はないのか。拡張に対してオープンであろうとする配慮をなぜできないのか。 そもそも、プライマリキーで十分高速にレコードを特定できている時点で、データベースの責務は終わっているのだ。なぜ貴様らは SQL などというモデリング言語外の文字列 にユースケースを実装するのか。 正しいコードを示そう。

    WHERE id=? AND owner_id=? に天罰を - Qiita
    katsush
    katsush 2021/07/30
    ネタと言いつつ、コメントも含めちゃんと考えた方がいいことに言及してる記事。是非は置いておいて、プロダクト内でどうするか(SQLにどこまで業務ロジックを持たせるか)は決めた方がいい
  • 外部キー制約に伴うロックの小話

    PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)

    外部キー制約に伴うロックの小話
  • 【MySQL】外部キー制約とロックとデッドロックについて - とりあえずphpとか

    はじめに MySQLはよく使っているのですが外部キー制約はほとんど使った事ありませんでした。 使うデメリットとしてはデータの登録作業が面倒だから・・・程度で考えていました が、今回は既に外部キーを採用しているシステムでの作業でしたがほとんど経験なかったので少し苦労しました 発生した現象としては原因不明のデッドロックエラーでこのようなエラーでした Deadlock found when trying to get lock; try restarting transactionなぜ意味不明かと思ったかと言うと以下からそう思っていました ・対象のテーブルを使用している箇所が1箇所だけ ・必ず一意となるデータをINSERTするだけ 概要 会員テーブル(user) 会員ID(id) 会員名(name) カウント(count) 1 太郎 0 2 花子 0 商品テーブル(item) 商品ID(id)

    【MySQL】外部キー制約とロックとデッドロックについて - とりあえずphpとか
  • 100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋

    要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事Java + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

    100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
  • MySQLで3億レコード物理削除した話 - Qiita

    はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse

    MySQLで3億レコード物理削除した話 - Qiita
  • N+1問題におけるORMの重たさについて - Atsuo Ishimoto's blog

    tl;dr¶ボトルネックはちゃんと測定して把握しないとダメだよ。 N+1問題¶DjangoRailsなど、ORMを利用するWebフレームワークなどの開発では、よく 「N+1問題」 というのが話題になります。ORMでは、あるモデルが参照している別のモデルを参照するとその時点でSQLが発行されてしまうため、気が付かないうちにパフォーマンスが低下する場合がある、というやつですね。 Django¶例えば、Djangoで次のようなモデルがあったとき、 class Table1(models.Model): text = models

    N+1問題におけるORMの重たさについて - Atsuo Ishimoto's blog
    katsush
    katsush 2021/07/25
    意外だったし計測の重要性は同意するけど、高負荷環境で問題になるのは簡単に増やせるAPサーバじゃなくてDBなのでDBのCPU使用率やqpsを計測しないと
  • InnoDBのMVCCのガベージコレクションについて - shallowな暮らし

    こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな

    InnoDBのMVCCのガベージコレクションについて - shallowな暮らし
  • MVCCとInnoDBでの実装について - shallowな暮らし

    こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ

    MVCCとInnoDBでの実装について - shallowな暮らし
  • 第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp

    MySQLでは、オプティマイザーヒントを使用してオプティマイザーを制御することで、実行計画を変更することができます。このオプティマイザーヒントはステートメントに適用できるため、ステートメント単位で最適化が可能になります。MySQL 5.7とそれ以降から使用可能です。 今回は、MySQL 8.0から追加されたオプティマイザーのヒントを主に紹介したいと思います。 オプティマイザーヒント構文 オプティマイザーのヒントは/*+ ... */をステートメント内に記述します。SELECT、UPDATEやDELETEなどのDMLのキーワードの後にヒントを記述します。ヒントの内容をパーサーが認識して処理します。以下のように記載します。 mysql> SELECT /*+ hint */ ... mysql> UPDATE /*+ hint */ ... 指定したヒントが有効か確認するには、EXPLAIN後

    第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp
  • 第138回 オンラインスキーママイグレーションツール gh-ostを使ってみよう[その1] | gihyo.jp

    今回から3回に渡って、GitHub社がOSSとして公開しているオンラインスキーママイグレーションツール gh-ostについて紹介したいと思います。 はじめに、MySQLのオンラインスキーママイグレーションというとMySQL 5.6からオンラインDDLがあります。これにより、並列でDMLが実行されてもロックすることなくスキーマ変更が可能です。特に、MySQL 8.0からのInstance Add Columnは、テーブルをリビルドすることなく即時でカラム追加が完了するといううれしい機能です。 しかし、int型からbigint型へなどの型変更を伴うALTERステートメントなど、いくつかの操作は並列のDMLが許可されない、つまりそのテーブルが全体ロックされるような動作になります。加えて、レプリケーションの遅延が発生する可能性もあります。このように、操作の種類によってAlter中にできる動作が異な

    第138回 オンラインスキーママイグレーションツール gh-ostを使ってみよう[その1] | gihyo.jp
  • 第144回 MySQLの<=>演算子を使ってみる | gihyo.jp

    皆さんはカラムにNULLが入らないようにするNOT NULL制約を積極的に使っていますか? もし使うにしても、どうしてもカラムにNULLを入れる必要があったり、過去からのしがらみなどから、どうしても付けられていないという場合もあると思います。そんな時に、厄介に感じるのはNULL値の値です。NULL値の比較に通常の=による比較演算子を使用すると、想定した結果が得られないためバグにつながる可能性もあります。 今回は、NULL値が入る可能性がある場合に便利な<=>演算子について紹介していきます。 検証環境 今回は第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、GitHubのわたしのレポジトリにサンプルコードとして置いてあるので、気軽に試したい方はgit cloneして試してみてくだ

    第144回 MySQLの&lt;=&gt;演算子を使ってみる | gihyo.jp
    katsush
    katsush 2021/07/24
    NULLでも使えるMySQLの演算子 “MySQLの公式のドキュメントでは「NULL-safe equal」や「NULL安全等価演算子」と呼ばれます。”
  • 機械学習業界で働き始めて3年目の初心者への(技術的)アドバイス | AI専門ニュースメディア AINOW

    著者のChris氏はデータサイエンティストで、AINOW翻訳記事『機械学習エンジニアが職を失いつつある。しかし、とにかく機械学習を学ぼう』の著者でもあります。同氏が最近Mediumに投稿した記事『機械学習業界で働き始めて3年目の初心者への(技術的)アドバイス』では、自身の実務経験にもとづいた新米機械学習エンジニアに対する技術的アドバイスが解説されています。 Chris氏の機械学習アプリ開発における数々の成功と失敗から導き出された教訓は、以下のような6項目に集約されます。 データの特徴を抽出する教師なし学習に安易に手を出さない。多くの場合、人間の直観に劣る。 ニューラルネットワークにも安易に手を出さない。初心者には難易度の高い技法である。 問題を二値分類としてとらえる。3値以上に分類するマルチクラス分類より良いパフォーマンスを発揮することが多い。 ハイパーパラメータを調整する。デフォルトのそ

    機械学習業界で働き始めて3年目の初心者への(技術的)アドバイス | AI専門ニュースメディア AINOW
    katsush
    katsush 2021/07/24
  • ソーシャルゲーム開発経験から学んだゲームにRedisを使う際のTips

    稿は「ソシャゲ開発経験から学んだゲームに Redis を使う際の Tips」をもとに加筆・補正し、文章を整えました。 近年のKVSでは割とRedisが覇権を取っていることもあり(当社比)、社内の多くのプロジェクトでRedisを使用するようになりました。ということでノウハウ的なのも溜まってきたのでまとめてみます(大量のユーザーデータを扱うソーシャルゲームにしか当てはまらない部分もあるかと思います)。 単純にパフォーマンスをRDB < Redisと思い込んでとりあえずでキャッシュしない 「Redisは速い」と言われますが、インデックスをきちんと貼ったRDBのクエリもそこまで遅いわけではありません。結局通信コストの方が遥かに大きいので、内部の取得時間差はトータルで考えると多くの場合誤差です。特にRDBの主キーのみで取得できるようなデータを、Redisにキャッシュすることにメリットはありません。

    ソーシャルゲーム開発経験から学んだゲームにRedisを使う際のTips
  • SQLアンチパターン:ENUMは使わない方がいいよ | Shiro's secret base

    どうも、シローです。 今回は、特定の文字列に限定した列を定義する方法について、アンチパターン「サーティワンフレーバー」も一緒に紹介します。 特定の値を持ちうる列とは 例えばユーザ(Users)の権限(管理者かメンバーか)を表したい場合、Usersテーブルにメンバーの権限を表すuser_roleという列を定義するとします。 このuser_roleには管理者の場合はadmin、メンバーの場合はmemberという値を持ちそれ以外の値は格納しない(できない)ようにするにはどうすれば良いのか アンチパターン「サーティワンフレーバー」について 先にアンチパターンについて紹介します。 サーティワンフレーバーと呼ばれる設計方法では特定の値を入れるために 列にCHECK制約を入れる(MySQL8.0以降) 列をENUM型にする という手法を取りうることです。 僕の環境はMySQL5.7なのでENUM型のカラ

    SQLアンチパターン:ENUMは使わない方がいいよ | Shiro's secret base
  • 設計を学びたいときに読みたい本一覧 - Qiita

    これは何 の参加記事です。 エンジニアとして開発をしていく以上、設計についての知識を身につけていくことはとても重要です。 とはいえ設計という言葉からは何を勉強するべきかがいまいちピンときません。 この記事では、僕が読んできた設計に関するおすすめのを網羅的に紹介しています。 これから設計を勉強する方の役に立てれば幸いです。 おすすめの一覧 おすすめのを紹介していきます。 他にもおすすめがあればぜひ編集リクエストをください! オブジェクト指向設計実践ガイド 設計を始めに学ぶならこれ、という一冊です。 エンジニアとして開発を行なっている中で、オブジェクト指向設計は一番汎用的に使う設計知識なのではないでしょうか? オブジェクト指向設計を学ぶことで、いわゆる「におう実装」と「良い実装」を見極めることができるようになると思います。 知らなかったら読んだほうが良いキーワード SOLID原則 Cle

    設計を学びたいときに読みたい本一覧 - Qiita
    katsush
    katsush 2021/07/14