多数の高速分散：インメモリデータグリッドソリューションの選択方法

必要なのは、Turingの用語では、マシンメモリを提供して、データを迅速に掘り下げ、それと同じくらい早く掘り出すことができるようにする方法でした。

ニール・スティーブンソン、クリプトノミコン

この画像の背景として使用されているIBM 1401メインフレームの磁気コアメモリモジュールの写真は、コンピューターが大きく、メモリが高価だった時代を思い出させます。 今日、以下の投稿から学ぶように、すべてが変わりました...



IMDG、グリッド、インメモリデータグリッド-投稿のトピックであることが判明したシステムに名前を付けない場合。 また、名前は完全に真実であり、ツールとしてのグリッドはますます普及していますが、多くの場合、グリッドを分散キャッシュシステム、NoSQLデータベース、または「MySQLをRAMに配置すると、ドライブ、ほとんどIMDGです。」



少し前まで、情報を蓄積し、処理された後の決定は論理的であり、情報リポジトリ用の新しいクエリ言語は優れたソリューションであるように見えました：情報を処理するプロセスの各段階が強調され、かなりよく制御されていました。 しかし、時代は変化しており、今日ではビジネスは「昨日」ではなく情報を処理したいという要望をますます強くしていますが、現在の情報は文字通り「オンライン処理」を持ち、かなり大量の情報に関連しています。 そして、ここで、それが欲しいかどうかにかかわらず、新しいツールを探すことを余儀なくされています。





オンラインサービスのユーザー数の増加、ソーシャルネットワークの大規模な広がり、モノのインターネットの出現と発展、銀行業および電気通信セクターのサービスの開発はすべて、IT業界に非常に予測可能な方法で影響を及ぼしました。強化されただけで、長い間箱から出て行った奇跡的なソリューションは登場しませんでした。 言い換えれば、時間の要求は「好きなように実行してください。しかし、より速く実行してください。そうでなければ、ビジネスはやりすぎになりません！」



最初は、クラウドはWebアプリケーションのリクエスト数の増加に耐えることに成功しました：クラウドのコンピューティングパワーをスケーリングするというアイデアは、もちろん、アプリケーションコードのサポートとアカウンティングが必要でしたが、少なくとも、アプリケーションがプロセッサのハードウェアおよびメモリ機能を実行しないことが明らかになりました。 しかし、処理された情報のストレージはより複雑になりました。そのようなストレージの通常のバリアント（たとえば、古典的なSQL DBMS）が次第にシステム全体のボトルネックになることが判明したためです。 すべての計算ノード（自動スケーリングがそのようなノードをどのように上げても）がSQLサーバーからの応答を待っているアプリケーションは、率直に言って、悲痛な光景です！



もちろん、優れたアーキテクトは、そのような行き詰まった状況で稼働中のシステムを構築しようとします（ここから、各データストリームのキャッシュ、無効化のバインディング、NoSQLサーバーを追加するか、SQLの前身を置き換えて、上記を考慮してアプリケーションロジックを書き換えます。何があっても、チーム全体でやるべきことがあります！）が、もちろん、決定を「少し簡単に」したいと認めなければなりません。



キャッシュ、NoSQLアプローチ、および分散アプローチ（多くの場合、LANだけでなくWANを介して分散されることもあります）を組み合わせてIMDGソリューションが登場し、システムを構築しました。 本質的に、これらはクラスターデータストレージであり、データモデルはオブジェクトベースまたはキーバリューストレージを使用できます。 これらのストレージには、率直に言って「魔法の」プロパティがいくつかあります。データを完全に信頼できない環境（RAM）に確実に保存する機能と、データを最初にディスクに保存してから再度読み取ることなく、メモリで直接処理する機能です。



グリッドデータストレージモデルは、「何も共有しない」という原則に基づいて構築されており、物理的に分散した多くのサーバー間でのデータの分散を伴います。 IMDGに含まれるすべてのサーバーは同等であり、すべてのデータはRAMに保存されます。 同時に、グリッド設計はフォールトトレラントであり、障害が発生したサーバーを自動的に検出する機能があり、必要に応じて（グリッドのメモリサイズを変更するなど）、サーバーはグリッドインフラストラクチャを中断せずに接続または切断できます。



すでに説明したプロパティは、大規模システムの設計者の注意をIMDGのアイデアに引き付けるのに十分なはずです。 実際、分散処理されたデータの分散ストレージが得られます。これはすべて、RAMの拡張という代償を伴いますが、その幸いなことに、その単位コストはますます減少しています。 イデオロギー的に、グリッドソリューションはクラスター内のRAMの量に制限がないため、ストレージテクノロジーの境界データを超えてデータ量を増やす問題はそれほど深刻ではありません。



特定のプロジェクトに適したグリッドソリューションを選択するのは簡単なことではありません。 グリッド自体は非常に複雑でデザインが面白く、悪名高い猫のように「調理できる必要がある」ためです（これは、クラスターの開始とプロジェクトへの統合の両方に時間がかかることを意味します）。 IMDG製品は進化的開発において互いに有用な機能を採用しようとするため、機能の実装がより興味深く、プロジェクトのニーズにより適した場所を慎重に選択する必要があります。



インメモリデータグリッドのトピックについて、いくつかの非常に興味深い対話者と話し合いました。 特に興味深いのは、それぞれのシステムがどのように設計され、実装されるべきかについての経験と理解を持っているという事実です。 だから、私は提示する：

アンドレイ・エルショフ（Dino Systems）

-興味深い技術的質問：システム設計の段階でのグリッドソリューションの選択。 アドバイスをお願いします：すぐにソリューションが提供する幅広い機能を利用するか、徐々に複雑化する道を進みます-よりシンプルなものから始め、プロジェクトが成長するにつれて、より機能的なソリューションを使用する可能性を探りますか？



すべてのIMDGの動作原理は似ていますが、APIは異なる場合があります。 ベンダーに関係なく、IMDGと作業を統合するJSR-107もあります。 この場合、1つのソリューションから別のソリューションにまったく問題なく切り替えることができます。 しかし、いくつかの欠点があります。

まず、このJSRは、キャッシュへの書き込み/キャッシュからの読み取り、エントリプロセッサ、連続クエリなどの基本的な事項のみを説明します。 多くの場合、このような機能では不十分な場合があり、ベンダー固有の機能を使用する必要があります。



第二に、使用するソリューションで機能テストと負荷テストを実行する必要があります。異なるIMDGには異なるパラメーターがあり、最大のシステムパフォーマンスを確保するためにいくつかのデフォルト値が設定されていますが、多くの障害ケースは正しく処理されない可能性があります。



繰り返しますが、別のソリューションに切り替えるには、別のベンダーのシステム設定を理解する必要があることを意味する場合があります。

すぐにベンダーを選択することをお勧めしますが、最初にコミュニティバージョンを使用してから、テクニカルサポートと追加機能を備えたエンタープライズバージョンの料金を支払います。



正直に言うと、特にIMDGを初めて使用し、システムでIMDGを使用するためのスクリプトを完全に知らない場合は、ベンダーの選択は簡単な作業ではありません。 この場合の適切なアプローチは、各IMDGソリューションでシステムのPoCを作成することです。



-たまたま、ほとんどすべてのIMDGソリューションが、ユーザーにとって（すべてではないにしても、多くの人にとって）最高のソリューションとして位置付けられました。 そのようなトピックの最高/最低について明確に話すことは可能ですか？



私はGridGain（Ignite）のみで豊富な経験があり、CoherenceとHazelcastの機能についても考えています。 3つのソリューションはすべて優れた機能を提供し、多くの共通点を持っていると言えます。 グリッドの変更に対応する機能を備えたキーと値のストアが必要な場合は、任意のソリューションを安全に使用できます。 ただし、複雑なデータクエリを作成する場合は、トランザクションサポート（構成可能な分離レベル）、ディスクへのデータの保存、データセンター間のデータの複製、ネットワークセグメンテーションの場合の正常な動作、ノードによる複雑なデータ分散が必要です。各ソリューションのドキュメントを作成し、タスクに適したソリューションを選択してください。



-作成できる魔法の杖を入手できたとしても、非常に優れたデータストレージシステムがあれば、どのシステムを注文しますか？



もちろん、プログラマーとして、サーバーのクラッシュやネットワークの問題に関係なく、システムを常に利用可能にして、最も予期される方法でシステムを機能させたいと考えています。



一般に、データベースまたはIMDGの作業に関する期待については、一貫性と新鮮さについて話します。 システムがトランザクションを処理する場合は、トランザクション分離レベルも追加されます（コードフリーズのCRDTレポートを検討することをお勧めします。 このレポートのビデオはこちらです-著者のメモ ）。 一貫性と分離のレベルが高いほど、システムの動作が予測可能になり、プログラミングが容易になります。 最良の保証は、厳密な直列化可能性（strong-1SR）です。これは、直列化可能トランザクションの分離レベルと一貫性のレベル（線形化可能性）の組み合わせです。 厳密な直列化可能性を提供するシステムは夢の実現です。



そのようなシステムは可能ですか？ もちろん、分散システムに興味があります。 ここでCAP定理を思い出し、CP（CA）の場合、そのようなシステムは可能ですし、存在さえしていると言います-Google Spanner。 ただし、インフラストラクチャの要件が非常に高いため、このようなシステムを購入できるのはGoogleだけです。 そして、大陸間のデータ複製の遅延に我慢する必要があります。



APの場合、つまり、ネットワークの問題が発生する可能性がある場合や、高速な応答時間を必要とする場合に、厳密な一貫性を保証するシステムが必要です。 そのようなシステムはなく、ありえません。たとえば、 Peter Bailis博士に示されています。



IMDGを選択するというトピックに戻ります。これまたはその決定が保証するものについて考えてください。メーカーの広告の約束は、分散システムの理論的な制限に違反していますか？ スイッチのポートが切れたり、JVMに長いガベージコレクションがある場合、またはトラクターがDC間のケーブルを破損した場合、IMDGに依存することは可能ですか？

ウラジミール・オゼロフ（GridGain）

-GridGainには無料版と有料版があります。 技術的な観点から言えば、両者の違いは技術サポートといくつかの機能（WANレプリケーションなど）の可用性のみですが、他のオープンソースApache Igniteと「有料」GridGainは同じですか？ または、ここでFedora vs. RHEL」、無料版では「戦闘侵入」機能があり、後でより安定した形で有料配信に含まれますか？



3つの製品バージョンがあります。 GridGain Professionalは、Apache Igniteコードベースに加えて、サポートと迅速な変更と改善（ホットフィックス）です。 これはビジネスにとって重要な瞬間です。なぜなら、オープンソースでは誰もあなたに何も負っておらず、尋ねる人もいないからです。

Professionalに加えて、GridGain EnterpriseとGridGain Ultimateを提供しています。これらは、WANレプリケーション、セキュリティ、ローリングアップグレード、スナップショットなどの高度な機能を備えたGridGain Professionalに基づく製品です。



修正プログラムはすぐにマスターApache Igniteに分類されますが、GridGain Professionalの一部として以前にリリースされます。 したがって、有料のユーザーはすぐにそれらを受け取り、無料のユーザーは、Apache Igniteの次のリリースを待つか、ウィザードから危険を冒して自分で収集します。

無料のユーザーでの実行は練習していません:-)



-どうやら、Apache Ignite（または必要に応じてGridGain）は、他のIMDGシステムのより広範な機能バージョンとしての地位を確立しています。 これは本当にプライドの理由なのでしょうか、それとも他の人に比べて収益性の高いマーケティングアプローチにすぎないのでしょうか？



簡略化すると、当社の戦略は3つのポイントで構成されています。 まず、私たちはあらゆるプラットフォームとあらゆるフレームワークに取り組んでいます。 私たちの武器は、Java、C＃、C ++、Spring / HibernateからHadoop / Sparkへの多数の統合を豊富にサポートしており、この方向を強化し続けています。 2番目は、データにアクセスするための重要な方法としてのSQLです。 これは、Key-Value APIとは異なるウェイトカテゴリです。 独自のSQLエンジンとそのためのJDBC / ODBCドライバーを積極的に開発しています。 3番目は永続性です。 メモリとディスクの両方で作業することを学びました。 現在、Apache Igniteは、RAMが許容するよりも多くのデータを格納できる、分散された水平方向にスケーラブルなDBMSです。



これは、古典的な用語「IMDG」よりもはるかに進んでいることを示しています。 それでも、Apache Igniteは依然として高速で便利なグリッドであり、一方が他方に干渉することはありません。 さて、「より広い」または「すでに」誰が決定するかはユーザー次第です:-)



-IMDGの使用を必要とするプロジェクトは、ほとんど常に非標準であり、アーキテクチャと技術の両方のソリューションがプロジェクト専用に開発されます。 あなたの意見では、プロジェクトでIgnite / GridGainを使用する会社は、選択されたグリッドソリューションのデバイスの技術的理解レベルで能力を持っているべきですか？ スタッフに専任のIMDG DBAスペシャリストが必要ですか？



非常に正しい質問です。 誰もが慣れ親しんでいる従来のDBMSとはあまりにも異なるため、システムの使用と管理のスキルが不足しています。 現在、これは主にソリューションアーキテクトの肩にかかっています。 しかし、私たちはこの方向で多面的な作業を行っています。 私たちの焦点は、インテグレーター企業とのドキュメンテーション、トレーニング、およびパートナーシップの構築です。 これはすべて、知識と経験の普及に貢献します。 今後数年間で、そのようなスキルは非常に広まると思います。

ビクターガモフ（コンフルエント、以前はヘイゼルキャスト）

-たまたま、ほとんどすべてのIMDGソリューションが、ユーザーにとって（すべてではないにしても、多くの人にとって）最高のソリューションとして位置付けられました。 そのようなトピックの最高/最低について明確に話すことは可能ですか？



私はユースケースについて話をしますが、「最良/最悪」の概念については話しません。 プロジェクトの内部アーキテクチャに関連する瞬間に基づいて構築する必要があります。 IMDGソリューションはそれぞれ独自の方向で開発されており、「1つに最適」という質問に答えずに比較することは正しくありません。

グリッドは、分散キャッシュのソリューションとは異なり、ノードで直接計算を実行できます。これはニッチな機能ですが、特定の種類のタスクには非常に便利です。 ただし、IMDGはキャッシュとしてのみ使用されることもあります。もちろん、ここではタスクがグリッドを対象としていないため、異なるソリューションを比較することは困難です。 ちなみに、グリッドを理解した開発者は、ほとんどの場合、以前に選択したIMDGの他の機能を使用し始めます。



いずれにせよ、開発者の立場からグリッドについて話し合う必要があり、まず、この開発者が解決するタスクから、次に彼の以前の経験とプロジェクトで使用されたスタックから進む必要があります。



-市場には多くの「純粋なIMDG」ソリューションがあり、実際には1つ（Ignite / GridGain）のみが存在し、それ自体がより多くのものとして位置付けられています。 そのような状況で、すべてのソリューションに独自のニッチがあると言うのは正しいですか、または誰かが技術的に進歩し、他の誰かが追加機能を習得していないと言えますか？



マイクロソフトの急速な成長のフレーズを思い出してください。「すべてに集中しましょう！」

当初はニッチな製品に多数の機能が存在することは、多くの点でマーケティング上の問題だと思います。 各IMDGはいくつかの点で興味深いものであり、それぞれが開発のある時点にあるため、機能を追加するペースはどこでも異なります。



IMDGは、データの保存、そのデータに対するコンピューティング、分散通信の3つの方法で強力です。 他の機能は、必要に応じて追加されます。 GridGainは、顧客の要望を考慮に入れること（たとえば、SberTechとの協力の一環として）など、いくつかの興味深い機能を実装していますが、他のIMDGソリューションでは、製品の機能を拡張するためにすぐに電力を噴霧する必要性はありません。



一方、IMDGのような狭いシステムのメリットは、エンドユーザーではなく、主に開発者が受け取ります。 そして、開発者はすでにIMDGが提供する機会をどのように活用するか、およびこれらの機会を使用するためにアプリケーションのロジックをどのように変更するかを決定します。 （英語でのビクターのレポートへのリンク -著者のメモ）。



-長い間、IMDGの概念は現実とは離婚したように見えました。すべてのデータを完全にメモリに保存することは高価であり、なんとなく非合理的でした。 今日、IMDGは一種の「銀の弾丸」としてますます使用されています。 この技術が十分に長く市場に出ることを期待することは可能ですか、これはいつか別のものに置き換わる別の流行ではありませんか？



そう思う。 私の意見では、メモリのコストが下がり、サーバーのコストも下がり、ネットワーク上の通信速度が上がります-タスクに大量のデータをすばやくアクセスして信頼性の高いストレージが必要な場合、IMDGを使用することは長い間素晴らしい選択肢です。 このようなタスクは常に必要になるため、ツールとしてのグリッドが必要になります。



ここで、IMDGがデータストリーム処理スキームにうまく統合されていることがわかります。 情報の流れがあり、その統計をリアルタイムで作成する場合、IMDGデータはすぐに処理されます（たとえば、ディスクに保存されず、直接メモリに保存されますが、同時に終了時でも情報の安全性が保証されます）クラスター内のノードの構築）、すぐにさらに使用できます-たとえば、一部のダッシュボードに表示されます。 同時に、最初に特定のデータベース（ディスク）にデータをロードし、それをディスクに転送して処理し、ディスクから「アウト」して読み込む必要がないことに注意してください-常にメモリに保存し、不要な移動に多くのお金を節約します長期のデータストレージ「ラウンドトリップ」で私たち。



IMDGは「銀の弾丸」になりますか？ ほとんど：これは、私が言ったように、ニッチなソリューションですが、グリッドは確かに需要があります。

---

このトピックについて長い間議論することができます：議論、同意、ホリバー、時にはキャベツスープを打つ...そして最初の3つのオプションをコメントに実装できる場合は、4番目（最初の3つも練習できますが）どこかに行く必要があります。 どこへ？ JavaカンファレンスのJoker 2017 （11月3〜4日、サンクトペテルブルク）またはDevOpsカンファレンスのDevOops 2017 （10月20日、サンクトペテルブルク）にアクセスできます。ストレージについて話し合う人がいます。