必要条件
データベースの主な要件は、情報を失わないことです。 驚くべきことに、多くのデータベースはこの重要な要件を満たしていません。長年にわたってテストされたソリューションでさえ、単純なシナリオでは失敗します（例： one 、 two ）。 メンテナンスのためにサーバーのシャットダウン中に冗長性を維持するため、少なくとも3つのサーバーに情報を保存する必要があります。
別のデータベース要件は、最新のハードウェアを使用できることです。 10年後、プロセッサのコア数は100を超え、RAMはチップ自体に統合され、フラッシュメモリのコストは大幅に減少します。 10年後に変わらないのは光の速さです。 ヨーロッパからアメリカへのネットワークパケットは約100ミリ秒（RTT）で、この時間は理論上の限界にかなり近づいています。 そのため、将来のデータセンターは強力なナンバークラッシャーのクラスターであり、内部には高速ネットワークがあり、世界中で高遅延リンクで接続されています。 最新のデータベースは、データセンター内の同期レプリケーションとデータセンター間の非同期レプリケーションをサポートする必要があります。
分析では、データベースプロバイダー自体のステートメント、独立テストの結果（利用可能な場合）、および実際の使用例（ highscalabitility.comに多くの例があります）に焦点を当てました。 ネットワーク経由の自動レプリケーションがないため、組み込みデータベースを考慮から除外しました。
商用SQLデータベース
このセグメントの最も有名な代表者は、Microsoft SQL ServerとOracle Databaseです。 これらは優れた、実績のある製品であり、最新の技術革新（インメモリテーブルとカラムストア）により、最新の鉄の機能を最大限に活用できます。 両方のデータベースはクラスタリングテクノロジーをサポートし、両方とも豊富なSQL機能を備えています（ただし、それぞれに独自の方言があります）。
両方のデータベースは、「プロセッサコアあたりの価格」モデルに従ってライセンスを付与でき、価格はユーザー数に依存しません。 負荷を分析し、成長予測を行った後、コストが不均衡に高くなると考え、代替案を検討することにしました。
オープンソースのSQLデータベース
このグループの最も有名な代表者であるMySQLとPostgreSQLは、ほとんどのタスクに最適です。 どちらもクラスタリングをサポートしており、大規模プロジェクトでの使用例や、大規模プロジェクトでのプロジェクト間の 移行の 例もあります 。 おそらく、私たちにとっての主な欠点は、手動シャーディングであり、その結果、自動クラスターリバランスの欠如です。
このシステムでは、組織（ユーザーグループ）をシャーディングキーとして選択するのが自然です。これは、クラスター内のどのサーバーでデータ要素を保存するかを決定するパラメーターです。 ただし、一部の組織は小規模のままです。1〜2人のユーザーがいる一方で、他の組織はサービスで働いているため、数万人のユーザーに成長します。 このようなキーの負荷分散は、遅かれ早かれ、クラスター内の一部のサーバーのオーバーフローと、他のサーバーのアンロードにつながります。 この時点で、リバランスが必要です。つまり、クラスターノードを2つに分割します。 この作業は、信頼性を損なうことなく、稼働中の24時間365日のクラスターで行うことは困難です。
NoSQLデータベース
2000年代に流行したNoSQL運動は現在、成熟期を迎えています。 すべてのプレイヤーはよく知られており、独自のサポーターを持っています。 インターネットの急速な成長とともに作成されたこれらのデータベースは、関連するタスク、たとえば数十億件の非構造化文書の保存と処理のために開発されました。 多くのソリューションは、「結果整合性」を宣言します。これは、CAP定理の厳密な「C」を拒否することを意味します。 顧客データを失うことはできないため、このような妥協は容認できません。
Cassandraなど、一部のNoSQLソリューションは可用性（「A」）を低下させ、「CP」を宣言します。 これはタスクに適していますが、行レベルの一貫性の欠如に驚きました。同じ行の異なる列で2つの同時記録を行うと、データが破損する可能性があります。 また、データベースからこのようなレベルのグリッチが発生することは想定していませんが、この問題の回避策（たとえば、文字列全体を変更するなど）を見つけることができ、Cassandraに注目しました。
クラウドデータベース
このカテゴリに関する別のレビューを書くことができます。 メインのPaaSプレーヤー（Amazon、Google、Microsoft）にはそれぞれ、構造化データを保存するための6〜8種類のオファー（およびBLOBを保存するためのより多くのサービス）があります。 あらゆるタイプの負荷に対して、ターンキーソリューションを選択できます。
個人データの保存を理由にクラウドストレージを拒否しました。 当社の顧客はさまざまな国にあり、単一のサービスが世界各国の法律に従って個人データの保存を提供しているわけではありません。 もう1つの理由は、特定のベンダーに強く依存していることです。ベンダーのテクノロジーを使用してハードウェアに展開することはできません。 （価格の上昇または信頼性の低下により）ベンダーから離れたいという要望がある場合、移行プロジェクトは非常に長くなる可能性があります。 DropboxがAmazonクラウドから独自のストレージに移行するのに2年以上かかりました 。
NewSQLデータベース
SQL言語の人気とハードウェアの開発により、SQLクエリ言語を備えた分散データベースという新しい動きが生まれました。 中でも、Google Spannerは際立っています。これは、すべてのトランザクションを記録するグローバルな順序である線形性を保証します。 このような問題を世界規模で解決するには、世界中のデータベースサーバーで時刻を同期する必要があります。 Googleはこれに原子時計を使用し、バックアップにはGPS受信機を使用します。
しかし、普通の人間にとって、原子時計は依然として贅沢品であるため、Spannerの著者は、トランザクションの順序についてはわずかに低い保証で、ほとんどのアプリケーションに十分な同様のデータベースを構築しました。 このデータベースはCockroachDB（英語の「ゴキブリ」から）と呼ばれ、その名前は鉄の故障やデータセンター間の接続の場合のクラスターの存続可能性を表します。 CockroachDB は 、ノードが失われたときに、本格的な分散トランザクションと自動クラスターリバランシングを提供します 。これは、通常のSQLクエリ言語と相まって、Cassandraと比較して有利です。 欠点の中でも、フルテキストインデックスの欠如とソリューションの比較の若さは注目に値します。
コードをデータに移動する
多くの場合、ビジネスロジックはアプリケーションサーバー上にあり、クライアントリクエストを受信し、その処理のためにデータをデータベースサーバーに転送します。 大量のデータがある場合、データベースサーバーからネットワークを介してデータを転送するには、かなりの時間がかかります。 これにより、データベース内のすべての処理と、Apache Hadoopなどのテクノロジーを転送して、そのようなタスクをプログラムできるようになります。 （通常のリレーショナルデータベースでは、ストアドプロシージャの内部にクエリロジックを記述することもできますが、多くの開発者は、デバッグに不便であるため、クエリロジックを好みません。）
最近、ほぼリアルタイムのOLTPロード用にアプリケーションサーバーとデータベースを組み合わせるというアイデアが人気を集めており、対応するテクノロジ（Tarantoolなど）が登場しています。 「協調的マルチタスク」をロックしないアーキテクチャは非常に魅力的ですが、そのようなアプリケーションの作成はより困難です。 Luaプログラミング言語を停止します-ゲーム開発者の間で人気がありますが、閉じられており、ゆっくりと開発されており、私たちのチームにはそれを実際に使用した経験がありません。
おわりに
今日、CockroachDBが最も有望なオプションであると考えています。 会社のオープン性（データベースのソースコードはgithubに投稿されています）とドキュメントの品質（低レベルのデータストレージ形式までのアーキテクチャおよびその他の重要な決定がサイトに公開されています）に感心しています。 私たちは製品の進化を追っており、本番環境でこのデータベースを使用している同僚と意見交換できます。
それまでの間、パイロットプロジェクトを開始し、戦闘モードでの使用経験を共有します。