カサンドラ。 Oracleしか知らなくても死なない方法

おい、ハブル。

私の名前はミーシャ・ブトリモフです。カサンドラについて少し話したいと思います。 私の話は、NoSQL データベースに触れたことがない人にとって役立つでしょう。NoSQL データベースには、知っておくべき実装機能と落とし穴がたくさんあります。 Oracle やその他のリレーショナル データベース以外のものを見たことがなければ、これらのデータベースがあなたの命を救ってくれるでしょう。

カサンドラの何がそんなに良いのですか？ これは、単一障害点がなく、適切に拡張できるように設計された NoSQL データベースです。 データベースに数テラバイトを追加する必要がある場合は、リングにノードを追加するだけです。 別のデータセンターに拡張しますか? クラスターにノードを追加します。 処理された RPS を増加しますか? クラスターにノードを追加します。 逆方向にも機能します。

彼女が他に得意なことは何ですか? たくさんのリクエストに対応することです。 でも、たくさんってどれくらいですか？ 10 秒あたり 20、30、40、100 のリクエストはそれほど多くありません。 録画用のリクエストも 2 秒あたり XNUMX 万件あります。 XNUMX 秒あたり XNUMX 万件のリクエストを保持しているという企業もあります。 おそらく彼らはそれを信じなければならないでしょう。

そして原則として、Cassandra にはリレーショナル データとの大きな違いが XNUMX つあります。それは、リレーショナル データとはまったく似ていません。 そして、これは覚えておくことが非常に重要です。

同じように見えるものすべてが同じように機能するわけではない

あるとき同僚が私のところに来て、こう尋ねました。「これは CQL Cassandra クエリ言語です。これには select ステートメント、where、and があります。 手紙を書いてもうまくいきません。 なぜ？"。 Cassandra をリレーショナル データベースのように扱うことは、暴力的自殺に最適な方法です。 私はそれを宣伝しているのではなく、ロシアでは禁止されています。 間違ったものを設計してしまうだけです。

たとえば、ある顧客が私たちに来て、次のように言います。「テレビ シリーズのデータ​​ベース、またはレシピ ディレクトリのデータベースを構築しましょう。 そこには料理やテレビシリーズや出演者のリストが掲載される予定です。」 私たちは喜んで「行きましょう！」と言います。 XNUMX バイトといくつかの署名を送信するだけで完了です。すべてが非常に迅速かつ確実に機能します。 そして、顧客が来て、主婦も逆の問題を解決している、つまり商品リストがあり、どんな料理を作りたいのか知りたいと言うまでは、すべてがうまくいきます。 あなたが死んでいる。

これは、Cassandra がハイブリッド データベースであるためです。キー値を提供し、同時に幅の広い列にデータを保存します。 Java または Kotlin では、次のように記述できます。

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

つまり、ソートされたマップも含まれるマップです。 このマップの最初のキーは行キーまたはパーティション キー、つまりパーティション キーです。 XNUMX 番目のキーは、すでにソートされたマップのキーであり、クラスタリング キーです。

データベースの分散を説明するために、XNUMX つのノードを描いてみましょう。 次に、データをノードに分解する方法を理解する必要があります。 なぜなら、すべてを XNUMX つに詰め込んだ場合 (ちなみに、XNUMX、XNUMX、XNUMX つは好きなだけあります)、これは実際には分散に関するものではありません。 したがって、数値を返す数学関数が必要です。 ある範囲に収まる単なる数値、long int です。 そして、XNUMX つのノードが XNUMX つの範囲を担当し、XNUMX 番目のノードが XNUMX 番目の範囲を担当し、n 番目のノードが n 番目の範囲を担当します。

この数値はハッシュ関数を使用して取得され、パーティション キーと呼ばれるものに適用されます。 これは主キー ディレクティブで指定された列であり、マップの最初で最も基本的なキーとなる列です。 どのノードがどのデータを受信するかが決まります。 Cassandra では、SQL とほぼ同じ構文でテーブルが作成されます。

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

この場合の主キーは XNUMX つの列で構成され、パーティション化キーでもあります。

ユーザーのパフォーマンスはどうなるでしょうか? 一部は XNUMX つのノードに送信され、一部は別のノードに送信され、一部は XNUMX 番目のノードに送信されます。 結果は、通常のハッシュ テーブル (マップとも呼ばれ、Python では辞書とも呼ばれます)、またはすべての値を読み取り、キーによって読み書きできる単純なキー値構造になります。

選択: フィルタリングの許可がフルスキャンになる場合、または実行しないこと

select ステートメントを書いてみましょう。 select * from users where, userid = 。 Oracle のように、select を書き、条件を指定するとすべてが機能し、ユーザーはそれを理解します。 しかし、たとえば特定の生まれ年のユーザーを選択すると、Cassandra はリクエストを満たせないと不平を言います。 彼女は、誕生年に関するデータをどのように配布するかについてまったく知らないため、キーとして示されている列は XNUMX つだけです。 すると彼女はこう言いました。「わかりました、このリクエストはまだお応えできます。 許可フィルタリングを追加します。」 ディレクティブを追加すると、すべてが機能します。 そしてこの瞬間、恐ろしいことが起こります。

テストデータを実行すると、すべて問題ありません。 そして、たとえば 4 万件のレコードがある運用環境でクエリを実行すると、すべてがうまくいきません。 フィルタリングの許可は、Cassandra がすべてのノード、すべてのデータセンター (このクラスターに多数のデータセンターがある場合) からこのテーブルのすべてのデータを収集し、その後でのみフィルター処理できるようにするディレクティブであるためです。 これはフル スキャンの類似物ですが、これを喜ぶ人はほとんどいません。

ID によるユーザーのみが必要な場合は、これで問題ありません。 ただし、場合によっては、他のクエリを作成したり、選択に他の制限を課したりする必要があります。 したがって、これはすべてパーティション化キーを持つマップですが、その内部にはソートされたマップがあることを覚えておいてください。

そして、彼女はクラスタリング キーと呼ばれるキーも持っています。 このキーは、選択した列で構成されており、これを利用して Cassandra はデータがどのように物理的に並べ替えられ、各ノードに配置されるかを理解します。 つまり、一部のパーティション キーの場合、クラスタリング キーは、データをこのツリーにプッシュする方法と、データがそこでどの場所に配置されるかを正確に示します。

これは実際にはツリーであり、そこでコンパレーターが呼び出されるだけで、オブジェクトの形式で特定の列のセットが渡され、列のリストとしても指定されます。

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

主キー ディレクティブに注意してください。その最初の引数 (この例では年) は常にパーティション キーです。 XNUMX つ以上の列で構成されていても構いません。 複数の列がある場合は、これが主キーであり、その背後にある他のすべての列がクラスタリング キーであることを言語プリプロセッサが理解できるように、再度括弧内で削除する必要があります。 この場合、それらは出現する順序でコンパレータに送信されます。 つまり、最初の列はより重要であり、XNUMX 番目の列はより重要ではない、というようになります。 たとえば、データ クラスのフィールドの書き方は同じです。フィールドをリストし、それらに対してどのフィールドが大きいか、どのフィールドが小さいかを記述します。 Cassandra では、これらは相対的に言えば、データ クラスのフィールドであり、そのフィールド用に書かれた同等のものが適用されます。

ソートを設定し、制限を課します

ソート順序 (降順、昇順など) はキーの作成と同時に設定され、後で変更することはできないことに注意してください。 データの並べ替え方法と保存方法を物理的に決定します。 クラスタリング キーまたは並べ替え順序を変更する必要がある場合は、新しいテーブルを作成し、そこにデータを転送する必要があります。 これは既存のものでは機能しません。

テーブルにユーザーを記入すると、最初は誕生年ごとにリングに分類され、次に給与とユーザー ID ごとに各ノードの内側に分類されることがわかりました。 制限を課すことで選択できるようになりました。

私たちの働く人が再び現れます where, andそしてユーザーを獲得し、再びすべてがうまくいきます。 しかし、クラスタリング キーの一部だけを使用し、それより重要度の低いキーを使用しようとすると、Cassandra はすぐに、このオブジェクト (null コンパレータ用のフィールドとこのフィールドを持つ) がマップ内でどこにあるか見つからないと文句を言います。それはちょうど設定されたところです - 彼が横たわっている場所。 このノードからすべてのデータを再度取得してフィルタリングする必要があります。 これはノード内のフル スキャンに似ていますが、これは悪いものです。

状況が不明瞭な場合は、新しいテーブルを作成します

ID、年齢、給与などでユーザーをターゲティングできるようにしたい場合は、どうすればよいでしょうか? 何もない。 テーブルを 10 つ使用するだけです。 XNUMX つの異なる方法でユーザーにアプローチする必要がある場合、テーブルが XNUMX つ存在します。 ネジのスペースを節約する時代は終わりました。 これは最も安価なリソースです。 ユーザーにとって不利益となる可能性がある応答時間に比べて、コストがはるかに低くなります。 ユーザーにとっては、XNUMX 分で何かを受け取るよりも、XNUMX 秒で何かを受け取る方がはるかに快適です。

不必要なスペースと非正規化データを犠牲にして、適切に拡張し、確実に動作する能力を獲得します。 結局のところ、実際には、それぞれが XNUMX つのノードを持つ XNUMX つのデータセンターで構成されるクラスターは、許容レベルのデータ保存 (何も失われていない場合) を備えていれば、XNUMX つのデータセンターが停止しても完全に生き残ることができます。 そして残りの XNUMX つのそれぞれにさらに XNUMX つのノードがあります。 そしてこの後初めて問題が始まります。 これはかなり優れた冗長性であり、SSD ドライブとプロセッサをいくつか追加する価値があります。 したがって、リレーションシップや外部キーがない SQL ではない Cassandra を使用するには、簡単なルールを知る必要があります。

ご要望に応じてあらゆるものをデザインさせていただきます。 重要なのはデータではなく、アプリケーションがデータをどのように扱うかです。 異なるデータを異なる方法で受信する必要がある場合、または同じデータを異なる方法で受信する必要がある場合は、アプリケーションにとって便利な方法で受信する必要があります。 そうしないと、フル スキャンに失敗し、Cassandra は何の利点も与えません。

データの非正規化は標準です。 私たちは標準形式のことを忘れており、リレーショナル データベースはもうありません。 何かを100回置くと、100回横になります。 それでも止めるよりは安いです。

正常に分散されるようにパーティション化するキーを選択します。 キーのハッシュが 5 つの狭い範囲に収まることは望ましくありません。 つまり、上記の例の生まれ年は悪い例です。 より正確に言うと、ユーザーが生まれ年によって正規に分布している場合は良好ですが、XNUMX 年生について話している場合は不良であり、そこでの分割はあまり適切ではありません。

ソートは、クラスタリング キーの作成段階で XNUMX 回選択されます。 変更する必要がある場合は、別のキーでテーブルを更新する必要があります。

そして最も重要なことは、同じデータを 100 の異なる方法で取得する必要がある場合、100 の異なるテーブルが存在することになります。

出所： habr.com