今更ながらMATERIALIZED VIEW(マテリアライズドビュー)について学ぶ

アプリケーションにおいて高負荷になりやすい処理の一つにレポート・データ集計があります。
リアルタイム性が求められる場合もあれば、ある時点までに集計されたデータを見れればOKなど、要件はさまざまですが、一般的にはデータベースに対して複雑なクエリや複数テーブルに対しての結合を行う必要があります。そのためデータ量に依存しやすく、リリース当初は問題なくレポートが見れていたのに、サービスの運用期間が長くなるとレポートが見えなくなったという話をよく聞きます。

この問題への対処方法の1つとして、データのキャッシュ化が挙げられます。
リアルタイム性は失われてしまいますが、ある時点までの集計がされているデータを用意しておけば、都度、集計を行う必要がないため結果を表示するまでの時間を大幅に短縮することができます。

MATERIALIZED VIEWによるキャッシュ化

キャッシュ化をアプリケーション側で実装しても良いですが、実はデータベースにはMATERIALIZED VIEW(マテリアライズドビュー)という、SQLの実行結果をキャッシュする機能が提供されています。通常のビューとは異なり、SQLの実行結果を保持してくれるため、あたかも1つのテーブルのように扱うことができます。

PostgreSQLにおけるマテリアライズドビューはビューのようにルールシステムを使用しますが、あたかもテーブルであるかのような形態で結果を保持します。

マテリアライズドビュー

2023年に買って良かったもの

早いもので2023年も終わろうとしています。
いやー、今年もあっという間でしたね。今年もたくさん記事を書いてきましたが、どうでしたでしょうか。
読者の皆さんをはじめ、僕の記事を読んでくださる方には頭が上がりません。本当にいつもありがとうございます。年末なので毎年恒例(?)の「〜年に買って良かったもの」の記事を書きたいと思います。

自称ミニマリストなんですが、なんだかんだで色々と買ってしまいました。
新居に引っ越して今年で2年経つのですが、長く住んでいるとモノが悪くなってきたり「うーん、何か違うなぁ...」と目につくものが続々と現れる一年間でした。
ということで、2023年に買って良かったと感じているものを順不同で紹介していきたいと思います。

NULL値が含まれるカラムにインデックスは有効なのか

データベースで0対Nのモデルを表現する際に、よく外部キー制約とNULL許容の制約を定義することがあります。
値は特定のテーブルのIDもしくはNULLのどちらかを持つことになります。これを出版社(publishers)と書籍(books)のモデルをテーブルに落とし込んでみると以下のようになります。
基本的に書籍は出版社から出版されてbooksテーブルのレコードはpublisher_idで紐付けられますが、個人出版・データベースに登録されていない出版社から出版された書籍はpublisher_idにNULLを持つこととします。別途、個人か企業による出版かのカラムを持たせたり...と考えられることはありますが、今回は簡単のために省略します。

しばしば出版社がどんな書籍を出版しているのかを検索したいため、books.publishers_idに検索用のインデックスを作成します。 このインデックスは出版社から出版されている書籍に対して、検索の高速化を期待してのものですが、果たして個人出版の書籍の絞り込み(books.publishers_idがNULL)に対しても有効なのでしょうか。
NULLを含むカラムを検索するということは一般的なことだと思いますが、意外にも深く考えたことがなかったテーマです。 事前の予測ではインデックスが効いてくれると思いますが、実際に検証してみたいと思います。

Ruby3.4で追加されるブロックパラメーター"it"について

先週、届いたRuby Weeklyに面白そうなトピックが紹介されていました。

Ruby 3.4 Will Have 'it'
— There’s never been any doubt: Ruby has it. But now as well as the ‘it’ factor,
it really will have it. Confused? it is a nicer looking shortcut to the first parameter in a block (a la _1) – e.g. arr.each { puts it }.
Ruby 3.3 will warn on it with 3.4 (due in a year’s time) getting the real deal.
TAKASHI KOKUBUN

Re-reconsider numbered parameters: it as a default block parameter

ふむふむ...。
要するにRuby3.4系では、ブロック構文のデフォルトパラメーターにitが設定されてブロック引数をしてしなくても要素の参照が可能になるということです。

# 3.4系だとOK
[1,2,3].each do 
  puts it
end

データベースにおけるJSON型のカラムの使い所

最近、データベースのテーブル設計を担当したり、既存のテーブル設計を見ることが多いです。
テーブルの設計書を見てみるとJSON型が指定されているカラムが目につくことがあります。既存のテーブルでもJSON型が使われている箇所がありました。
「json型を使うな！」というわけではありませんが、前から何度も言っているように設計やアーキテクチャというのは常にトレードオフです。JSON型のカラムについても同様にメリット・デメリットがあります。
今回はRDBにおいてJSON型を使っても良いケース、避けるべきケースについて個人的な所感を書いてみたいと思います。なお、今回の内容はSQLアンチパターンでも紹介されている「ジェイウォーク(信号無視)」を参考にしています。

SQLアンチパターン

とても良い書籍なので、データベースを触る人は一度は読んでおいて損はありません。