DevConf：高負荷のための有望なデータベース

来週、DevConf 2018が開催されます！ 昨年、Yuri Nasretdinovは、高負荷用の有望なストレージシステムの興味深いレビューを実施しました。 レポートのあるビデオは、レポートページでご覧いただけます 。 そして、habr-readerのために、簡単な言い直しを提供します。







最初に、高負荷プロジェクトのテクノロジーの選択にアプローチする方法を説明します。

• まず第一に、それがどのように機能するかを理解する必要があります。 長所だけでなく、弱点もあります。
• 監視およびバックアップ方法の知識。 これに適したツールがなければ、このテクノロジーは実稼働で使用するには早すぎます。
• 遅かれ早かれ、システムは「落下」し（これは通常の通常の状況です）、この場合に何をすべきかを知る必要があります。

成功した技術の例を挙げます。







MySQLとMongoDBは、非常にシンプルで、オークのように機能し、明らかに機能し、明らかな欠陥があるソリューションから始まりました。

タランツール

Tarantoolはどのユーザーケース用に作成されましたか？ ソーシャルネットワークとユーザーデータが100のmysqlサーバーに分散していると想像してください。 同時に、ユーザーはユーザーIDによって共有されます。 ユーザーは自分の電子メールを入力し、ログインしたいと考えています。







明らかな方法は、電子メールでユーザーをチャードすることです。 しかし、人々は彼がログインしたい電話番号も持っています。 したがって、2番目の明白な解決策は、通信メール=> userId、電話=> userIdを含む高速の特定のデータベースであり、そのようなデータベースは永続的であることが望ましい。 しかし、当時はそのようなデータベースはありませんでした。当時の選択肢の1つは、これらすべてをmemkeshに入れることでした。 しかし、userIdを検索するために新しいフィールドを追加する操作は非常に難しいと仮定します。 memkeshには多くの問題がありますが、少なくとも多くの読み取りと書き込みに耐えることができます。



だから、タランツール。 すべてのデータをメモリに保存します。 そして、同時に、ディスク上。 開発者によると、プロセッサコアあたり1秒あたり100万のリクエストに耐えます。 mail.ruで開発されています。 Tarantool開発者の1人であるKonstantin Osipovは、MySQLの開発に使用していました。







Tarantoolのリクエスト処理プロセスには、パイプラインアーキテクチャがあります。 多くのクライアントがTarantoolサーバーを要求します。 これらの要求はすべて、I / Oスレッドのキューに入れられます。 その後、彼はいくつかの間隔でそれらを実行に渡します。 したがって、実行スレッドのロックはかなり短い時間続きます。







個別に言及する価値があるのは永続性です。 誰かが永続的にredisを使用する場合、フォークを作成するプロセスが進行している瞬間に、大根がかなり長い期間「固着」していることに気付くでしょう。 Tarantoolには異なるモデルがあります。 バージョン1.6.7より前は、共有領域にメモリの一部を保持しており、フォーク中はコピーされません。 そして、フォークされた子がディスクに書き込まれている間、親はこのメモリの一部に触れることができないことを知っています。 バージョン1.6.7以降、彼らはフォークを完全に放棄しました。 それらは、ユーザー空間の仮想メモリメカニズムをサポートしていると言えます。 ユーザー空間のメモリアドレス変換。 フォークプロセスを作成する代わりに、ユーザー空間のメモリスナップショットを実行して、一貫したスナップショットをディスクに書き込むスレッドが作成されます。

Tarantoolが適している状況：

• 多数の読み取り/書き込みクライアントがあります。
• 多くの浅い読み取り/書き込み。
• 何らかの中央ストレージが必要になり、ワーキングセットがメモリに格納される場合。 Tarantoolはまだシャーディングをサポートしていません。
• ストアドプロシージャを記述したい。 TarantoolはLuaでそれらをサポートしています。
• 承認、セッション、カウンター。

使用しない場合：

• 必要に応じて：自動シャーディングとフェイルオーバー、Raft / Paxos、長いトランザクション。
• 少数の顧客と最小遅延要件。 パイプライン化されたアーキテクチャにより、遅延は可能な最小値より大きくなります。
• ワーキングセットがメモリに収まりません。 Kostya OsipovはTarantoolの新しいVinylエンジンについて話しましたが、最初に確認することをお勧めします。
• 私の個人的な意見：Tarantoolは分析タスクには適していません。 彼はすべてをメモリに保持していますが、これらのタスクに必要な方法を保持していません。

クリックハウス

分析のためだけにYandexによって作成されました。 Yandex.Analyticsなどのシステムでは、次のデータベースが必要でした。

• 効率的で線形にスケーラブル。
• リアルタイム分析。
• 無料でオープンソース。

当時、3つの基準をすべて満たす製品はありませんでした。 可能な解決策：

• MySQL（MyISAM）-高速書き込み、低速読み取り
• Vertica、Exasol-有料
• Hadoop-書き込みは機能しますが、読み取りはリアルタイムではありません。

Yandexは最初にMySQLを使用しました。 しかし、彼はClickHouseを作成しました。これは、列データを格納する分散分析DBMSで、HDD（SSDは非常に高価です）に最適化され、非常に高速です（1秒あたり最大10億レコードをスキャンできます）。 Yandexの生産で既にテストされています。 ClickHouseは、データの挿入とクエリのみをサポートします。 削除と編集はありません。







データは毎月のパーティションに保存されます。 各パーティションでは、主キーを増やすことでデータが順序付けられます。 この場合の「主キー」は、一意性が保証されていないため、あまり正確ではありません。







主キーですばやく検索できるようにするために、ClickHouseは「serif」ファイルを使用します。このファイルでは、主キーの値を使用して特定の数のエントリでセリフが作成され、その場所に配置されます。 これにより、少数のディスク操作でさまざまな主キーでクエリを実行できます。







挿入は次のように行われます。 データは一時パーティションに書き込まれ、ソートされます。 その後、バックグラウンドプロセスで、記録がしばらく停止すると、これらのパーティションがマージされます。

ClickHouseの機能：

• JOINによって制限されるSQL。
• レプリケーションとクラスターが機能します。 サポートされていますが、試してみる必要があります。
• 17（おそらくそれ以上）実行アルゴリズムごとのグループ。
• マテリアライズドビュー、グローバルジョイン。
• サンプルのサンプリング。 データの一部のみを最適に読み取ることができる場合。 たとえば、Yandex.Analyticsの特定のユーザーのみ。

使用シナリオ：

• リアルタイム分析のタスク。
• 時系列-github.com/yandex/graphouse
• ClickHouseが非常に迅速に集約できる生データのストレージ。 インプレッション、クリック、ログなど

使用しない場合：

• OLTPタスク（トランザクションなし）
• お金を扱う（取引なし）
• 集計データの保存（意味なし）
• マップ/タスクの削減（それらの多くはSQLを使用して完全に解決されます）
• 全文検索（意図しない）

ゴキブリ

作成の前提条件は、Tarantoolの場合と同じです。 サーバー全体に広がるユーザーベースがあります。 そして、たとえばメールや電話で検索する必要があります。 ただし、この例のTarantoolがデータベースシャードに対する高レベルのインデックスとして機能する場合、CockroachDBはすべてを自宅に保存することをお勧めします。

CockroachDBの前に考えられる解決策：



Google Cloud Spanner

承認者+手動シャーディング（既にTarantoolで見たように）

MongoDB、Cassandra-分散ユニークインデックスをサポートしていません。



CockroachDBはもともと分散Key-Valueストレージとして作成されましたが、現在の現実では、新しいKey-Valueデータベースを必要とする人はほとんどいません。 誰もがSQLを望んでいます。 SQL、JOIN、トランザクション、ACID、一意のインデックス、自動シャーディングをサポートしています。 Google Spannerによって作成されました。 Goで書かれています。 ほぼ初めて、Jepsenテストに合格しました。 そして、すでにBaiduの生産で使用されています。



それでは、リレーショナルモデルはKey-Valueストレージにどのように適合しますか？ これは手動で簡単に配置できます。 非常に簡略化したバージョンを提供します。 CockroachDBでは、すべてが少し複雑です。 キーは非常に単純です-テーブル名/プライマリキー値/フィールド名。







セカンダリインデックスも非常に簡単です。 インデックスの名前を持つ別のキー。 主キーの値とともに、一意でないインデックスの場合。











データはかなり簡単な方法で保存されますが、私には非常に正しいようです。 グローバルにソートされたKey-Valueマップは領域に分割され、データベースは約64 MBを維持しようとします。 これらの各リージョンは複数のノードに複製され、リージョンのこれらのノードの1つはRaftリーダーです。 レコード全体（おそらく読み取りも）に入ります。 ここで、いくつかのノードが落ちたと想像してください。 Raftを使用すると、各地域の新しいリーダーをすばやく選択できます。 したがって、書き込みと読み取りの両方が使用可能になります。



主な機能の1つは、分散トランザクションのサポートです。 複数のノードでデータをトランザクション的に変更する必要がある場合。 これらはこのように実装されます。 トランザクションのリストを含むシステムテーブルがあります。 キーの値を変更すると、トランザクション番号を持つキーが近くに追加されます。 このようなキーを読み取ると、トランザクションテーブルはコミットされているかどうかを確認し、目的の値が選択されます。 成功すると、値は最終値に置き換えられます。 失敗したトランザクションは、ガベージコレクターによってクリアされます。



将来、CockroachDBは大規模プロジェクトのメインデータベースとして使用される可能性があります。 1.0リリースが最近リリースされて以来、それは時期尚早です。



使用しない場合：



CockroachDB分散トランザクションアルゴリズムの説明からわかるように、このプロセスは高速ではありません。 プロジェクトで低レイテンシまたは毎秒高いクエリが必要な場合-価値はありません。 録音も最速ではありません。

厳密な一貫性が必要ない場合。 分散データベースの場合、これは非常に重要な要素です。 条件付きで、あるユーザーから別のユーザーにメッセージを送信する必要がある場合、メッセージの作成者のサーバーと、このメッセージの送信先のサーバーにメッセージに関する記録が表示されます。これをアトミックに実行することをお勧めします。



結論として、各ツールは賢明に選択する必要があり、解決するタスクとその制限を明確に理解する必要があります。 私の言うことを聞いて自分ですべてをチェックしないでください。



今年もStorageの興味深いセクションです。 あなたの経験を共有してください。 Habrachitateli 割引 。