Pitfalls of Rails db transactions
Rollback Rails transaction and rescue error to display it good: This is fine record = MyModel.last error_for_user = nil begin ActiveRecord::Base.transaction do # ... record.save! end rescue ActiveRecord::RecordInvalid => e # do something with exception here error_for_user = "Sorry your transaction failed. Reason: #{e}" end puts error_for_user || "Success" source, source2, source3 This is ok as wel
プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空
zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
RDS Proxyを使うとDB接続処理は早くなるのか？ | DevelopersIO
CX事業本部＠大阪の岩田です。 コネクションプーリングのメリットとして、接続済みのDB接続をプーリングして再利用することでアプリケーションからDBに接続する際のオーバーヘッドが削減できる というメリットがあります。このメリットはアプリケーションレイヤでDB接続をプーリングするアーキテクチャにおいては効果が大きいですが、RDS Proxyのようなプロキシ型のコネクションプーリングでは効果が薄くなりがちです。アプリケーションからDBプロキシに接続する際にTCPの3WAYハンドシェイク等の接続処理が必要になるからです。 このブログではLambdaからRDS/RDS Proxyに対して接続/切断を繰り返し、RDS Proxyを利用することでDB接続処理が早くなるか？を実際に検証してみました。 計測方法と環境(共通) ざっくり以下の手順で計測しました。 メモリを1792MB割り当てたLambda(P
Managing db schema changes without downtime
At Discourse we have always been huge fans of continuous deployment. Every commit we make heads to our continuous integration test suite. If all the tests pass (ui, unit, integration, smoke) we automatically deploy the latest version of our code to https://meta.discourse.org. This pattern and practice we follow allows the thousands self-installers out there to safely upgrade to the tests-passed ve
Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
An in-process SQL OLAP database management system
分割と整合性と戦う