タグ

データベースに関するkabakiyoのブックマーク (8)

  • データベースの値をちょっとだけ書き換えたら検索に数十分かかる様になって障害になった裏話 - STORES Product Blog

    はじめに 2024年1月にリテール(ネットショップ・レジ)部門からサービス(予約)部門に異動になった @ucks です。 異動してからはスマートリストという機能の開発を行っていて、5月6日に無事リリースできたのと、開発途中で障害に至ってしまった部分があるので、裏側を少し紹介しようかなと思います。 はじめに スマートリストとは スマートリストの設計 検索の仕様変更 高負荷時のハンドリング そして障害へ 見逃した点 DBの実行計画確認時の見逃し 動作確認時の漏れ 監視先の漏れ ログの損失 おわりに スマートリストとは スマートリストの開発についての話を行う前に、まずはスマートリストについて簡単に説明しておきます。 スマートリストとは、特定の条件の顧客をラベリングする機能です。 早い話、最終予約日がいつ、予約回数が何回以上等の顧客の検索条件を保存しておいて、閲覧時にラベリングして、視認しやすくし

    データベースの値をちょっとだけ書き換えたら検索に数十分かかる様になって障害になった裏話 - STORES Product Blog
  • Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary

    先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの

    Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
  • How Does a Database Work?

    What format is data saved in? (in memory and on disk) When does it move from memory to disk? Why can there only be one primary key per table? How does rolling back a transaction work? How are indexes formatted? When and how does a full table scan happen? What format is a prepared statement saved in? In short, how does a database work? I’m building a clone of sqlite from scratch in C in order to un

  • データベースのロックの基礎からデッドロックまで

    データベースのロックについて、資料を読んだり実際に試してみたので、学んだことを整理してみようと思います。はじめにロックについての基的な知識を整理して、最終的にはデッドロックとその対策について説明します。 使用したソフトウェアのバージョン MySQL 8.0.31 この記事ではMySQLを使用しています。その他のデータベースについては、基的な部分は共通していると思いますが、異なる点があることをご了承ください。 ロックとは何か(概要) ロックはデータの更新を正しく行うための仕組みの一つで、あるデータに対する更新処理を制御するためのものです。ここで、データを正しく更新するとはどういうことかを説明するために、口座への振込を例に考えてみます。 例えば、口座Aから口座Bに1万円の振込を行うとします。このとき、口座Aの出金処理と口座Bの入金処理は、必ず両方が成功しなければなりません。このための仕組み

    データベースのロックの基礎からデッドロックまで
  • データベースの障害回復機能(ロールバックとロールフォワード) : ouyou

    データベースサーバの電源故障などにより、データベースに障害が発生することがあります。データベースには、障害が発生した場合、特にメモリ上のデータは消えてしまうことがあります。そんな場合でも、データを障害発生の直前に戻す機能が備わっています。 まずは、データの書き込み処理を理解しましょう。データの追加・変更などの処理によって、データの保存には次の3つのアクションがあります。 ①SQL操作(UPDATEやDELETEなど) 更新前ログと更新後ログをメモリに書き込みます。ログは、操作の都度記載されます。このときの更新前ログが、ロールバックに活用されます。製品の実装にもよりますが、このログはファイルにも書き込むことでしょう(そうしないと、システム障害時にロールバックできません)。ログファイルはジャーナルファイル(Oracleの場合はREDOログ)と言われます。 ②コミット(COMMIT)を実行 変更

    データベースの障害回復機能(ロールバックとロールフォワード) : ouyou
  • データベース: トランザクション分離レベルについてまとめてみる

    1. ダーティーリード ダーティリードはトランザクション処理において、あるトランザクションが更新されている最中に、他のトランザクションからデータを読み出すことができてしまう現象のこと。 ここではトラン2が"りんご"を"みかん"に変更した後、トラン1が"みかん"を読み込むがその後、トラン2によって"みかん"は"りんご"にロールバックされます。 汚れ(誤り)のあるデータを読み込んでいることがわかります。 図の例の場合の対策例としてはトランザクション2が専有ロック(他のトランザクションによる書き込み、読み込み不可)を対象の行にかける等が考えられます。 2. ノンリピータブルリード(ファジーリード) 読み出した行がほかのトランザクションにより更新または削除され、同じトランザクションで再度同じ行を読み込んだときに、その行が更新または削除されていること。 ここではトラン1が"りんご"を読み出した後、ト

    データベース: トランザクション分離レベルについてまとめてみる
  • PostgreSQLで全角半角大文字小文字ひらがなカタカナを区別せず検索したい!というよくあるわがままに応える - ほんじゃらねっと

    したいしたい!絶対したい!と駄々をこねられたので調査してみた。 こういった区別なし検索を実装する方法としてパッと思いつくのは、 あらかじめ検索対象となるカラムの検索用カラムを用意して、 データ変更時にトリガーで 元カラムの内容を半角小文字英数字カタカナに変換したデータが入るようにしておき、 検索時はその検索用カラムを使用する、という方法。 これはめんどくさそうだ。 SQL Serverは照合順序の設定で制御できるらしい。 照合順序と Unicode のサポート PostgreSQLも同じことができないかと調べてみたけど、対応してなさそう。 第22章 多言語対応 他に方法がないか調べてみると、 「式インデックス」を使って、自作の変換用関数で変換したデータを インデックスに登録しておく方法を試しているページがあった。 PostgreSQLで全角半角を区別しない問い合わせ この方法なら少なくとも

    PostgreSQLで全角半角大文字小文字ひらがなカタカナを区別せず検索したい!というよくあるわがままに応える - ほんじゃらねっと
  • データベース設計の際に気をつけていること - 食べチョク開発者ブログ

    皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ!”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

    データベース設計の際に気をつけていること - 食べチョク開発者ブログ
  • 1