Ruby on Railsソフトウェア開発インデックス v2

Ruby on Railsフレームワークで作業する場合、通常はMySQLやPostgreSQLのようなリレーショナルデータベースを扱います。Active Record Migrationsを使用してマイグレーションを定義するとき、いわゆるインデックスに出くわしますが、初心者はインデックスとそれがもたらす利点についてよく理解していないことがよくあります。

この投稿では、インデックスとは何か、インデックスが何のために使われるのかを説明し、インデックスの採用方法についていくつかのグッドプラクティスを紹介したい。

データベース

データベース・エンジンは数多くあるが、最もポピュラーなもののひとつに、先に挙げたMySQL、PostgreSQL、Oracle、Microsoft SQL Serverがある。これらはすべてリレーショナル・データベースであり、すべてのデータは互いに関連付けられ、テーブルに格納されている。各テーブルの行はレコードと呼ばれ、それぞれ固有の識別子（id）を持っている。https://db-engines.com/en/ranking、最も人気のあるデータベースエンジンのランキングをチェックできる。MongoDBのような非リレーショナルデータベースもあります。

インデックスの作成

データベースのテーブルは、数個から数十個、極端な場合は数百個のカラムを持つことができる。各テーブルの行数は無制限であることに注意してください。この数はデータベースの構造から直接生じるものではなく、レコードの数がどんどん増えていき、結果としてデータベースが大きくなっていくことを常に想定しておく必要があります。既存のアプリケーションで書かれた初期の仮定やクエリは、レコード数が少ないか中程度であれば素晴らしいかもしれませんが、時間の経過とともに、より多くのデータが到着すると、アプリケーションとデータベースとの通信は効率的ではなくなります。

プログラマーの役割は、テーブルからデータを取り出すためのクエリーを書くことだが、クエリーの最適な処理方法はデータベース・エンジンに依存する。データベースエンジンはデータをディスクからメモリにロードし、それをスキャンすることを覚えておいてください。つまり、多くのユーザーが同時に複雑な操作を行うと、検索を実行するためのリソースが不足するため、何人かのユーザーが順番を待たなければならなくなります。これが、関連インデックスが非常に重要な理由である。

ウィキインデックス - テーブルの検索処理を高速化するデータ構造。

各インデックスには、テーブル内のレコードを検索するために使用するキー（1つまたは複数のカラム）を定義する必要があります。インデックス内のデータは、あらかじめ定義されたキーでソートされる。日常生活で最も単純な例は、名前と姓でソートされた電話帳である。この場合のインデックスは姓と名である。

最適なインデックスキーの選び方は？難しいことではありません。いくつかのルールを覚えておいてください。以下のカラムに基づいてインデックスを作成する：

- は私たちの問い合わせ（WHERE）でよく使われる、

- を互いに組み合わせることで、一意な値（つまり、正確に1行を示す値）が得られます、

- はいわゆる連結列（JOIN）として使われる、

- は最も選択的なキー、つまりクエリーを書くときに最も少ない行数を返すキーを与える。

どのキーがテーブルにとって最適かがすでに分かっているのであれば、インデックスがいくつ必要かを自問することもできる。この場合、設計段階ですでにテーブルを参照するクエリを把握しておくのがベストです。

登場する特定のクエリのためにインデックスを作成しよう。インデックスもテーブルと同様、どこかに格納する必要があるため、カラムごとにインデックスを持つテーブルを作成すると、使用する容量が大幅に増えることを考慮しなければならない。

ユニーク・インデックスの作成

もうひとつ考えなければならないのは、一意性である。インデックスが本当に一意であるかどうかを考えるのに5分余分に費やす価値はあります。こうすることで、クエリオプティマイザに、クエリの重複を期待する必要がないことを伝えることができます。例えば、メールアドレス：

frozenstringliteral: true

クラス CreateUsers < ActiveRecord::Migration[6.0］
def change
createtable :users do |t|
t.string :email, null: false
end
addindex :users, :email, unique: true
end
終了

PostgreSQLエンジンの例で、emailカラムにユニークインデックスがある場合とない場合のクエリー速度の違いを示します。

1.サンプル コード スニペットを自分のデータベース上で作成し、以下の例をテストできるようにしてください。まず、カラムが1つの空のテーブルを作成してみましょう：

 CREATE TABLE users (
   電子メール varchar
 );

2.テスト用に10,000レコードを生成してみよう：

 DO $
   BEGIN FOR i IN 1..10000 LOOP
     INSERT INTO users values((select 'user' || i || '@example.com'))；
   END LOOP; END；
 $；

EXPLAIN ANALYZEを使用して、データベース内の特定のユーザーを検索する場合のクエリの処理速度をチェックします。

EXPLAIN ANALYZE SELECT email FROM users WHERE email = 'user890example.com'；

このクエリーは、興味のあるレコードを探すために、テーブル全体を強制的に反復させる。

この処理はシーケンシャル・スキャンと呼ばれる。この場合、テーブル全体を読み取り、特定の行をフィルタリングするのが最適な方法である。

PostgreSQLは不要な行をフィルタリングし、興味のある行だけを返します。これはこの例では本当に最善の方法です。シーケンシャルスキャンが常に悪いわけではなく、シーケンシャルスキャンが理想的な場合もあります。

4.今こそ、INDEX UNIQUEを持つテーブルに対して既に行われたクエリをチェックする時です。インデックスを設定し、クエリを実行してみましょう。

 EATE UNIQUE INDEX index_email on users(email)；
 EXPLAIN ANALYZE SELECT email FROM users WHERE email = 'user890example.com'；

今回、PostgreSQLはインデックススキャンを利用しました。

インデックスを使用する場合、数行だけを選択するのは非常に効率的である。しかし、より多くのデータを選択すると、インデックスとテーブルのスキャンに時間がかかりすぎる。

概要

ご覧のように、インデックスを持つ列に対する問い合わせの実行時間は非常に短くなっています（示された例では、1.267msから0.111msに減少しており、91.24%と同じです！）。最も重要な違いは、PostgreSQLが興味のあるレコードを検索する方法です。最初のケースでは、データベースエンジンは必要なレコードを探すためにテーブル全体を検索しなければなりませんでした。しかし、2つ目のケースでは、インデックス構造はソートされ、一意であるため、エンジンはレコードがどこにあるかを知っており、クエリ処理の時間を大幅に短縮することができました。

大規模なデータベースや非常に複雑なクエリの場合、インデックスを正しく設定することで、データベースを検索するマシンの速度を上げることなく、アプリケーションの作業を大幅に高速化することができます。

各カラムにインデックスを作成することは良い習慣ではないことを覚えておく価値がある。確立されたインデックスは、目的のデータを検索する際のオプティマイザの作業をスピードアップさせますが、同時に新規の挿入や既存のインデックスの更新を遅くします。

続きを読む

– Railsアプリで一般的なJSフレームワークを使用する必要がありますか？Stimulus.jsが代替になるかもしれません。

– 新しい現実の時。リモートワークの時代が始まって1カ月

– ウェブアプリ開発：なぜRuby on Railsは選ぶ価値のある技術なのか？