成長するにつれてデータベースのスケーリングを容易にするための簡単なヒント

若いプロジェクトに取り組んでいるときは、後で拡張するのが簡単または困難になるような意思決定を常に行っています。より速く出荷できるように、技術的負債を少し増やすために、短期的な利益を選ぶのが良い場合があります。しかし、別の方法があることを知らなかったために技術的負債を受け取ることもあります。

これは、ここHoneybadgerで、私たちの生活を必要以上に困難にするいくつかのことを行ったためです。いくつかの重要なポイントを理解していれば、スケーリングはそれほど苦痛ではなかったでしょう。

UUIDを使用する

「主キー」と言うとき、私たちのほとんどは自動インクリメント番号を思い浮かべます。これは小規模なシステムではうまく機能しますが、スケーリングすると大きな問題が発生します。

常に、1つのデータベースサーバーのみが主キーを生成できます。つまり、すべて 書き込みは単一のサーバーを経由する必要があります。 1秒間に何千もの書き込みを実行したい場合、これは悪いニュースです。

UUIDを主キーとして使用すると、この問題を回避できます。それらに精通していない場合、UUIDは次のような一意の識別子です：123e4567-e89b-12d3-a456-426655440000 。

ウィキペディアでの説明は次のとおりです。

標準的な方法に従って生成された場合、UUIDは、中央の登録機関やそれらを生成する当事者間の調整を必要とせずに、実用的な目的で一意になります。 UUIDが複製される確率はゼロではありませんが、ゼロに非常に近いため無視できます。

したがって、誰でもUUIDを作成し、それを使用して、他の何かを識別するためにすでに作成された識別子と重複せず、将来複製されないことをほぼ確実に識別できます。したがって、独立した当事者によってUUIDでラベル付けされた情報は、識別子間の競合を解決する必要なしに、後で単一のデータベースに結合したり、同じチャネルで送信したりできます。

UUIDを主キーとして使用すると、すべての書き込みが単一のデータベースを経由する必要がなくなります。代わりに、それらを多くのサーバーに分散させることができます。

さらに、前のレコードのIDを生成するなどの柔軟性を提供します。 データベースに保存されます。これは、レコードをキャッシュサーバーまたは検索サーバーに送信したいが、データベーストランザクションが完了するのを待ちたくない場合に役立つことがあります。

RailsアプリでデフォルトでUUIDを有効にするのは簡単です。設定ファイルを編集するだけです：

# config/application.rb
config.active_record.primary_key = :uuid

Railsの移行では、個々のテーブルにUUIDを使用できます：

create_table :users, id: :uuid do |t|
  t.string :name
end

これは単純な構成オプションであり、開発を開始するときに有効にすると、スケーリングを試みるときに問題の世界を救うことができます。追加のボーナスとして、ボットや悪意のある人物があなたのプライベートURLを推測するのが難しくなります。

MyRecords.where("created_at < ?", 1.year.ago).destroy