並び順

ブックマーク数

期間指定

  • から
  • まで

161 - 200 件 / 1654件

新着順 人気順

postgresの検索結果161 - 200 件 / 1654件

  • はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog

    この記事は、はてなエンジニア Advent Calendar 2023の2024年1月17日の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog id:hagihala です。先日、はてなブログの DB を RDS for MySQL 5.7 から 8.0 へアップグレードしたので、工夫した点などを共有します。 Aurora MySQL 3.x にしなかった理由 MySQL 5.7 -> 8.0 で対応した変更点 character set や collation のデフォルトが変更される explicit_defaults_for_timestamp がデフォルトで有効になる SQL mode の変更 デフォルトの認証プラグインが caching_sha2_password になり、 mysql_native_passw

      はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog
    • MySQL (InnoDB) のロック範囲に気をつけよう

      こんにちは otsubo です。MySQL (InnoDB) のロックについて整理する機会があったので記事にします。 はじめに 全ての ロックタイプ を網羅するのは大変なため、 レコードロック ギャップロック ネクストキーロック を中心にまとめます。この3つはトランザクション内で UPDATE、DELETE、 SELECT ... FOR UPDATE / SHARE するときに獲得されるロックです。INSERT 時のインサートインテンションロックもちょっとだけ扱います。テーブルロックやメタデータロックは扱いません。 InnoDB ではクエリによって特定の「範囲」がロックされることがあります。これを知らないと思わぬ不具合に繋がります。 範囲をロックして InnoDB は何を実現したいのか、どのような仕組みでロックするのかを知っておくと開発に役立ちます。 記事を通して下記を前提とします。 M

        MySQL (InnoDB) のロック範囲に気をつけよう
      • Herokuから ECSに 移行した - pixiv inside

        こんにちは、インフラ部の id:sue445 です。私事ですが先日GCPの Professional Cloud Architect を取得しました。 そういうわけで今日はGCPではなくAWSの話をします。 tl;dr; 劇的ビフォーアフター 構成 移行のモチベーション パフォーマンス向上 コスト圧縮 アーキテクチャの採択理由 やったこと 1. DB作成 2. MySQL 5.7 -> 8.0 MySQL 8.0でハマったこと MySQL 8.0からデフォルトの認証がcaching_sha2_passwordになった RDSのMySQL 8.0からMariaDB 監査プラグインがなくなった 3. 本番用のDockerイメージを作成 困ったこと:CodeIgniterがログの標準出力に対応していなかった 4. ECS + Fargate + CodePipeline構築 5. CDN作成 6

          Herokuから ECSに 移行した - pixiv inside
        • 今日から『自由』にMySQLの性能改善始めます。(MySQL開発チームを退職しました)

          前回の在籍も含めると、累計9年半、本家MySQLチームでInnoDBの性能改善をターゲットに開発の仕事してきました。5.7でのb-tree index scaleや、8.0の初期の新機能で入ってしまった性能問題の修正など貢献できましたが、ここ数年は開発が進む度に導入される性能劣化に追いつけなくなってしまいました。悪いコードを見つけて直そうとしても抵抗が大きいのも大きな要因です。(遅くしたいのでしょうか?遅いことが認識できないのでしょうか?) この度、体制変更で退職を勧められたのを機に、別の営みでMySQL/InnoDBの性能を改善していくことにしました。どうせ、性能劣化に(私よりも)無頓着な現体制では私が性能を改善することは困難なので、成果は出ないでしょう。(直しても、同時に導入される新機能・修正による劣化に改善分を喰いつぶされることもしばしばあった、と考えています。キリがありません。そも

          • Zennの検索スピードを5倍に高速化した話

            @dyoshikawaです。 先日、以下のリリースでZennのサイト内検索の高速化を行いました。 結論を先に述べるとCDNキャッシュやPostgreSQLの全文検索インデックスを活用して対応しました。この記事では本パフォーマンス改善の取り組みについて紹介します。 Zennの構成 ZennはGoogle Cloud上に構築されており、フロントエンドNext.jsとバックエンドRailsをそれぞれCloud Run上にホスティングしています。上の図では省かれていますが、CDNにはCloudflareを利用しています。 データベースはCloud SQL for PostgreSQLを利用しています。 検索速度とDB負荷に課題 2025年2月頃、某AIクローラーによる検索ページへの集中アクセスによりDBインスタンスのCPU使用率が100%近くに張り付いてしまうという事象が発生しました。 生成AIサ

              Zennの検索スピードを5倍に高速化した話
            • データベースエンジニアの仕事を楽にする。PgAssistantの紹介

              この資料は2026年3月27日に開催された「第52回 PostgreSQLアンカンファレンス@オンラインの登壇資料」です。 PostgreSQLをAIの力を借りて改善する、PgAssistantの紹介をします。

                データベースエンジニアの仕事を楽にする。PgAssistantの紹介
              • 育児支援ダッシュボードを支える技術 - 人間だったら考えて

                この記事はなに? 構成・実装 育児記録 室内の温湿度 現在の天気 ダッシュボード 取得情報のデータベースへの格納 ダッシュボードに何を掲出すべきか? まとめ 参考 この記事はなに? 以下の育児支援ダッシュボードの構築ポストに触発され、自分もダッシュボートを作ってみました。 我が家の最終形態こんな 日中妻が試す→不満・希望を夕方俺に伝達→夜俺が治すみたいなサイクルを2週間回した後の図 pic.twitter.com/PHYRx7m1MS— Dr.10(どく・とぉと読んでください) (@Dr10_TakeHiro) 2023年10月2日 現時点で、自分が作ったダッシュボードは以下のようになっています。 育児支援ダッシュボード この記事では、上記の育児支援ダッシュボードを支える技術について解説します。 構成・実装 ダッシュボードには大きく分けて以下の3つの項目を載せています。 育児記録:「ぴよロ

                  育児支援ダッシュボードを支える技術 - 人間だったら考えて
                • Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話

                  Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話 こんにちは。 KINTO テクノロジーズの DBRE チーム所属の@p2skです。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち(@_awache)による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を

                  • explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ

                    はじめに こんにちは、バックエンドエンジニアのSakiです!バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL(InnoDB)についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや

                      explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ
                    • オレ的EXPLAIN技を語っちゃうゾ - Qiita

                      最下行(内部表)のLoopsは上の塊(駆動表)で得られた結果の行数分発生していて、Loop回数×所要時間が膨大になってしまった。**B社は仕事を受けた時点ではこんなにLoopするとは思ってなかったのでしょう。**これ、行数の見積が正確なら最初からLoop回数の予測が立って、最初からHash Joinしてるでしょ。プランナ仕事しろ案件です。 階層が深いところから読む説に対して 問題であった「B社がIndexScan」してるところは実行計画の階層(インデント)としてはかなり浅いところに出てきてますよね。「階層が深いところ」から見ていく方式だと、全体としては概ね問題ない「A社内の一部の仕事(3次請け、4次請けの仕事)」を掘っているだけで、このタイプの問題にはなかなかたどり着けないんですよね。 「今まで深いところから見てたわ~」という方へ。アナタもワタシも雰囲気チューニングの同志ってことです🥰

                        オレ的EXPLAIN技を語っちゃうゾ - Qiita
                      • マルチテナントSaaSのテナント分離をRow-Level Securityに移行した - Sansan Tech Blog

                        こんにちは、クラウド請求書受領サービス「Bill One」の開発に携わっているソフトウェアエンジニアの加藤です。Bill OneはB2BのマルチテナントSaaSであり、データベースとして Cloud SQL 上のPostgreSQLを利用しています。従来はマルチテナントのデータを分離するために、テナントごとにPostgreSQLのスキーマを分けていましたが、2020年12月にRow-Level Securty(行レベルセキュリティ。以降RLSと表記)による分離に移行しました。 本稿では、移行の背景とRLS組み込みにあたって考慮したポイントをご紹介します。 マルチテナントSaaSのテナント分離 マルチテナントSaaSにおけるテナント分離方法はいくつか知られており、大きく次の3つに分けられます。 アプリケーションの実行環境ごと完全に分離する データベースのみをインスタンスやスキーマで分離する

                          マルチテナントSaaSのテナント分離をRow-Level Securityに移行した - Sansan Tech Blog
                        • BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場

                          BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場 Google Cloudは、BigQueryに対してMySQLやPostgreSQL、Oracle Databaseからニアリアルタイムで直接データのレプリケーションを可能にする新サービス「Datastream for BigQuery」をプレビューリリースしました。 オンプレミスやクラウドで稼働するMySQLやPostgreSQL、Oracle DatabaseでのOLTPによるデータ操作が、ETLツールなどを挟むことなくほぼリアルタイムでBigQueryに反映されるため、プライマリとなるデータベースのOLTP処理に負荷をかけることなく並行してBigQueryによる大規模データの分析処理が容易になります。 To stay compet

                            BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場
                          • MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス

                            はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

                              MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
                            • AWS、事実上無制限にスケールするPostgreSQL互換の大規模分散DB「Amazon Aurora DSQL」正式版を提供開始

                              Amazon Web Services(AWS)は、事実上無制限にスケールするPostgreSQL互換の大規模分散データベース「Amazon Aurora DSQL」の正式版を提供開始したと発表しました。 Amazon Aurora DSQLは昨年(2024年)12月のイベント「AWS re:Invent 2024」で発表された、サーバレスな大規模分散データベースです。 1つのリージョン内で3つのアベイラビリティゾーンにまたがる構成、もしくは複数のリージョンにまたがる構成において、自動スケーリングと自動障害復旧機能を備えたActive-Activeなクラスタを実現できます。 分散処理による高いスケーラビリティおよび複数のアベイラビリティゾーンやリージョンによる冗長構成による高可用性の両方を実現するだけでなく、複数リージョンのような広域での分散データベースにおいてトランザクション処理による強

                                AWS、事実上無制限にスケールするPostgreSQL互換の大規模分散DB「Amazon Aurora DSQL」正式版を提供開始
                              • [速報]「Amazon Aurora DSQL」プレビュー公開、事実上無限にスケールする高性能なPostgreSQL互換の大規模分散データベース

                                Amazon Web Services(AWS)は、米ラスベガスで開催中のイベント「AWS re:Invent 2024」で、PostgreSQL互換の分散データベース「Amazon Aurora DSQL」のプレビュー公開を発表しました。 Amazon Aurora DSQLは、地理的に離れた複数のリージョンでデータベースが稼働する大規模分散データベースです。 分散処理による高いスケーラビリティ、複数のリージョンによる冗長構成による高可用性の両方を実現するだけでなく、分散データベースにおいてトランザクション処理による強い一貫性を実現する際の弱点とされていたレイテンシの大きさを克服し、小さなレイテンシによる高速性も兼ね備えたPostgreSQL互換のデータベースだと説明されています。 分散データベースの弱点はレイテンシの増大 一般に分散データベースは、複数のデータベースのノードが分散してリ

                                  [速報]「Amazon Aurora DSQL」プレビュー公開、事実上無限にスケールする高性能なPostgreSQL互換の大規模分散データベース
                                • MySQLでIn句に大量の要素を渡すとまずい理由

                                  概要 MySQLでIN句を使用する時はIN句に渡す要素数に注意する必要があるとよく先輩エンジニアの方から聞いていたのですが、実際に大量の要素を渡すと何がまずいのかはっきり分かっていなかったので調べてみました。 この記事で伝えたいこと MySQLでIn句に大量の要素を渡すとまずい理由 まずい状況を回避するために気をつけるべきポイント 先に結論 MySQLでIN句に大量の要素を渡すとインデックスを貼っていたカラムだとしてもフルスキャンが発生しスロークエリになる可能性があります。 フルスキャンが発生してしまう条件はテーブルに設定してあるインデックスの内容とrange_optimizer_max_mem_size の設定値に依存しており、MySQL8でデフォルトの設定値 & シンプルなテーブルであってもおおよそ数万件の要素数をIN句に渡すとフルスキャンが発生する可能性があると考えられます。 検証環

                                    MySQLでIn句に大量の要素を渡すとまずい理由
                                  • WebAssemblyとしてPostgreSQLをビルドした「PGlite」公開。Node.jsやブラウザ上でPostgreSQLを実行、DBの永続化も可能

                                    PostgreSQLのソースコードをWebAssemblyバイナリとしてビルドしたことで、Node.jsなどのJavaScriptランタイムやWebブラウザ上で(ほぼ)フル機能のPostgreSQLを実行可能にした「PGlite」が公開されました。 PGliteはPostgreSQLのCのソースをEmscriptenでコンパイル PostgreSQLはオープンソースの代表的なリレーショナルデータベースであり、C言語で開発されています。 PGliteはこのPostgreSQLのCのソースコードのビルドにEmscriptenコンパイラを使用してWebAssemblyバイナリとして出力、JavaScript/TypeScriptからライブラリとして呼び出せるようにしたものです。 ただしEmscriptenでコンパイルされたプログラムは新しいプロセスをフォークできないため、PGliteはPostg

                                      WebAssemblyとしてPostgreSQLをビルドした「PGlite」公開。Node.jsやブラウザ上でPostgreSQLを実行、DBの永続化も可能
                                    • Aurora MySQL のバックアップは本当にそれでいいのだろうか? | CyberAgent Developers Blog

                                      技術本部 サービスリライアビリティグループ(SRG)の長谷川 @rarirureluis です。 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL(以下:Aurora MySQL)の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに

                                        Aurora MySQL のバックアップは本当にそれでいいのだろうか? | CyberAgent Developers Blog
                                      • Next.js + Vercel + Supabase を用いた高速アプリ開発 - RAKUS Developers Blog | ラクス エンジニアブログ

                                        こんにちは!ラクス入社1年目のkoki_matsuraです。 本日は、Next.jsとVercel、Supabaseを用いて簡単なアプリを高速で開発する手順についてお話しできればと思います。 アジェンダは以下の通りです。 Next.jsとは ReactとNext.jsの違い Next.jsの特徴 Vercelとは Supabaseとは ToDoアプリ作成 Supabaseにデータベースを用意 VercelでNext.jsプロジェクトを作成・デプロイ・GitHub連携 VercelとSupabaseの連携 GitHubからクローン Vercelから環境変数を取得 Supabaseのデータベースに接続 コード編集 終わりに 参考文献 Next.jsとは Next.jsはReactベースのアプリケーションフレームワークです。 公式サイトではNext.jsとはReactを用いたWebアプリ開発で生

                                          Next.js + Vercel + Supabase を用いた高速アプリ開発 - RAKUS Developers Blog | ラクス エンジニアブログ
                                        • Git for Data「Dolt」というDBの話

                                          ここ最近、何やらデータベースの相談をされることが何やら多くなってきたmasamikiです。 今、とあるプロダクトの開発をしようと、要件まとめたり設計したりたりしてるのですが、この仕組みをやるためには…version管理いるなぁ…gitが欲しいなぁ……となってます。 そして、調べてみたところ、2年も前のものですがこんな記事を見つけました。 「DoltとDoltHubが我々の結論だ」とおっしゃってます。 Doltとは Doltは、Gitリポジトリと同じように、フォーク、クローン作成、ブランチ、マージ、プッシュ、プルできる最初で唯一のSQLデータベースです。(← by Google翻訳) おぉ、まさしく、そのままんま、これだ。 他にも、GitRows とかも使えそうかな…と思ってみていたものの、どうやら今の要件にあうのあはDoltっぽそう。 上記事だと、他にもdata.world(Microso

                                            Git for Data「Dolt」というDBの話
                                          • まだ PostgreSQL の開発で疲弊してるの? - Qiita

                                            { "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // ( SQLite など他の RDS と競合させないためです。) // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq

                                              まだ PostgreSQL の開発で疲弊してるの? - Qiita
                                            • 競走馬の血統をSQLで再現できる! 再帰クエリ徹底活用してみた - asoview! Tech Blog

                                              アソビュー! Advent Calendar 2022の10日目です。 8月に入社しアソビューでバックエンドエンジニアをしている長友です。 みなさま再帰クエリ使っていらっしゃるでしょうか! 最近アソビューではmysqlの8系へのバージョンアップを行った為、再帰クエリの利用が可能となりました。 そこで本日は、アソビュー競馬部にも所属しておりサラブレッドの血統好きな私が再帰クエリを使ってツリー構造の血統表を作成してみるというお話です。 血統表とは ~ 本稿の目的 再帰クエリについて mysqlにおける再帰クエリの構文 再帰クエリとナイーブツリー構造 血統表作成における再帰クエリ 血統表のデータ構造 血統表を作成するクエリ ポイント1. 世代を表すgenerationを0で初期化し、各再帰の中でインクリメントする ポイント2. 世代内での配置を表すpositionを初期値1で定義し、再帰で取得す

                                                競走馬の血統をSQLで再現できる! 再帰クエリ徹底活用してみた - asoview! Tech Blog
                                              • MVCCとInnoDBでの実装について - shallowな暮らし

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

                                                  MVCCとInnoDBでの実装について - shallowな暮らし
                                                • Ultimate Guide to Improving MySQL Query Performance

                                                  Have you ever waited far too long for a MySQL query to finish and wondered if there’s a better way? If you manage a MySQL database or build apps that depend on one, you know how slow queries can grind everything to a halt. Users get frustrated, response times creep up, and suddenly you’re dealing with support tickets instead of focusing on new features. Maybe you’re seeing queries that used to fly

                                                    Ultimate Guide to Improving MySQL Query Performance
                                                  • MySQL8.0のバックアップはどれがいいのか - CyberAgent SRG #ca_srg

                                                    #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

                                                      MySQL8.0のバックアップはどれがいいのか - CyberAgent SRG #ca_srg
                                                    • マイグレーションしないRDBMS

                                                      README.md マイグレーションしないRDBMSが欲しい! 課題 PostgreSQLなどの既存のRDBMSはスキーマを持つ。スキーマがあることは良いことだが、このスキーマのライフサイクルはアプリケーションコードのライフサイクルと乖離しがちで、結果として以下のような問題が発生する。 特に自動化をしない場合はマイグレーションをデプロイとは別に行う必要が発生する。これにより、 シンプルに作業が面倒。 承認フローが追加で必要になる。または、デプロイはレビューの管理下に置かれているのにマイグレーション側が適切に管理されないなどのミスマッチが起きる。 マイグレーション忘れ、マイグレーションのリバート忘れのリスクがある。 異なるバージョンのアプリケーションは同時に存在できるがスキーマは同時に存在できない。これにより、 ある種のスキーマ変更はローリングデプロイ環境下では実質的に実行できない。 (テー

                                                        マイグレーションしないRDBMS
                                                      • MySQLのutf8mb4と戦った話 - Uzabase for Engineers

                                                        皆様こんにちは、NewsPicksエンジニアの米澤です。 先日 2023/03/30は、こちらでアナウンスしていた通り、サービスの停止を伴うシステムメンテナンスを実施させて頂きました。 NewsPicksをご利用頂いている皆様には、ご迷惑おかけいたしました。 今回はこのメンテナンスの中で行われたDBテーブルのmigrationについてお話ししたいと思います。 ことの始まり やったこと 方針決め utf8mb4に対応していないテーブルを調べる migrationを作成する 影響範囲を調べる 開発環境でリハーサルを行う メンテナンスの日 最後に ことの始まり NewsPicksではバグの検知にBugSnagを利用しています。 ある時、BugSnagにこんなエラーが通知されてきました。 org.springframework.orm.hibernate4.HibernateJdbcExcepti

                                                          MySQLのutf8mb4と戦った話 - Uzabase for Engineers
                                                        • Laravelへの異常な愛情 または私は如何にして心配するのを止めてEloquentを愛するようになったか

                                                          動画: https://youtu.be/QHjRGPw34EI?si=MWb-1v1i1S5MG0eE プロポーザル: https://fortee.jp/phperkaigi-2023/proposal/6211083d-fc51-49a3-8b27-485d8e231b1f

                                                            Laravelへの異常な愛情 または私は如何にして心配するのを止めてEloquentを愛するようになったか
                                                          • TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話

                                                            こんにちは。DevOps芸人と化して久しいAndyです。 2020年の秋にTypeScript 4.1へTemplate Literal Typesが導入され、そのインパクトに俄かに一部の界隈がザワついたのは記憶に新しいかと思います。 今回は型プログラミングの可能性を大いに押し広げたTemplate Literal Typesを用いてSQL文を型レベルで解析し、その実行結果を型情報として導出するためのsqlptureというライブラリを作ったので紹介します。 Embedded content: https://github.com/andoshin11/sqlpture SQLの実行/検証対象はPostgreSQL v13です。 tl;dr SQL文を型レベルで解析・評価して返り値型を取得できるmini interpreterを作ったよ 型レベルのSQL validatorも作ってるよ 実際

                                                              TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話
                                                            • パフォーマンスチューニング9つの技 ~「書き」について~|PostgreSQLインサイド

                                                              今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ~はじめに~ パフォーマンスチューニング9つの技 ~「書き」について~(本記事) パフォーマンスチューニング9つの技 ~「探し」について~ パフォーマンスチューニング9つの技 ~「基盤」について~ 1. パフォーマンスチューニングの「書き」とは 一般的にデータベースは、大量データを扱い、大量の問い合わせや更新を高速に処理し、さらに障害発生

                                                                パフォーマンスチューニング9つの技 ~「書き」について~|PostgreSQLインサイド
                                                              • 医薬品検索にベクトル検索を導入したら、デフォで検索ニーズをほぼ満たせそうだった話

                                                                どんな人向けの記事? 医薬品のような難しい検索ニーズにこたえるためにベクトル検索を利用する知見を見てみたい MySQLの全文検索と、ベクトル検索の精度や速度を比較してみたい ベクトルDBとEmbeddingモデルを利用した簡単なベクトル検索の実装方法を知りたい 医薬品の検索ニーズは多様なので、ベクトル検索で解決できるか試したい 1つの医薬品を指す名称は、複数存在するため医薬品検索は意外と面倒な問題です。 例えば、日本人なら頭痛や生理痛、発熱したときに「ロキソニン」を飲んだことがあるかもしれません。この名称は商品の名称ですが、成分の名称は「ロキソプロフェンナトリウム水和物」です。 さらに、ロキソプロフェンには錠剤以外にもテープやパップといった剤形の違いがあります。 そして最後に、ロキソプロフェンを作っている会社は複数あるので、末尾に「トーワ」や「ファイザー」などの組み合わせが存在します。ロキ

                                                                  医薬品検索にベクトル検索を導入したら、デフォで検索ニーズをほぼ満たせそうだった話
                                                                • 結合テストを書くときはコードベースを分離している

                                                                  新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと!!!」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker

                                                                    結合テストを書くときはコードベースを分離している
                                                                  • Oracle、「MySQL Shell for VS Code」をプレビュー公開/「MySQL」の開発・管理シェル「MySQL Shell」を「Visual Studio Code」で直接扱える

                                                                      Oracle、「MySQL Shell for VS Code」をプレビュー公開/「MySQL」の開発・管理シェル「MySQL Shell」を「Visual Studio Code」で直接扱える
                                                                    • Goodbye to sequential integers, hello UUIDv7!

                                                                      Scale-Out Delivery Platform→Complexity is inevitable. Tame it and gain your competitive advantage.

                                                                        Goodbye to sequential integers, hello UUIDv7!
                                                                      • docker composeのserviceをグループ化

                                                                        docker composeではserviceごとにprofilesという属性を指定できて、起動時にこれを指定することで関連する一連のserviceだけを起動させられる。 どういうシーンで使えるのか。例えばとあるRailsアプリでは、一部の開発者はMySQLやRedisなどのデータストアだけdocker composeで起動して開発し、他の開発者は加えてRubyもdocker composeで起動して開発している。osxfsが遅すぎて、ファイルへの読み書きが頻発する処理がmacOSのDockerでは使い物にならないからだが、この話は今回どうでもいい。さてこのとき、データストア用のserviceに適当な名前のprofileを割り当てておくことで、個々のserviceの名前を逐一指定しなくても起動でき、将来の変更にも強くなって嬉しい。 # profile導入前 docker compose u

                                                                          docker composeのserviceをグループ化
                                                                        • 12年目を迎えた『ガールフレンド(仮)』におけるデータベースの負債解消への道のり【CAGC2024】

                                                                          本セッションではPC/スマートフォン向けゲーム『ガールフレンド(仮)』のデータベースの負債とその解消の道のりをご紹介します。 当ゲームではデータベースにMySQLを採用しており、長年の運用を続けていく中で下記のような課題が発生してきました。 「突発的なユーザー増加で更新負荷に耐えられない」 「デー…

                                                                            12年目を迎えた『ガールフレンド(仮)』におけるデータベースの負債解消への道のり【CAGC2024】
                                                                          • 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

                                                                              MySQL の UPDATE で IN 句の要素が多すぎてデッドロックした話 #LayerXテックアドカレ - LayerX エンジニアブログ
                                                                            • 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としての未来像
                                                                              • MySQL JOIN Types Poster - Steve Stedman

                                                                                So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S

                                                                                  MySQL JOIN Types Poster - Steve Stedman
                                                                                • MySQLでわざとデッドロック発生させて挙動を確認してみた - Qiita

                                                                                  概要 RDB(リレーショナルデータベース)を運用していると、複数のトランザクションが同じデータに同時アクセスしようとする場合に「デッドロック」が発生することがあります。デッドロックとは、あるトランザクションが必要とするリソースが別のトランザクションによってロックされ、さらにそのトランザクションも他のリソースのロック解除を待っているため、互いに進行できなくなってしまう状態を指します。

                                                                                    MySQLでわざとデッドロック発生させて挙動を確認してみた - Qiita

                                                                                  新着記事