タグ

dbに関するtyamamotoのブックマーク (40)

  • データベースの楽観ロックと悲観ロックを理解する

    分離レベルを高くするほど、データの整合性は向上しますが、ロックが増えるためパフォーマンスは低下する傾向があります。アプリケーションの要件に応じて適切な分離レベルを選択することが重要です。例えば、高いスループットが必要な読み取り中心のアプリケーションでは READ COMMITTED を、金融取引のような厳密な整合性が必要なアプリケーションでは SERIALIZABLE を選択するといった判断が必要です。 楽観ロックの仕組み 楽観ロックの基概念とメンタルモデル 楽観ロック(Optimistic Locking)は、その名の通り「楽観的」なアプローチでデータの整合性を管理します。このアプローチでは、データ競合が発生する確率は低いという前提に立ち、事前にデータをロックせずに処理を進めます。 楽観ロックのメンタルモデルは、EC サイトでの買い物に似ています。あなたがオンラインショップで商品を閲覧

    データベースの楽観ロックと悲観ロックを理解する
    tyamamoto
    tyamamoto 2025/03/12
  • DBテーブルのカラムを削除するときにやること・考えること - エムスリーテックブログ

    突然ですが皆様は、稼働済みサービスのDBからテーブルカラムを削除されたりすること、ありますでしょうか? 基的に削除はまずやらないのではと思います。えっやらないの? と思われた方もいらっしゃるかもしれませんが、きっとこの記事を読めばなぜ多くの方がカラム削除を避けるのかわかることでしょう。 とはいえ、そうして使わないカラムがテーブルに溜まっていくとやがて新規加入メンバーがコードにキャッチアップする妨げとなるレベルにまで溜まってきたりします。いつかは大掃除のときがくるわけです。DBは寿命長いですからね。そうしたときに実際どのような手順でカラムを削除するのか見ていきましょう。エムスリーエンジニアリンググループUnit1(製薬プロモーション)・Unit9(治験臨床研究支援)チームエンジニアの三浦 [記事一覧 ]が、最近実際にやった作業から知見をお届けします。 長いので3行で 考え方 1. そのカ

    DBテーブルのカラムを削除するときにやること・考えること - エムスリーテックブログ
    tyamamoto
    tyamamoto 2024/12/26
  • 2024年度のサイバーエージェント新卒社内研修で「データベースの歴史」の話をしました | CyberAgent Developers Blog

    こんにちは。 AI事業部の協業リテールメディアdivでバックエンドエンジニアをしている yassun7010 といいます。 先日、 AI 事業部の新人研修で「データアプリケーション」の講師を同じチームの 千葉 と担当しました。 今回の記事では、主に私が担当した「データベースの歴史」の章の講義資料を公開し、資料を作成する際に考えていたこと・伝えたかったことを話します。 「データベースの歴史」で説明されている内容は、AI事業部の新卒研修で毎年取り上げられているものです。こういった研修の資料は、同じテーマであっても講師をする人の好みが反映されやすく、今年の資料も先人が作られた昨年の資料を参考にしつつ、私が好きな話題を多く取り入れたものに仕上がりました。 SlideShare でも公開しています。 今年の構成は、データベースを RDS・NoSQL・NewSQL として分け、下記のような構成を

    2024年度のサイバーエージェント新卒社内研修で「データベースの歴史」の話をしました | CyberAgent Developers Blog
  • SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita

    概要 この記事では、MySQLでのSQLクエリのパフォーマンスを最大限に引き出すための効率的な書き方を解説します。アプリケーションの応答速度を向上させることは、ユーザーエクスペリエンスの大幅な改善に直結します。この記事を通じて、初心者から中級者のデータベース管理者や開発者は、SQLクエリの基から高度な最適化テクニックまで、幅広い知識を習得できることを目指しています。 MySQL 8.0での検証を基にしていますが、その他のバージョンでの動作は保証されません。この記事は継続的に更新されます。 主な内容 このセクションでは、検証データの作成手順を含め、インデックスの利用、JOIN操作の最適化、サブクエリとビューの利用、クエリキャッシュの活用など、効率的なクエリの書き方について解説します。 検証データの作成 MySQLサーバーへの接続方法から始め、テスト用データベースとテーブルの作成、ダミーデー

    SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
  • WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました! - Qiita

    WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました!MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも, MVCC アーキテクチャの恩恵で, SELECT と UPDATE は基的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ,排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ,これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で,更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離

    WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました! - Qiita
    tyamamoto
    tyamamoto 2022/07/04
  • テーブルに登録されているデータからINSERTスクリプトを作成 [SQLServer]

    SQL Serverのテーブルに登録されているデータをもとに、INSERTスクリプトを作成するプログラムを作成します。 C#のプログラムでデータベースへ接続して、指定されたテーブルのデータを挿入するINSERT文のSQLスクリプトを作成し、クリップボードにコピーします。 SQLスクリプトを作成するプログラムを実行するプログラムは、Visual StudioのWindowsフォームアプリケーションで作成します。

    テーブルに登録されているデータからINSERTスクリプトを作成 [SQLServer]
  • NULL撲滅委員会

    序文 全国1千万の DB エンジニアの皆様、こんにちは。NULL撲滅委員会極東支部長のミックです。皆様におかれましては日々、DB の構築、SQL 作成、パフォーマンス・チューニング、番データの入ったテーブルをいともあっさり DROP した新入社員の尻拭いと、獅子奮迅の働きにてチームを支えておられるであろうと存じます。さて、日私が一筆啓上しましたのは、NULL撲滅基宣言への皆様の参加を募りたく思ったからです。 NULL というこの面妖な怪物の質の悪いところは、最初は私たちの感覚に心地よく合致すると感じられるため、ごく自然にするっとシステム設計の中に忍び込んできて、気が付いたときにはシステムをどうしようもなく複雑で、非効率的で、直観に反する動作をするに至らしめ、開発も運用も困難なものにしてしまうところにあります。ゆえに、NULL のもたらす脅威から身を守るには、まず第一にその正体をよく知

    tyamamoto
    tyamamoto 2020/06/05
  • NULL嫌いのUPDATEしないDB設計 #DBSekkeiNight / DB design without updating

    DB設計したいNight #6 正規化 [online] https://dbnight.connpass.com/event/177859/

    NULL嫌いのUPDATEしないDB設計 #DBSekkeiNight / DB design without updating
    tyamamoto
    tyamamoto 2020/06/05
  • A5:SQL Mk-2 - フリーのSQLクライアント/ER図作成ソフト (松原正和)

    特徴・機能 様々なデータベースへの接続 Oracle Database へはOCI接続(オラクルクライアント経由)、直接接続(オラクルクライアント不要)で接続出来ます。 PostgreSQL, MySQLへは直接接続(クライアントライブラリ不要)で接続出来ます。 Microsoft SQL Server へは NativeClient 経由で接続できます。 それ以外のデータベースへはADO(OLE DB)または、ODBCで接続出来ます。 SQL入力支援機能 Ctrl+SpaceでSQL文を解析しテーブル名やテーブルカラム名の入力補完が行えます。 共通表式や副照会も解析する強力な機能です。 AIアシスタント機能 外部AIサービス(OpenAI ChatGPT, Google Gemini, Anthoropic Claude, Microsoft Azure OpenAI, Ollama)の

  • 1日に100万レコード増える場合のテーブル設計

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

    1日に100万レコード増える場合のテーブル設計
  • DBの基礎 - コネクションプーリングについて

    コネクションプーリングについて、わかっていないことが多すぎたので、ちょっとだけ調べたことをメモで残しておきます。 今はまだ触りレベルしかわかっていなのいので、もう少しちゃんと分かるようになりたい! 😀 [スライド] データベースの羅針盤 コネクションプーリングを調べている過程で偶然見付け足資料 『データベース技術の羅針盤』。 とにかくわかりやすくて、俯瞰的にDBの業界を知ることができる資料。すばらしすぎる。 🎂 コネクション・プーリングとは?DBのコネクションを一定数確立しておいて、それを使いまわす手法のこと。 DBへの接続に必要となるオーバーヘッドをカットしてWeb/DBの双方の負荷を下げる。 また、WebとDBの接続を使いまわすことで同時接続数を節約する。 用意した、コネクション数を超えたアクセスは、コネクションに空きがでるまで待たされる。 以下はOracle関連の話ですが、基

    DBの基礎 - コネクションプーリングについて
  • DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

    DELETE_FLAG を付ける前に確認したいこと。 - Qiita
  • 削除フラグのはなし

    [DI12] あらゆるデータをビジネスに活用! Azure Data Lake を中心としたビックデータ処理基盤のアーキテクチャと実装

    削除フラグのはなし
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
    tyamamoto
    tyamamoto 2011/07/15
  • DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して

    データベースには,「トランザクション分離レベル」というものがある。 以下では,それが なぜ必要なのか? デフォルトのレベルでは,どうして駄目なのか? PostgreSQLでは,どうやってレベルを変更・確認するのか? などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは: 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか,のレベル。 ANSI規格では,4つのレベルがある。 READ UNCOMMITTED (一番低い) READ COMMITTED REPEATABLE READ SERIALIZABLE(一番高い) 徹底比較!! PostgreSQL vs MySQL 第3回:トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく

    DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して
  • ユーザーコミュニティ座談会(前編) 「データベーススペシャリスト資格不合格が勉強会のきっかけでした」 | oracletech.jp

  • 株式会社プロズサービス

    ”人とのつながりを大切にする” 当社が最も大事にしているキーワードです。 システム開発では関係者とのコミュニケーションに多くの時間を割いています。 この時間を省略して、質の高いシステムを提供することは難しいでしょう。 その上で、過去の経験や技術動向を踏まえ、プロフェッショナルな IT技術者として お客様の求めていることを実現する。 これが当社全員の目指す姿です。 人との関わり方に物足りなさを感じている方、 ご自身の経験をフル活用してお客様にサービスを提供したい方、 是非当社までご連絡ください。 まずはカジュアルに話をしましょう!

    株式会社プロズサービス
  • トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis

    データベースの同時実行性の定義データベースにおける同時実行性は、同時に共有データにアクセスしたり、 共有データを変更したりする複数プロセスの機能性として定義することができる。 互いにブロックすることなく同時に実行できるユーザプロセス数が多いほど、 データベースシステムの同時実行性は高いといい、データの変更プロセスによって、 他のプロセスがその変更データを読み取りできなかったり、 データの読み取りプロセスによって、他のプロセスがそのデータを更新できない場合、 同時実行性が低いという。また、複数プロセスが同じデータを同時に変更しようとすると 常にデータの整合性が損なわれるような場合も、同時実行性が低いと言える。 同時実行性が低くなる状況に対処する方法データベース システムで同時実行性が低くなる状況に対処する方法は、 使用している同時実行制御がオプティミスティック(楽観的)*1かペシミスティック

    トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis
  • なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − @IT

    ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture

  • データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ

    データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 OracleSQLServer、MySQLと色々なDBのチューニングをしてきましたが、

    データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ