サーバーレステクノロジーが大好きです。私はいろいろと遊んで、他のクールなテクノロジーを試すためにさまざまなサーバーレスアプリケーションを作成しています。私が使用/実験しているテクノロジーの巨大なクラスターの中で、PlanetScaleは PrismaORMがサポートする他の「良い」オプションがなかったために私が主に個人的なサイドプロジェクトに使用したデータベース 。

PlanetScaleは、MySQLの水平スケーリング用のデータベースクラスタリングシステムであるVitessを販売するMySQLサーバーレスプラットフォームです。彼らは独自のデータベースを作成しませんでした-おそらくそれに貢献しましたが、彼らはそれを作成しませんでした。 Vitessのドキュメントから：

Vitessは2010で作成されました YouTubeのチームが直面したMySQLのスケーラビリティの課題を解決するため。

この記事では、これらの非ACIDレガシーシャードデータベースの構造、参照整合性ほど重要なものをサポートできない理由、およびアプリケーションでの使用を避ける必要がある理由を理解する方向に進んでいきます。この記事はVitessのテクノロジーに関するものですが、タイトルにPlanetScaleを含めました。これは、前述のように、Vitessをサービスとして（いくつかのツールを使用して）販売しているだけであり、次の月に「信頼できる」サーバーレスデータベース。

背景

私の最初の質問は、PlanetScaleデータベースを参照整合性でスケーリングすることが不可能であると述べている理由でした。ドキュメントには次のように記載されています。

FOREIGN KEYの方法 制約はMySQL（または、むしろInnoDBストレージエンジン）に実装されており、オンラインDDL操作に干渉します。詳細については、このVitessブログ投稿をご覧ください。

単一のMySQLサーバースコープ、FOREIGN KEYに限定 データが大きくなり、複数のデータベースサーバーに分割されると、制約を維持することは不可能です。これは通常、機能的なパーティション分割/シャーディングおよび/または水平シャーディングを導入したときに発生します。

これにより、私は次のように考えるようになりました。FOREIGN KEY 制約は一般的にスケーラビリティに影響しますか？もしそうなら、どのように？

SQLテーブルの結合にはかなりのコストがかかることを理解することが重要だと思いますが、私の知る限り、参照整合性の影響はそれほど大きくありませんでしたか？さて、データ分析のようなことをしている場合、データを単一のテーブルにダンプしたいだけなので、明らかに参照整合性は必要ありませんが、PlanetScaleとVitessは大きなWebアプリケーションでの使用を誇っていますYouTubeなど。

これにより、なぜFOREIGN KEYを削除するのか混乱しました。 CockroachDBやSpannerなどのデータベースは、スケーラブルであると同時に参照整合性を維持するため、制約があります。

参照整合性とは何ですか、なぜそれが重要なのですか？

初めての方のために、基本から始めましょう。この投稿を読んでいるほとんどの人は、彼らが何について話しているのかについて公正な考えを持っていると思いますが、私は形式として説明します。簡単に言うと、FOREIGN KEY 制約は、列または列のセットを参照することにより、2つの異なるテーブル間の関係を作成するために使用できるデータベースキーです。参照整合性とは、すべてのキーのすべての値が有効であるデータベースの状態を指します。

なぜそれが重要なのですか？

それらが何であるかについて少し考えたので、2番目の部分にスキップしましょう：なぜそれらが重要なのですか？

参照整合性は、データベースに新しいエラーが発生するのを防ぐために重要です。これは、リレーショナルデータベースによって提供されることが多い機能であり、ユーザーまたはアプリケーションがデータベースに一貫性のないデータを入力するのを防ぎます。これにより、データ品質が向上し、開発が迅速化され、バグが大幅に減少し、アプリケーション全体の一貫性が保たれます。

なぜVitessにはないのですか？

したがって、Vitessが参照整合性をサポートできない理由を理解するには、データベースのアーキテクチャに飛び込む必要があります。 Vitessは、シャーディングされた非ACID SQLデータベースであり、真の分散ACIDSQLデータベースではありません。

今、あなたはそれらの用語が何であるか疑問に思っているに違いありません。それらを分解してみましょう。ACIDはAtomicity、Consistency、Isolation、Durabilityの頭字語です。

ここで、アトミック性とは、トランザクションの部分的な完了ではなく、完全に完了するか失敗するアクションを指します。整合性とは、データベースを有効な状態のままにするトランザクションを指します。分離とは、2つのトランザクションが互いに干渉することなく実行されることを意味し、耐久性とは、トランザクションの変更が保存されることを意味します。

シャードはデータベース内のデータの水平パーティションであり、各シャードは負荷を分散するために個別のデータベースサーバーインスタンスに保持されます。したがって、シャーディングされたデータベースを参照するときは、このようなことを言っています。さて、先に述べたように、Vitessはシャーディングされた非ACID SQLデータベースです。これは、基本的に、トランザクションのACIDプロパティを保証しないことを意味します。

なぜそれを落とすのですか？

問題は、スキーマが明確に定義されたMySQLデータベースがある場合に始まり、データベースにヒットする読み取りが多すぎるという問題でサービスが一般的になります。ここでほとんどの人が行うことは、頻繁に実行されるクエリのキャッシュを開始することですが、読み取りはもはやACIDicではありません。

読み取りが多すぎることに加えて、データベースへの書き込みが多すぎることは、多くの人が直面する可能性のある深刻な問題です。ポケットに火をつける準備ができているとしましょう。垂直方向にスケーリングして、RAM、16コアプロセッサ、および非常に高速なソリッドステートドライブを追加できます。

もちろん、SQLテーブル結合の複雑さが増すという問題がまだ残っているため、テーブル間の結合を回避するために非正規化を開始します。

少し前にPrismaMeetupで講演をしました。そこでは、リレーショナルデータベースの設計の基本について説明しました。ここで取り上げたトピックは非正規化でした。興味がある場合は、必ずこれを確認してください。

ただし、非正規化は基本的に、データベース内のテーブルに冗長データを追加するプロセスです。これにより、結合にCPUパワーを使用しなくなるため、ディスクスペースのコストのパフォーマンスが向上します。非正規化は読み取り速度を向上させますが、書き込みが遅くなることを理解することが重要です。

それでも、これらすべてにもかかわらず、データベースはまだ低速であるため、データベースの計算をクライアントに移動します。たとえば、UUIDの生成や日付の割り当てなどです。

このすべての後でも、クエリは依然として低速です。そのため、データベースの実体化と呼ばれるプロセスで、最もクエリされたデータの結果を準備しておきます。現在、読み取りは高速かもしれませんが、書き込みは日ごとに遅くなっています。現在の唯一の論理的な状況は、セカンダリインデックスを削除することです。

したがって、この時点で、データベースには

• キャッシュのためにACIDプロパティがありません
• 正規化されたスキーマはありません
• トリガーなし
• データベースの計算はありません
• セカンダリインデックスなし

これにより、企業はデータベースのスケーリングに問題を抱えていたため、VitessおよびNoSQLデータベースへの道が開かれました。設計方法では、トランザクションが複数の異なるシャードにまたがる場合、データの一貫性、つまりACIDプロパティを維持できませんでした。参照整合性とは、データが複数のシャードにまたがる場合の一貫性に関するものです。したがって、参照整合性は、データを適切にサポートできないことは理にかなっています。

FOREIGN KEYを使用せずに、NoSQLデータベースの構造を深く掘り下げることができます。 そのモデルを採用する際に直面する制約と問題ですが、それは別の投稿のトピックです。

Vitessだけでなく、他に選択肢がないため、参照整合性を回避することは、シャーディングされたデータベースの標準的な方法です。 ACIDモデルに関して、彼らのドキュメントには、原子性は保証されているが分離は保証されておらず、さらには次のように述べられています。

ACID分離の保証は非常に論争があり、コストが高くなります。デフォルトで提供すると、Vitessは最も一般的なユースケースでは実用的ではなくなります。

ACIDアイソレーションとは何かについて簡単に説明しましょう。これには、直列化可能性、コミットされた読み取り、コミットされていない読み取り、および繰り返し可能な読み取りを含む4つのレベルがあります（SQL-92標準による）。そうは言っても、FirebaseやMongoDBなどのいくつかのデータベースで使用されているものの、SQL標準ではないスナップショットアイソレーションなど、より多くのレベルのアイソレーションがあります。これにさらに興味がある場合は、この投稿を読むことをお勧めします。簡潔にするために、すべてのレベルの分離が何を意味するかについては説明しませんが、それについて詳しく知りたい場合は、MySQLドキュメントからこのページをチェックしてください。

ACID分離とは、データベーストランザクションがACIDicであることを指します。これは、操作が開発者の期待どおりに動作することを保証するため、重要です。 「ACIDの分離を保証することは非常に論争があり、コストが高い」と彼らが言ったときの意味はわかりませんが、ACIDの分離を保証することは、すべての製品に対して高いコストがかかることを意味する場合 、彼らは間違っています。いくつかの分散ACID準拠データベースは、最高レベルの分離（シリアル化可能なトランザクション）を備えながら、高速の読み取り/書き込み速度でパフォーマンスを発揮します。ただし、Vitessのコンテキストでは、複数のシャード間でトランザクションがどのレベルの分離にも対応できないため、間違いではありません。

結論

これらすべてで、あなたは疑問に思う必要があります：なぜ誰かがPlanetScaleまたはVitessを使いたいのですか？まあ、同じだろうか。多くの企業やウェブサイトで、その理由は、より良い選択肢がなかったときに彼らがVitessを選んだためです。記事の冒頭に行くと、2010年にどのように作成されたかに注目してください。参照整合性を備えたACID準拠のスケーラブルなデータベースを利用できるようになったので、これらの新しいデータベースに移行することが最善の利益になります。すでにそうし始めました！テクノロジーは急速に変化しており、データベースを最新の状態に保つことは、あらゆるアプリケーションの重要なコンポーネントです。