データベースは長い間記録システムとして機能し、信頼性が高く耐久性のある方法で重要なデータを保存および管理するという点でほとんどの企業の信頼を獲得してきました。
しかし、時代は変わりつつあります。多くの新たなトレンドが今日のデータの保存と管理の方法に影響を与えており、一部のテクノロジー意思決定者はデータ ストレージにどのようなイノベーションがあるかを再考する必要があります。おそらく、リレーショナル データベースは時代遅れになり始めています。
この記事では、「すぐに使える」記録システムの新しい方法、つまり組織がデータ ストレージについて異なる考え方をする必要がある理由、Kafka を記録システムとして使用する利点、実装の優れたアイデアとは何かなどについて説明します。皆さんにインスピレーションを与えてください。
1. リレーショナル データベースを Kafka に置き換える
KOR Financial は金融サービスのスタートアップ企業ですが、データの保存にリレーショナル データベースに依存せずに Kafka を選択したのはなぜですか? 同社の最高技術責任者であるアンドレアス氏は、かつて Pivotal Software と VMware に勤務し、世界規模でアプリケーション変革アーキテクチャの実践を主導してきましたが、彼の決断の謎は何でしょうか?
まず結果についてお話しますが、Kafka ソリューションを使用すると、 「数十ペタバイト、さらには数百ペタバイトのデータをコスト効率よく安全に保存し、数十年間保存する」ことが可能になります。データ アーキテクチャとスケーラビリティに対する優れた柔軟性を実現しながら、無駄のない機敏な運用を可能にします。」
2. 型を破る: データベースは規模を考慮して設計されていない
時が変わった！デジタル変革の時代において、データ主導の意思決定には、企業が最新の柔軟なデータ アーキテクチャを備えていることが必要です。このようなアーキテクチャを実現するには、データ ストレージが強力で、信頼性が高く、柔軟性が高いかどうかが成功の鍵となります。
過去 20 年間にビッグ データ、分散システム、クラウド コンピューティング、リアルタイム データ処理の台頭も見てきたことは事実ですが、従来のデータベースがボトルネックとなり、データ処理の速度と量に追いつくことができなくなっています。 1秒あたりに生成されるデータ。
まず、データベースはスケールを考慮して設計されていないためです。それらの固有の厳格な構造は、エンタープライズ データ アーキテクチャに必要な柔軟性を妨げるだけです。
グローバル企業にサービスを提供する金融および貿易リポジトリ、および補完的なモジュラー サービスの運営者として、データ処理のレベルは煉獄に匹敵します。KOR Financial の競合他社との違いは、まずデータ フローに対する革新的なアプローチです。「目標: 取引報告、データ管理、コンプライアンスに関するデリバティブ市場と世界の規制当局の考え方に革命を起こすこと。」
Kafka をアーキテクチャの中核とすることは、考え方の「質的」変化です。なぜなら、このアーキテクチャは単なる状態ではなくイベントを捉えることができるからです。「データベースの代わりに Kafka にデータを保存し、それを記録システムとして使用することで、これらすべてのイベントを追跡し、処理し、現在または将来のユースケースに基づいてデータの実体化されたビューを作成することが可能になります。」
他の取引リポジトリや仲介サービス・プロバイダは、データ・ストレージのニーズにOracle Exadataなどのデータベースを使用することがよくありますが、コストが高くつき、データ管理の課題が生じる可能性があります。SQL クエリの実行は可能ですが、課題は大規模な SQL データベースを管理し、これらのシステム内のデータの一貫性を確保することです。
世界的に義務付けられている貿易報告業務に携わるということは、それぞれ独自のデータ モデルと解釈を持つ複数の管轄区域にサービスを提供することを意味します。すべてのデータが単一のスキーマまたはモデルに統合されると、統合管理のタスクはますます複雑になります。データは特定のバージョンの状態で具体化されるため、データの履歴概要がなければスキーマの進化は困難であり、データ管理のジレンマはさらに悪化します。
さらに、大量のデータを扱う場合、従来のデータベースのスケーラビリティには限界があります。対照的に、Confluence Cloud と Kafka およびその無制限のストレージを使用すると、ユーザーは必要なだけのデータを必要なだけ Kafka に保存し、使用したストレージに対してのみ料金を支払うことができます。
パーティションの数は考慮事項ですが、Confluence Cloud に配置できるデータの量は無制限で、ストレージ スペースは必要に応じて自動的に拡張され、保存期間は無制限です。
これにより、技術者はデータが内部でどのように保存されるかを完全に抽象化し、すべてのデータを保存するためのコスト効率の高い方法を提供します。さらに良いことに、これにより、企業は無制限の方法で業務を拡張し、高度な自由度でイベントを必要な表現で解釈できるようになります。
3. アクティブになる Kafka: リプレイ イベント、リプレイ データ
Kafka を記録システムとして使用する大きな利点の 1 つは、データを再生できることです。これは、従来のデータベースにはないネイティブ機能です。財務シナリオの場合、この機能は、トランザクション状態を正確に計算するために重要な「イベントと状態を保存する」という設定によく適合します。
「私たちは、コミットまたはメッセージと呼ばれる大量のデルタ (増分) を受け取ります。これは、特定の時点での取引の状態に寄与します。受信メッセージまたはイベントはそれぞれ、トランザクションを変更し、現在の状態を変更します。エラーが発生した場合は、ストリーム処理ロジック中に発生すると、誤ったステータス出力が発生する可能性があります。」
その情報が固定表現または従来のデータベースに直接保存されていた場合、その状態に至ったイベントは失われます。たとえこれらの出来事の解釈が間違っていたとしても、その解釈に至った文脈を再検討することはできません。
ただし、Kafka は、イベントの履歴順序を不変の追加専用ログに保存することにより、それらのイベントを再生する機能を提供します。
ビジネスの規制要件を考慮すると、すべてを不変に保存する必要があります。最初に受信したすべてのデータをキャプチャして保持する必要があります。ほとんどのデータベース (SQL を含む) では変更が許可されていますが、Kafka は設計上、不変ログへの変更を禁止しています。
Kafka を記録システムとして使用し、無制限のストレージを持つということは、現在の運用ワークロードに影響を与えることなく、過去に遡り、物事がどのように展開したかを分析し、変更を解釈し、特定時点の履歴修正を管理し、代替表現を作成することを意味します。
この柔軟性は、特にエラーをタイムリーかつ効率的に修正することが重要である高度に規制された市場で事業を行う場合に、大きな利点をもたらします。
4. 柔軟性がすべてを克服する
Kafka を記録システムとして使用すると、データ アーキテクチャに大幅な柔軟性がもたらされます。専用のデータベースまたはニーズに正確に対応するテクノロジーを使用して、各ユースケースに固有のビューを構築し、これらのイベント ソースを含む Kafka トピックを読むことができます。
顧客データ管理を例に挙げます。グラフ データベースは Kafka に基づく単なるビューまたは投影であるため、グラフ データベースを中心にシステム全体を構築しなくても、このユースケース専用に設計されたグラフ データベースを使用することができます。
このアプローチにより、記録システムとして指定せずに、ユースケースに応じて異なるデータベースを使用できるようになります。代わりに、これらはデータの表現として機能し、柔軟性の維持を可能にします。それ以外の場合、データはデータベース、データ レイク、またはデータ ウェアハウスに挿入されますが、これらは厳格であり、特定の使用例に最適化された表現にデータを変換できません。
スタートアップの観点から見ると、この柔軟性により、特定のテクノロジーの方向性への時期尚早な固定化を回避することもできます。2021 年に設立された KOR は、責任ある最後の瞬間まで決定を延期するというアーキテクチャのベスト プラクティスに従っており、これにより、特定のテクノロジの選択に対するコミットメントは、それが必要で準拠するまで延期される可能性があります。このアプローチは、ビジネス ニーズの進化に合わせて適応および進化できるテクノロジ環境を意味し、将来の拡張性と柔軟性を可能にします。
柔軟性に加えて、スキーマ レジストリを使用するとデータの一貫性が保証されるため、開発者はデータがどこから来たのか、どのスキーマがそれに関連付けられているのかを知ることができます。Confluence Cloud では、スキーマ レジストリを通じて明示的な進化ポリシーを設定することもできます。たとえば、すべてのデータをデータ レイクに配置すると、そのデータのさまざまなバージョン、さまざまなスキーマ、およびさまざまな表現をすべて管理することがはるかに困難になります。
5. スイッチング技術の背後にある: イベント駆動型の考え方
データベースを放棄し、データを保存するための記録システムとして Kafka を採用することは、非常に新鮮なアプローチのように思えます。
すべての企業がこのアプローチを受け入れることができるわけではありません。アンドレアス氏は、これには企業が「イベント駆動型モデル」の文化を育む必要があると考えており、この考え方の変化はストリーム処理によるアプリケーション開発方法にも拡張されるべきであり、そうしないと互換性が生じてしまいます。 . 性別の不一致の問題。
この目的は、チーム メンバーが不変データを扱っていること、何かを書いた場合はそのまま変更することはできないことを認識できるようにすることです。
アンドレアス氏はまた、Kafka 中心のアーキテクチャの実装は、「証明システムとしてのストリーム処理とイベントの重要性」を理解するチームから始まると提案しました。そのチーム内で強みを示すことで、他のチームの大使として機能し、究極の真実としてのイベントの採用と、究極の表現としての状態によるストリーム処理の採用を促進できます。
6. 最後に書かれています: Kafka はデータベースを置き換えることができますか?
Apache Kafka と Confluent の共同創設者である Jay Kreps は、2017 年の時点で「データは Apache Kafka に保存できる」と明言しました。
さらに、データは必要なだけ Kafka に保存できます。ニューヨーク タイムズの Apache Kafka の発表は、Kafka を使用してデータを永久に保存する有名な例です。Kafka は、ニューヨーク タイムズがこれまでに公開したすべての記事を保存するために使用され、API ベースのアプローチに代わって使用されます。
では、Kafka はデータベースを置き換えることができるのでしょうか? この記事では、「データベースは規模を考慮して設計されていない」など、従来のデータベースの多くの「不適切な」側面について言及していますが、それは金融などの強力なリアルタイム シナリオにおけるソリューションに限定されています。
ただし、従来のデータベースの思考パターンを打ち破り、基礎となるアーキテクチャを再設計するという提唱された方法は、反映し学ぶ価値があります。
7. 関連分野の拡大
伝統的な企業でも大規模なデジタル化が始まったこの10年で、社内ツールの開発過程では、大量のページ、シーン、コンポーネントなどが常に繰り返されていることが分かりました。このホイールはエンジニアにとって多くの時間を無駄にしました。
このような問題に対応して、ローコードでは、特定の繰り返し発生するシナリオとプロセスを個別のコンポーネント、API、データベース インターフェイスに視覚化し、ホイールの繰り返し作成を回避します。プログラマーの生産性が大幅に向上しました。
プログラマーが知っておくべきソフトウェア JNPF 高速開発プラットフォームを推奨します。業界をリードする SpringBoot マイクロサービス アーキテクチャを採用し、SpringCloud モードをサポートし、プラットフォーム拡張の基盤を改善し、迅速なシステム開発、柔軟な拡張、シームレスな統合、高度なニーズを満たします。パフォーマンスアプリケーションなどの包括的な機能。フロントエンドとバックエンドの分離モードを採用し、フロントエンドとバックエンドの開発者が協力して異なるセクションを担当できるため、手間が省け便利です。体験公式サイト： https: //www.jnpfsoft.com/?csdn
ローコード技術を理解していなくても、すぐに体験して習得できます。