並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 411件

新着順 人気順

RDBの検索結果41 - 80 件 / 411件

  • PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳

    はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻(begin_at)と終了時刻(end_at)を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含:範囲Aが範囲Bを完全に含む 重複:範囲Aと範囲Bに共通点がある 隣接:範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複

      PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
    • インフラからSREへ

      Road to SRE NEXT@会津若松 2025/05/17

        インフラからSREへ
      • 医薬品検索でMySQLの全文検索機能を使った話 - KAKEHASHI Tech Blog

        AI在庫管理の開発チームでバックエンドエンジニアをしている沖です。今回は、AI在庫管理の医薬品検索において、MySQLの全文検索機能を使った話を紹介しようと思います。 この記事は秋の技術特集 2024の 8 記事目です。 今までの医薬品検索では満足できないユーザーがいた なぜMySQLの全文検索機能を採用したのか 全文検索機能を導入する 全文検索インデックスを付与したテーブルを作成する パーサー 照合順序と正規化 全文検索インデックスを使用して検索する データを最適な状態に保つために おわりに 今までの医薬品検索では満足できないユーザーがいた AI在庫管理には、医薬品の在庫一覧画面など、医薬品名で絞り込む画面がたくさんあります。この絞り込み機能を実現するために、これまではSQLのLIKE検索を利用していました。 LIKE検索は、使い慣れたSQLを用いて部分一致検索を実現できる便利な方法です

          医薬品検索でMySQLの全文検索機能を使った話 - KAKEHASHI Tech Blog
        • インデックスとは何?MySQL(InnoDB)とPostgreSQLのインデックスの違いとは?調べてみました

          はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお

            インデックスとは何?MySQL(InnoDB)とPostgreSQLのインデックスの違いとは?調べてみました
          • 「つくる人が、世界を面白くする。」篇30秒

            ドラゴンボールZの“天才発明家”ブルマが世界を動かす「つくる人が、世界を面白くする。」 ▼特設サイト https://findy-code.io/db-lp03?utm_source=youtube&utm_medium=organic&fr=youtube_organic

              「つくる人が、世界を面白くする。」篇30秒
            • SQLiteをRustで書き直した「Limbo」が海外で話題に — 完全な非同期I/Oのサポート、WASM対応、メモリ安全性の確保など、Rustのメリットを全面的に享受

                SQLiteをRustで書き直した「Limbo」が海外で話題に — 完全な非同期I/Oのサポート、WASM対応、メモリ安全性の確保など、Rustのメリットを全面的に享受
              • なぜDBから引くときに1000件ずつchunkingするのか、説明できますか - Lambdaカクテル

                MySQLやPostgreSQLといったRDBMSからデータを引いてくるとき、扱うデータの規模によっては、1000件ずつLIMITをかけて順に引いていくということがある。 以前slow queryが出たらよくやっていたのを思い出して、ふとこのあたりってどういう根拠があってやっているのだっけ、自分が知っている他に効能があったりするのかな、と思ってSlackに書き込んだところ、同僚の id:onk に教えていただいた。その内容に加えて軽く調べた内容をまとめてみる。 Web系の話です。みなさまの知見がありましたら教えてください。 TL;DR 刺さる*1から 刺さったら困るから あたりまえ 詳細 もともとSlackに書いた原文は以下の通り(MySQL前提で書いているけどPostgresといった他のRDBMSにも適用できる話。): DB引くとき、Perl時代(?)によく1000件単位でchunkin

                  なぜDBから引くときに1000件ずつchunkingするのか、説明できますか - Lambdaカクテル
                • 連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️)

                  大いなる流れには逆らえない あるAI研究者が言っていた、私の仕事もいつか AI に奪われるという言葉が非常に印象的だった。 私は一時期自分のキャリアに危機感を覚えAIに関する情報を集めていた。そのとき見つけたYoutube動画でこのようなことが語られていたのである。 ではなぜ彼らは研究を続けるのかと思うかもしれないが、個人や一団体がそれを放棄したところで世の中のイノベーションの流れを止めることは不可能だろう。 平和を望む国々も兵器開発をやめられないのと似たようなものだ。 私がこの記事のタイトルを思いついたとき、つい溜息が出た。あまり楽しくない思い出があるからだ。 ただ、思いついてしまった以上これを世に出さないわけにもいかず、血の涙を流しながらこの記事を書いている。 私というちっぽけな存在では、この大宇宙の大いなる流れには逆らえないのだ。 申し遅れました。私、YadaYadaKonnanYa

                    連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️)
                  • スロークエリログをどう使えばいいのかって疑問、全て解決

                    これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの

                      スロークエリログをどう使えばいいのかって疑問、全て解決
                    • MySQLを使っても会社は潰れない

                      MySQLを使っても会社は潰れない そんな話は聞いたことがない。AWS Lambdaが再帰実行されて潰れた会社の話は実際に聞いたことがあるが。 つい先日、私が書いた記事がとんでもなく大事になってしまい、大変な賛否を巻き起こした。 まさかこんなに読まれると思っていなかったので、大変驚いたのと同時にインターネッツの恐ろしさを体感した。 その中でも特に物議を醸したのが「MySQLを使うと会社が潰れる」というフレーズだった。 「MySQLを使うと会社が潰れる」とはなんだったのか 私がこのフレーズを選んだ理由は、言うまでもなく単に読者の注意を引く表現を使いたかったからである。 このフレーズがセクションの先頭にあったら、「なにをいってるんだこいつ?」と先を読んでみようという気になると思った。 そして続きを読んでいくと「なんだそういうことか」と意図を汲んで、それで同意するかしないかは人それぞれだろうなと

                        MySQLを使っても会社は潰れない
                      • 入門リトライ

                        • 失敗が⼀時的なものであり、リトライによって回復する可能性がある ◦ ネットワークの瞬断 ◦ サーバ側の⼀時的な⾼負荷 ◦ タイムアウトや接続の遅延 ◦ HTTPレスポンスコード ▪ 502 Bad Gateway ▪ 503 Service Unavailable ▪ 504 Gateway Timeout ⼀時的なエラー

                          入門リトライ
                        • 顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed

                          # 失敗から学ぶRDBの正しい歩き方 - https://amzn.to/4e0CqfH

                            顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
                          • S3にあるALBログの調査はAthenaよりDuckDBのほうが簡単 - road288の日記

                            AWSのALB(Application Load Balancer)のログはS3に置かれるが、この中身をサクッと調べたいとき、Athenaを使う方法が標準的で、下記で案内されているようにパーティション射影(Partition Projection)でテーブルを作ってAthenaからクエリする。 パーティション射影を使用して Athena で ALB アクセスログ用テーブルを作成する - Amazon Athena 私も従来はその方法を使っていたが、Athenaはブラウザから使うと動作がもっさりしているし、決まったクエリを1回きり実行して結果を取得したいだけのときならまだしも、探索的にクエリを何発も実行したいときには使い勝手が悪い。 最近他のプロジェクトでDuckDBを使うようになって、使い勝手の良さに感動していたが、DuckDBはALBのログを探索的に調べたいときにもめっちゃ使えると思った

                              S3にあるALBログの調査はAthenaよりDuckDBのほうが簡単 - road288の日記
                            • テストを書く方針と原則の備忘録 - Qiita

                              Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。サーバエンジニアのnsym-mです。普段はGoでバックエンドの開発などをしています。 最近テストに関する書籍や記事などを色々読み漁ったので、現時点での自分のテストについての考え方を備忘録として残しておきます。 今回の話はWebフロントエンドやiOS/Androidなどでも適用できる汎用的な考え方として記載していますが、ベースの文脈はバックエンド開発になりますのでそのつもりで読んでいただけますと幸いです なお、本記事では主にGoogle、『単体テストの考え方/使い方』、@t_wadaさんの発表されている考え方(いわゆる古典学派

                                テストを書く方針と原則の備忘録 - Qiita
                              • 2025年現在のNewSQL (最強DB講義 #36 発表資料)

                                最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi

                                  2025年現在のNewSQL (最強DB講義 #36 発表資料)
                                • Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog

                                  こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります

                                    Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog
                                  • アンチパターンで学ぶDB設計 - Qiita

                                    はじめに データベース(DB)の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て

                                      アンチパターンで学ぶDB設計 - Qiita
                                    • ベクトル検索システムの気持ち

                                      2025.03.25

                                        ベクトル検索システムの気持ち
                                      • 本番DBのマスターデータを全行ぶっとばすやらかしをしたときのお話、その反省

                                        はじめに はじめまして、さかがみ かずと(@_skgm092)です。 今回は自分がお手伝いしているプロジェクトで、本番DBへのアクセス作業中に発生したトラブルについて記録します。 自分の失敗を公開することは恥ずかしいものですが、同じような事故を防ぐための参考になればと思い、共有することにしました。 自分のしかばねを糧にして、皆様は同じ失敗をしないようにしてください。 トラブルの概要 起きてしまったこと 担当プロジェクトはコアタイムがPM10-AM03頃のSNSサービスでした。 サービスの主要機能が完全に機能停止する事態が発生し、コアタイムの大部分を緊急メンテナンスで停止せざるを得ない状況となりました。 どんな作業で発生したか マスタデータを含むテーブルの列を書き換える作業中に発生しました。 具体的には、とあるマスタデータのJSON型の列を全てブランク値で上書きしてしまいました。 何が問題だ

                                          本番DBのマスターデータを全行ぶっとばすやらかしをしたときのお話、その反省
                                        • PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines

                                          本規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに ​本規約はPostgreSQLを使用する開発者向けに、DBのテーブルやカラムの命名・型桁・制約などのスキーマ管理に加え、履歴・排他制御・マルチテナント対応などアプリケーション設計を含む内容についての設計標準を紹介する。 以下の目的・意図で作成するものとする。 DB設計の主な論点/設計項目/設計観点を提供することで、開発者の考慮漏れを防ぐとともに、チームでの設計上の合意形成を手助けするシステム開発における標準ラインとなる設計手法を提供することでナレッジやツールの横展開を容易にする適用範囲 ​作成

                                          • PostgreSQLにあるSQLインジェクションの脆弱性が9年以上発見されずアメリカ財務省への侵入に使用されてしまう

                                            2024年12月30日、「中国政府が支援する高度で持続的な脅威攻撃者」がアメリカ財務省の機密データを管理するシステムを侵害しました。この侵入にはPostgreSQLに9年以上存在していたのに誰も気付いていなかったSQLインジェクションの脆弱(ぜいじゃく)性が使用されたことが判明しており、ソフトウェアエンジニアのニック・アグリアーノ氏が記事にまとめています。 Hidden Messages in Emojis and Hacking the US Treasury https://slamdunksoftware.substack.com/p/hidden-messages-in-emojis-and-hacking SQLインジェクションは多くのセキュリティの教科書の冒頭に載っているような非常に有名な攻撃手法で、SQLインジェクションを通して攻撃者はSQL文を書き換えられるためシステムに重

                                              PostgreSQLにあるSQLインジェクションの脆弱性が9年以上発見されずアメリカ財務省への侵入に使用されてしまう
                                            • Rails vs Node.js

                                              Previous slideNext slideToggle fullscreenOpen presenter view Rails vs Node.js 最終章 「Prisma」 @mizchi Cloudflare Meetup 2024/10/02 今日の Prisma + Cloudflare の様子 About https://x.com/mizchi Node.js とフロントエンドの専門家 100万円*達成率で御社のフロントエンドの高速化をやります 前書き フロントエンド/Node.js 視点のポジショントークです Railsに対するチャレンジャーとして Node.js を使ってきた話 Rubyの開発者やRubyのユーザーを否定する意図はありませんが、好き嫌いは否定しません。型が好きです 「Rails」は 2010年前後に流行っていた任意なWAFに置き換え可能 Symfony

                                              • 都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」 - Kaigi on Rails 2024

                                                https://kaigionrails.org/2024/talks/osyoyu/

                                                  都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」 - Kaigi on Rails 2024
                                                • 小さなテーブルへのALTER TABLE一撃でサービス停止。そこから学んだ惨事を繰り返さないためのルール作り - Qiita

                                                  こちらは NewsPicksアドベントカレンダーの9日目の記事です。 はじめに こんにちは。NewsPicks エンジニアの鶴房です。 フロントエンドの刷新プロジェクトにおいて、主にインフラとバックエンドを担当しています。 今回は私が以前起こしてしまったサービス全停止の障害の原因と、その再発防止策に関して記載します。 尚、弊社ではRDBMSとしてMySQLを利用しているので、この記事はMySQLに関する内容になります。 障害事象 今年の夏頃、約30分の間、NewsPicksのほぼ全てのサービスが停止してしまいました。 ユーザーは、その間、ログインも、記事を読むことも、記事にコメントすることもできない状態でした。 アプリを開くと、エラーメッセージが表示されるだけの状態で、障害の解消までずっとその状態が続いていました。 障害の直接原因 障害の直接の引き金になったのは、タイトルにある通りALTE

                                                  • 生SQLに型を手書きする時代は終わり?Prismaの新機能「TypedSQL」

                                                    生SQLを扱う $queryRaw TypeScript向けのORMライブラリとしてPrismaがあります。Prismaは直感的で型安全なAPIを提供し、TypeScript向けのORMとしては第一に名前が上がることが多いライブラリです。 しかしそんな人気なPrismaでも、裏側では少しクセのあるSQLが発行されていたり、欲しいSQLがPrismaのAPIでは実現できない場合があります。 そういった場合のために $queryRaw というメソッドが用意されており、これを使うことで生SQLを書いてその結果を受け取ることができました。他のORMにもよくある機能です。 例えば以下のように実装することができます。 const users = await prisma.$queryRaw` SELECT id, name FROM "Users" WHERE id = ${userID} `; co

                                                      生SQLに型を手書きする時代は終わり?Prismaの新機能「TypedSQL」
                                                    • Claude Codeの会話ログをDuckDBで分析して自分の仕事スタイルを改善する方法 - yasuhisa's blog

                                                      3行まとめ はじめに Claude Codeのログ保存機能とその特徴 ログ分析の活用例 音声入力の課題と英語プロンプトの活用 DuckDBを用いた分析アプローチ スキーマ情報の重要性とログ分析の活用 ログの長期保存設定 まとめ 3行まとめ Claude Codeの会話ログはJSONL形式で保存されており、DuckDBを使って日次の利用状況や音声入力の課題などを分析できる 英語プロンプトの学習効率化やエラーパターンの特定など、自分の仕事の仕方を改善するための実践的な活用方法がある JSONLファイルのスキーマ情報を整理することで、Claude Codeがクエリを書く際の精度が向上する はじめに Claude Codeは非常に強力なツールで、これ自体は別のブログで書く予定ですが、もはやこれなしでコードを書けないほど便利に使っています。今回は、そのClaude Codeとの会話ログを分析すること

                                                        Claude Codeの会話ログをDuckDBで分析して自分の仕事スタイルを改善する方法 - yasuhisa's blog
                                                      • できるだけ無料で作る個人開発のための技術スタックと注意点

                                                        最近思いつきで身内向けにTwitterクローンを開発していて、そこでの知見をゆるく共有したいと思います。技術選定の段階で以下の記事を参考にさせていただいたのですが、この記事の内容を前提として代替案としてこれもいいんじゃない?という話をしたいと思います。 フロントエンド 元々私は個人的にずっとNuxtを使っていたのですが、やはり現状はNext.js (+ Tailwind CSS)が一番良い気がします。一度勉強してみたら全然アリだな、と思いました。 バックエンド こちらもNext.jsでフロントエンドと同時に開発できます。Next.jsのServer Actionsはサーバーコンポーネントとクライアントコンポーネントどちらからでも呼び出すことができ、DBにアクセスしたりといったことができます。 Server Actionsの注意点 便利なServer Actionsですが、セキュリティの観点

                                                          できるだけ無料で作る個人開発のための技術スタックと注意点
                                                        • MySQLのロックに起因するブロックタイムアウト撃退記 - inSmartBank

                                                          こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし

                                                            MySQLのロックに起因するブロックタイムアウト撃退記 - inSmartBank
                                                          • なぜ DuckDB を採用したのか

                                                            概要 なぜ 自社 で DuckDB を採用したのかを、雑に書いていきます。 変更履歴 2025-03-12: DuckDB の開発体制と Zstandard で圧縮されたファイルの読み込みについて追記 2025-02-13: 今後やりたい事 v2 を追記 まとめ DuckDB / DuckDB-Wasm を利用する事で中小規模のサービスであれば、ログ解析や統計情報の可視化を低コストで提供することができる DuckDB を go-duckdb 経由で利用する事で、HTTP リクエスト単位での DuckDB を利用できる DuckDB-Wasm と OPFS を利用する事で、クライアント側での統計情報のため込みができるようになる 解決したい課題 解決したい課題は基本的にサービスの運用費を抑えるということです。中小規模のサービスでは運用費が大きな課題になります。 自社パッケージ向けのログ解析ツー

                                                              なぜ DuckDB を採用したのか
                                                            • 開発環境のデータベースでも本番環境相当のデータを使う - クックパッド開発者ブログ

                                                              こんにちは。レシピ事業部バックエンド基盤グループの石川です。 2014 年、このブログに『開発環境のデータをできるだけ本番に近づける』というタイトルの記事が投稿されました。 クックパッドでは、ユーザーさんが実際に体験している状況と近い状況を再現しながら開発することに価値があると考えています。技術的には、最初からレコードがたくさんあることによってパフォーマンス問題に気付きやすくなるなどの長所がありますし、サービス開発としても、実際のユーザーさんの体験を最速でなぞって素早くフィードバックループを回せるようになるという長所があります。 この慣習は 2014 年の記事から 10 年経った今でも続いています。一方でその実現手法については変化を続けてきました。現在のクックパッドでは状況に応じていくつかの手段を使い分けています。それらの手段については今まであまり公開されていなかったような気がするため、こ

                                                                開発環境のデータベースでも本番環境相当のデータを使う - クックパッド開発者ブログ
                                                              • オイ、そこのSELECT COUNT。余計な数え上げに意味なんかねえ - inSmartBank

                                                                こんにちは。MySQLは秋の季語とする一派が世に存在していることを知り、私もMySQLに関わる記事を書いてみようと筆を取ることにしました。 さて、リレーショナルデータベースをバックエンドとするWebアプリケーション開発において、特定の条件に合致するレコードがN件だけ存在するかどうかを確認するロジックは頻出といえます。プログラマとして一度は書いたことがあるのではないでしょうか? この記事ではそのような件数カウントを行うためのクエリが引き起こした性能劣化と、その改善アプローチについて紹介していきます。 なお、本記事の内容はMySQLを前提としており、アプリケーションコードの例はRuby on Railsを用いますが特別な前提知識は必要ありません。コードの雰囲気だけ感じ取っていただければと思います。 ありがちなコード if query.count == n の問題 冒頭で述べた通り、特定の条件に

                                                                  オイ、そこのSELECT COUNT。余計な数え上げに意味なんかねえ - inSmartBank
                                                                • ODBCドライバーとは? ODBCの仕組みからドライバーの使い方まで解説!

                                                                  企業が業務システムにMySQL、PostgreSQL、Oracle、SQL Server といったリレーショナルデータベースを使いはじめてから今に至るまで、データベースへのコネクティビティは重要な課題であり続けています。1992年にMicrosoft が発表したOpen Database Connectivity(ODBC)API は、この課題に対する画期的な解決策となりました。 ODBC は、アプリケーションと多様なデータベース間の接続を標準化する技術として、現在でも広く採用されています。本記事では、ODBC 技術の仕組みとODBC ドライバーの役割、その重要性について詳しく解説します。 ODBC の仕組み ODBCとは ODBC は、アプリケーションからデータベースへのアクセスを標準化するためのAPI です。ODBC 4.0 の仕様はこちらに定義されています。この技術により、アプリケー

                                                                    ODBCドライバーとは? ODBCの仕組みからドライバーの使い方まで解説!
                                                                  • データベース自作勉強会・輪実装会のススメ - エムスリーテックブログ

                                                                    先日、社内有志で開催していたDB自作本 Database Design and Implementation の輪読会ならぬ輪実装会がついに完結を迎えました。 RDBMSをゼロから、毎週一人ずつ、1章分を実装してPullRequestを出しつつ資料も準備して発表をこなすという一見ハードな勉強会で、完走できるか不安もありつつスタートしましたが、やってみるとめちゃくちゃ楽しく最後まで完走できました。 本記事ではみなさんに「うちでもやってみたい」と思ってもらえることを願って、読んだ本の推しポイントや、どのように勉強会を進めたかを紹介したいと思います。 感動で涙の出るコード Part1: おすすめポイント 本が良い みんなでワイワイやるのが良い 3ヶ月で完走できるのがいい 完走後のモチベーションアップが良い Part2: 輪実装会 募集 参加者 進め方・実装 期間 Part3: おれたちのDB実装

                                                                      データベース自作勉強会・輪実装会のススメ - エムスリーテックブログ
                                                                    • 正規化を理解しているまともなITエンジニアなら、漏れなく戸籍廃止論者だよね?

                                                                      T/O と書きたいところだけど説明してみる。 実際に相続とかで戸籍を取ってみればわかるけど、現状の戸籍って個人(名前・性別・生年月日)と住所と血縁関係のリレーションテーブルなんだけど、主キーであるはずの住所が更新されないことが当然とされているっていう、DB的にはかなり不都合のある状態なんだよね。 あと血縁関係についても正確さが保証されていないし。 それだったら、ちゃんとメンテされるリレーションテーブルを作ろうよ、というのが戸籍廃止論で、正規化を理解しているまともなITエンジニアなら全員理解できると思う。 (正規化を理解しているまともなITエンジニアは少数かもしれないけど)

                                                                        正規化を理解しているまともなITエンジニアなら、漏れなく戸籍廃止論者だよね?
                                                                      • Liam

                                                                        SQL Server Backup Playbook: From Basics to Advanced StrategiesText by Takafumi Endo SQL Server backup represents a critical component of database management, serving as the primary defense against data loss and system failures.

                                                                          Liam
                                                                        • pixivの全文検索基盤とElasticsearchによるリプレイス - pixiv inside

                                                                          まもなく17周年を迎えるpixivでは、長年にわたり作品などの全文検索基盤としてApache Solrを使用してきました。 しかし、サービスの規模が拡大する中で、従来の基盤に問題が生じていました。これを受けて、pixivでは全文検索基盤のリプレイスを実行しました。 今回のリプレイスにより、pixivでは検索結果の更新反映時間や検索APIのレイテンシが大幅に短縮されました。また、今後のスケールに対応可能になり、新機能開発においても全文検索が容易に利用できるようになりました。 本記事では、pixivの全文検索基盤の歴史や、今回オンプレミス環境でElasticsearchクラスタを構築し、リプレイスを完了するまでの取り組みについてご紹介します。 こんにちは。pixivのnamazuです。最近、私たちのチームで進めていたpixivの全文検索基盤のリプレイスが完了しました。この機会に、pixivの全

                                                                            pixivの全文検索基盤とElasticsearchによるリプレイス - pixiv inside
                                                                          • データベースエンジニアの仕事を楽にする。PgAssistantの紹介

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

                                                                              データベースエンジニアの仕事を楽にする。PgAssistantの紹介
                                                                            • 製品ドキュメントは読むのではなく質問する時代

                                                                              VS Code の GitHub Copilot が MCP クライアントとして動作する仕組みが追加されたので、Copilot から気軽に自社製品の質問ができたら、快適ではないだろうか?考えた。 そこで、ハルシネーションをできるだけ少なくし、かつ安価で自社製品ドキュメントへの質問ができる仕組みを作ってみることにした。ちなみに LLM 系の知識はほぼ無い。 できあがった Sora Document MCP (Local) 0:00 /0:57 1× GitHub Copilot + Sora Document MCP デモ まぁまぁの速度で、質の高い回答を箇条書きで返してくれるようにはなった。 仕組みについて自社製品のドキュメントは Sphinx というフレームワークをを利用しており、reStucturedText (以降 rst) というマニアックなもので書かれている。この rst を L

                                                                                製品ドキュメントは読むのではなく質問する時代
                                                                              • 簡易DBをフルスクラッチで実装して得た学び

                                                                                ☀️ はじめに 最近 「Database Design and Implementation」 という技術書を読みました。 本書は、一般的なDBMSについての設計パターンを概説しつつ、その一つのパターンをJavaで実装するというものです。 しかし、ただJavaのサンプルをそのまま動かすのでは味気ないので、今回は Go で書き直しています。 実装する機能はごくシンプルに絞っていますが、実際に自作することで「DBMSが内部で何をしているのか」が肌感覚でわかり、非常に勉強になりました。(まだ一部実装しきれていない部分はありますが...) 📝 実装した内容 この書籍では、DBMSの設計における複数の実装パターンを解説したうえで、そのうちの1つを実際に作るという構成になっています。おかげで、シンプルなDB機能を一通り体験しながら理解を深めることができました。今回実装した機能の一部を挙げると、次のと

                                                                                  簡易DBをフルスクラッチで実装して得た学び
                                                                                • 今日から『自由』にMySQLの性能改善始めます。(MySQL開発チームを退職しました)

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