データ、安定性、NoSQL への信頼を失わずに Cassandra の目を見つめる方法

人生のすべてのことは、少なくとも一度は試してみる価値があると言われます。 リレーショナル DBMS の操作に慣れている場合は、少なくとも一般的な開発において、実際に NoSQL に慣れる価値があります。 現在、このテクノロジーの急速な発展により、このトピックに関しては多くの対立する意見や激しい議論があり、特に関心が高まっています。
これらすべての論争の本質を掘り下げてみると、それらは間違ったアプローチによって生じていることがわかります。 NoSQL データベースを必要な場所で正確に使用するユーザーは満足し、このソリューションからすべての利点を享受できます。 そして、このテクノロジーがまったく適用できない万能薬としてこのテクノロジーに依存している実験者は、大きなメリットが得られずにリレーショナル データベースの長所を失って失望しています。

Cassandra DBMS に基づくソリューションの実装における私たちの経験についてお話します。私たちが直面しなければならなかったこと、困難な状況からどのように抜け出したか、NoSQL を使用することでメリットが得られたかどうか、追加の努力や資金をどこに投資する必要があったのかなどです。 。
最初のタスクは、通話を何らかのストレージに記録するシステムを構築することです。

システムの動作原理は次のとおりです。 入力には、呼び出しの構造を記述する特定の構造を持つファイルが含まれます。 次に、アプリケーションは、この構造が適切な列に格納されていることを確認します。 将来的には、保存された通話は、加入者のトラフィック消費に関する情報 (料金、通話、残高履歴) を表示するために使用されます。

彼らが Cassandra を選んだ理由は非常に明らかです。彼女はマシンガンのように書き、簡単にスケーラブルで、フォールトトレラントです。

これが経験が私たちに与えてくれたものです

はい、ノードの障害は悲劇ではありません。 これが Cassandra の耐障害性の本質です。 しかし ノードは生きていても、同時にパフォーマンスが低下し始める可能性があります。 結局のところ、これはクラスター全体のパフォーマンスに直ちに影響を与えます。

Cassandra は、Oracle が制約であなたを救ってくれたように、あなたを保護しません。。 そして、アプリケーションの作成者がこれを事前に理解していなかった場合、Cassandra に到着したダブルはオリジナルよりも悪くありません。 到着しましたら、入れていきます。

IB は、そのままの状態で無料の Cassandra を強く嫌っていました。 ユーザーアクションのログや権利の区別はありません。 通話に関する情報は個人データとみなされます。つまり、何らかの方法でその情報を要求/変更しようとする試みはすべて、その後の監査の可能性を考慮して記録する必要があります。 また、ユーザーごとに異なるレベルで権限を分離する必要があることにも注意する必要があります。 単純な運用エンジニアと、キースペース全体を自由に削除できるスーパー管理者は、役割、責任、権限が異なります。 このようなアクセス権の差別化がないと、ANY 整合性レベルを使用する場合よりも早く、データの価値と整合性が即座に疑問視されることになります。

通話にはさまざまな条件に対する本格的な分析と定期的なサンプリングの両方が必要であることを考慮していませんでした。 選択されたレコードは削除され、書き換えられることになっているため (タスクの一部として、データが最初に誤ってループに入ったときにデータを更新するプロセスをサポートする必要があります)、ここでは Cassandra は私たちの友人ではありません。 Cassandra は貯金箱のようなものです。物を入れるのには便利ですが、数を数えることはできません。

テストゾーンへのデータ転送中に問題が発生しました (テストでは 5 ノード、プロムでは 20 ノード)。 この場合、ダンプは使用できません。

Cassandra に書き込むアプリケーションのデータ スキーマの更新に関する問題。 ロールバックにより大量のトゥームストーンが生成され、予期せぬ方法で生産性が低下する可能性があります。。 Cassandra は記録用に最適化されており、書き込み前にあまり考えず、既存のデータに対する操作もすべて記録になります。 つまり、不要なものを削除することで、さらに多くのレコードが作成され、そのうちの一部のみに墓石が付けられることになります。

挿入時にタイムアウトが発生します。 カサンドラは録音では美しいですが、 時々、入ってくる流れが彼女を著しく困惑させることがあります。 これは、アプリケーションが何らかの理由で挿入できない複数のレコードを循環し始めると発生します。 そして、gc.log、遅いクエリのシステム ログ、デバッグ ログ、保留中の圧縮に関するメトリクスを監視する本物の DBA が必要になります。

クラスター内の複数のデータセンター。 どこから読んでどこから書くのか？
おそらく読み取りと書き込みに分かれるのでしょうか？ もしそうなら、書き込みまたは読み取りのためにアプリケーションの近くに DC があるべきでしょうか? また、間違った一貫性レベルを選択すると、本当のスプリット ブレインが発生することになるのではないでしょうか? たくさんの疑問、未知の設定、実際にいじってみたい可能性がたくさんあります。

どうやって決めたか

ノードの沈下を防ぐために、SWAP は無効になりました。 そして、メモリが不足している場合、ノードはダウンし、大きな gc 一時停止が発生することはありません。

したがって、データベース内のロジックには依存しなくなりました。 アプリケーション開発者は自らを再訓練し、独自のコードで積極的に予防策を講じ始めています。 データの保存と処理を理想的に明確に分離します。

DataStax からサポートを購入しました。 ボックス化された Cassandra の開発はすでに終了しています (最後のコミットは 2018 年 XNUMX 月でした)。 同時に、Datastax は優れたサービスと、既存の IP ソリューションを修正および適応させた多数のソリューションを提供します。

Cassandra は選択クエリにはあまり便利ではないことにも注意してください。 もちろん、CQL はユーザーにとって (Trift と比較して) 大きな進歩です。 しかし、このような便利な結合、任意のフィールドによる自由なフィルタリング、クエリ最適化機能に慣れている部門全体があり、これらの部門が苦情や事故の解決に取り組んでいる場合、Cassandra のソリューションはそれらの部門にとって敵対的で愚かに見えるでしょう。 そして、私たちは同僚がどのようにサンプルを作成するかを決定し始めました。

XNUMX つのオプションを検討しました。最初のオプションでは、呼び出しを C* だけでなく、アーカイブされた Oracle データベースにも書きます。 ただし、C* とは異なり、このデータベースには当月の通話のみが保存されます (再請求の場合に十分な通話ストレージの深さ)。 ここで、次の問題がすぐにわかりました: 同期的に書くと、高速挿入に関連する C* の利点がすべて失われます; 非同期的に書くと、必要なすべての呼び出しが Oracle に到達するという保証はまったくありません。 プラスの点が XNUMX つありましたが、大きな点は、操作には使い慣れた同じ PL/SQL Developer が残っていること、つまり、実質的に「Facade」パターンを実装していることです。 C* からの呼び出しをアンロードし、Oracle の対応するテーブルからエンリッチメント用のデータを取得し、結果のサンプルを結合して結果を取得するメカニズムを実装します。その後、その結果を何らかの方法で使用します (ロールバック、繰り返し、分析、賞賛)。 短所: プロセスは非常に複数のステップからなり、さらに、運用担当者用のインターフェースがありません。

結局、私たちは XNUMX 番目の選択肢に落ち着きました。 Apache Spark を使用して、さまざまな jar からサンプリングしました。 このメカニズムの本質は Java コードにまとめられており、指定されたキー (サブスクライバー、呼び出し時間 - セクション キー) を使用して、C* からデータを抽出するだけでなく、他のデータベースから強化に必要なデータも抽出します。 その後、メモリ内でそれらを結合し、結果のテーブルに結果を表示します。 火花の上にクモの巣のような面を描いてみたところ、非常に使いやすいものになりました。

工業用テストデータの更新の問題を解決する際、私たちは再びいくつかの解決策を検討しました。 どちらも Sstloader を介して転送され、テスト ゾーン内のクラスターを XNUMX つの部分に分割するオプションがあり、それぞれがプロモーション用のクラスターと同じクラスターに交互に属するため、Sstloader によって駆動されます。 テストを更新するとき、それらを交換することが計画されました。テストで動作した部分はクリアされて運用環境に入り、もう一方は個別にデータの処理を開始します。 しかし、もう一度考えた結果、転送する価値のあるデータをより合理的に評価し、呼び出し自体はテスト用に一貫性のないエンティティであり、必要に応じてすぐに生成され、プロモーション データ セットには転送する価値がないことがわかりました。テスト。 移動する価値のあるストレージ オブジェクトがいくつかありますが、これらは文字通り XNUMX つのテーブルであり、それほど重いものではありません。 したがって、私たちは 解決策として、Spark が再び役に立ちました。その助けを借りて、テーブル間でデータを転送するためのスクリプト prom-test を作成し、積極的に使用し始めました。

現在の展開ポリシーでは、ロールバックなしで作業できます。 プロモーションの前に必須のテスト実行があり、失敗してもそれほど高くはありません。 失敗した場合には、いつでもケーススペースを削除して、スキーム全体を最初からロールすることができます。

Cassandra を継続的に利用できるようにするには、彼だけではなく dba も必要です。 アプリケーションを使用する全員が、現在の状況をどこでどのように確認すればよいのか、タイムリーに問題を診断する方法を理解する必要があります。 これを行うために、DataStax OpsCenter (ワークロードの管理と監視)、Cassandra Driver システムのメトリクス (C* への書き込みのタイムアウト数、C* からの読み取りのタイムアウト数、最大待機時間など) を積極的に使用し、操作を監視します。アプリケーション自体の、Cassandra との連携。

前の質問について考えたとき、主なリスクがどこにあるのかがわかりました。 これらは、ストレージへの複数の独立したクエリからのデータを表示するデータ表示フォームです。 このようにして、かなり一貫性のない情報を得ることができます。 しかし、この問題は、XNUMX つのデータセンターのみを使用している場合にも同様に関連するでしょう。 したがって、ここで最も合理的なのは、もちろん、サードパーティ アプリケーションでデータを読み取るためのバッチ関数を作成し、データが単一期間内に確実に受信されるようにすることです。 パフォーマンスの観点から読み取りと書き込みを分割することに関して言えば、DC 間の接続が失われると、互いに完全に矛盾した XNUMX つのクラスターが発生する可能性があるというリスクによって中断されました。

その結果、今のところ、 書き込みの場合は EACH_QUORUM、読み取りの場合は整合性レベルで停止 - LOCAL_QUORUM

簡単な感想と結論

結果として得られるソリューションを運用サポートとさらなる開発の見通しの観点から評価するために、このような開発が他にどこに適用できるかを考えることにしました。

すぐに、「都合の良いときに支払う」などのプログラムのデータ スコアリング (情報を C* にロードし、Spark スクリプトを使用して計算)、領域ごとの集計によるクレームの計算、ロールの保存、ロールに基づくユーザー アクセス権の計算マトリックス。

ご覧のとおり、レパートリーは幅広く、多彩です。 そして、もし私たちが NoSQL の支持者/反対者の陣営を選択した場合、私たちは支持者に加わることになります。なぜなら、私たちは利点を享受しており、まさに私たちが期待していたとおりだからです。

すぐに使用できる Cassandra オプションでも、リアルタイムでの水平スケーリングが可能で、システム内のデータ増加の問題をまったく簡単に解決できます。 呼び出し集計を計算するための非常に高負荷なメカニズムを別の回路に移動し、アプリケーションのスキーマとロジックも分離して、データベース自体にカスタム ジョブとオブジェクトを記述するという悪い習慣を取り除くことができました。 どの DC で計算を実行し、どの DC でデータを記録するかを選択して構成し、高速化する機会が得られ、個々のノードと DC 全体の両方のクラッシュに対して保険をかけました。

私たちのアーキテクチャを新しいプロジェクトに適用し、すでにある程度の経験があるので、上記のニュアンスをすぐに考慮して、いくつかの間違いを防ぎ、最初は避けられなかったいくつかの鋭い角を滑らかにしたいと考えています。

たとえば、 Cassandra の最新情報をタイムリーに追跡するなぜなら、私たちが得た問題のかなりの数はすでに知られており、修正されていたからです。

データベース自体と Spark の両方を同じノードに配置しないでください (または厳密に、許容されるリソース使用量で割る)、Spark は予想よりも多くの OP を消費する可能性があるため、リストから問題番号 1 がすぐに得られます。

プロジェクトのテスト段階での監視と運用能力を向上させます。 最初は、ソリューションの潜在的なすべての消費者を可能な限り考慮します。なぜなら、これはデータベース構造が最終的に依存するものだからです。

最適化を可能にするために、結果として得られた回路を数回回転させます。 どのフィールドをシリアル化できるかを選択します。 最も正確かつ最適に考慮するためにどのような追加テーブルを作成する必要があるかを理解し、要求に応じて必要な情報を提供します (たとえば、次のようなさまざまな内訳を考慮して、同じデータを異なるテーブルに保存できると想定します)。異なる基準を使用すると、読み取りリクエストの CPU 時間を大幅に節約できます)。

悪くありません TTL の付加と古いデータの消去を直ちに提供します。

Cassandraからデータをダウンロードする場合 アプリケーション ロジックは、すべての行が一度にメモリにロードされるのではなく、バッチで選択されるように、FETCH 原則に基づいて動作する必要があります。

プロジェクトを説明されているソリューションに転送する前に行うことをお勧めします。 一連の衝突テストを実施してシステムの耐障害性をチェックするXNUMX つのデータセンターでのデータ損失、一定期間にわたる破損したデータの復元、データセンター間のネットワークのドロップアウトなど。 このようなテストは、提案されたアーキテクチャの長所と短所を評価できるだけでなく、テストを実施するエンジニアにとって良いウォームアップ練習にもなり、運用環境でシステム障害が再現された場合に習得したスキルは決して無駄ではありません。

重要な情報 (請求用データ、加入者負債の計算など) を扱う場合は、DBMS の機能によって生じるリスクを軽減するツールにも注意を払う価値があります。 たとえば、nodesync ユーティリティ (Datastax) を使用し、次の順序で使用するための最適な戦略を開発します。 一貫性を保つために、Cassandra に過度の負荷を与えないでください。 特定の期間の特定のテーブルに対してのみ使用します。

生後XNUMXか月後のカサンドラはどうなるのでしょうか？ 一般に、未解決の問題はありません。 また、重大な事故やデータ損失も許されませんでした。 はい、以前には発生しなかったいくつかの問題を補うことを考える必要がありましたが、最終的には、これによってアーキテクチャ ソリューションが大きく曇ることはありませんでした。 何か新しいことに挑戦したいと思っていて、それを恐れず、同時にあまりがっかりしたくないのであれば、無料のものは何もないという事実を受け入れる準備をしてください。 古い従来のソリューションよりも理解し、ドキュメントを詳しく調べ、独自のレーキを組み立てる必要があります。また、どのレーキがあなたを待っているかを事前に知る理論はありません。

出所： habr.com