The how and why of optimal performance | Fractaled Mind
Over the last year or so, I have found myself on a journey to deeply understand how to run Rails applications backed by SQLite performantly and resiliently. In that time, I have learned various lessons that I want to share with you all now. I want to walk through where the problems lie, why they exist, and how to resolve them. And to start, we have to start with the reality that… Unfortunately, ru
「複雑すぎるサーバー構成」を原点にまで簡素化する「Litestream」が生まれた理由
現代のシステムでは、冗長化や負荷分散の観点から、複数のサーバーにサービスを分離することが当たり前となりました。しかし、キャッシュやキューの乱用など、システム構成が必要以上に複雑化している場合もあります。「複雑化したサーバー構成」を簡素化すべく、Goのローカルデータベースとして知られるBoltの開発者・ベン・ジョンソン氏が生み出したのが「Litestream」です。 Why I Built Litestream - Litestream https://litestream.io/blog/why-i-built-litestream/ ジョンソン氏が「古き良き時代だが、実のところは最悪な時代」と語る数十年前は、単一のプログラミング言語とSQLの知識があればどんな開発現場でも通用し、すべてのウェブサイトが基本的なHTML技術で作成されていた時代だったとのこと。1990年代後半には「Linux
PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
rspec-railsでのAR::PendingMigrationError時のバックトレースを消す - koicの日記
元ネタは Rails 5.2 で入る kirs さんによる以下の PR となる。 github.com たとえば、RSpec でテストを実行しようとした際に db:migrate を実行していないものがあるときの振る舞いが以下のとおりになる。 % bin/rspec Migrations are pending. To resolve this issue, run: bin/rails db:migrate RAILS_ENV=test これまではこの後に読むことのないバックトレースがだらっとついていたので、ノイズが減って良いと思う。 Rails 標準で採用されていない RSpec で Rails アプリケーションを開発しているケースでは rspec-rails を使っていると思うが、spec/spec_helper.rb か spec/rails_helper.rb で ActiveR
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
ActiveRecordのバルクインサート比較 その1 - @ledsun blog
手始めにRails6で追加されたinsert_allとimport(とその他)のパフォーマンス検証 - Qiita を追証します。 次のように検証用のRailsアプリケーションを用意します。 bundle exec rails new . bulk_insert -MCAJT bin/rails g user name:string bin/rails db:prepare DBはとりあえずSQLite3で行きます。 app/models/user.rbに元記事通りのスクリプトをコピペします。 class User < ApplicationRecord class << self def benchmark_bulk_insert # create data import_data = [] 1_000.times { import_data << new(name: 'name', c
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
外部キー制約に伴うロックの小話
4. ロックおさらい（簡易） • 共有ロック（LOCK_S） 共有ロック同士は互いにブロックしない 例：SELECT LOCK IN SHARE MODE • 排他ロック（LOCK_X） 何も受け付けないぞ、排他 例：INSERT(成功), UPDATE, DELETE, SELECT FOR UPDATE X S X Conflict Conflict S Conflict Compatible 4 大きく分けてロックは2種類 5. 5 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MODE; > BEGIN; トランザクションA トランザクションB 共有と排他順によるデッドロック例 6. 6 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MO
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
GitHub - sue445/index_shotgun: duplicate index checker :gun: :cop:
$ index_shotgun postgresql --database=index_shotgun_test # ============================= # user_stocks # ============================= # index_user_stocks_on_user_id is a left-prefix of index_user_stocks_on_user_id_and_article_id # To remove this duplicate index, execute: ALTER TABLE `user_stocks` DROP INDEX `index_user_stocks_on_user_id`; # ============================= # user_stocks # ==========
楽々ERDレッスンを読んだ - patorashのブログ
TLで良書だというのをチラホラと見かけていたのだけれど、結構古い本なので迷っていたのだが、今でも通用しそうな内容っぽいので買って読んでみた。 TLで見かけてた、楽々ERDレッスンを手にいれたので読んでいく。 pic.twitter.com/f7WEl6mHft— パトラッシュ@エキスパート職 (@patorash) 2021年2月1日 感想から書くと、これもまた「UNIXという考え方」と同じで、もっと若いうちに読みたい本だった…😇 この本の内容を知っていれば、データベース設計で悩むことも相当減っていたと思うし、プログラムで苦しむことも減っていたと思う。つまり、この本は「買い」です。かなりお薦めできる。もう読んでいる途中から社内のTeamsでは良書だと言いまくった。めちゃめちゃプッシュしたからか、後輩の何人かも買ってくれたみたいだった😋 ちなみに「UNIXという考え方」の感想はこちら。
DMS撤退 && Aurora撤退 を決めてきた 【Aurora撤退編】 - お？意外といけるやん！
オミカレでテックリードをしております、高橋です。 ちなみにその任も後2週間足らずで終わりです。 3月からは別の会社で働く事になっておりますが、これは転職 or 退職エントリでは無いのでまたの機会に..! いやぁーーー、この2〜3ヶ月、本当に色んなタスクを倒してきたなーーー！ DMS撤退に始まり数十万円単位でのインフラリソースの削減等も完了出来る状態になった。思い残す事は何も無い。 という事で本日、高橋は最終出社日でございます！— ikkitang (@ikkitang) 2021年2月11日 さて、表題の通りですが、この度 オミカレでの最後の大仕事として DMS撤退、Aurora撤退を決めてきたので どんな風に進めてきたか、みたいなのをアウトプットしようかと思います。 意思決定プロセスみたいなのも僕の能力で実現出来る限り言語化してみようと思うのでなにかご参考になれば嬉しいな、と思う限りです
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
Railsの楽観的ロックで発行されるSQL - Qiita
はじめに 環境: Ruby on Rails 5.1.1 Railsの楽観的ロックで、どういうSQLが発行されるかを検証する。 楽観的ロックについては http://qiita.com/merrill/items/d9d41d64df292bd6432a などを参照。 もしRailsの実装で "saveする直前にselectしてlock_versionを確認し、同じならupdate" となっていたら、このselectとupdateの間に横から更新が入ると問題になる。そうなっていないかどうか念のため確認したかった。 先に結論 インスタンスをupdateするとき、1回のSQL文で行われる。したがって上のような問題は起きない。 where + update_all をした場合は楽観的ロックの対象外になるので注意。 準備 migration class CreateDogs < ActiveRec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
GitHub - scenic-views/scenic: Versioned database views for Rails
そーだい@初代ALF on Twitter: "userみたいなクソ強い責務の名前のテーブル、memberなのかadminなのかloginなのかみたいなの考えた上でuserならいいし、userに大してupdateを流したときのロックの影響範囲を理解した上で外部キー制約を外さずに設計できるならテーブル分けなくてもいいと思う。"
楽々ERDレッスン 第2回：「図書館の予約申込書」編
Railsパフォーマンス・チューニング入門
