監査ログの保管先をRDBからS3に移行する - メドピア開発者ブログ
こんにちは。サーバーサイドエンジニアの @atolix_です。 今回はメドピアで運用しているアプリケーションのkakariの監査ログをDB管理からS3管理に移行したので、その方法と手順について紹介したいと思います。 kakari.medpeer.jp 背景 従来kakariではAuditedを用いて、監査ログを専用のauditsテーブルに保管する処理を行っていました。 github.com # application_record.rb class ApplicationRecord < ActiveRecord::Base ... include Auditable # auditable.rb module Auditable extend ActiveSupport::Concern included do audited ... end しかしレコードの変更の度にauditsテーブ
Amazon Auroraに2種類のオートスケーリングポリシーを組み合わせてコストを削減しました - Nealle Developer's Blog
こんにちはSREチームの宮後(@miya10kei)です。最近、DisplayLink対応の変換アダプターをGETし、トリプルディスプレイ化していろいろ捗っています！ 前回から少し時間が空いてしまいましたが、今回はAmazon Auroraに対して2種類のオートスケーリングポリシーを組み合わせた事例を紹介します。 背景 Park DirectではデータベースにAmazon Aurora（Provisioned）を利用し、Writerインスタンス1台、Readerインスタンス2台の構成で運用しています。 ReaderインスタンスのCPU利用率には次の傾向がありました。 ReaderインスタンスのCPU利用率の推移 CPU利用率の傾向 平日 08:00~18:00までCPU利用率が（相対的に）高い状態が続き、18:00を境に低い状態になる。 休日 平日と同じ傾向だが全体的にCPU利用率が低い状
RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)
結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは？ MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBでのツリー表現入門2024 | ドクセル
MySQLで処理するGIS ～地球が丸いことを覚えたMySQL～ / MySQL GIS FOSS4G TOKAI 2023