セコイアのコアR&Dチームとの対話: 自社開発分散データベースへの道

データベースの中核となる研究開発チームは常に非常に謎に包まれています。舞台裏に隠れた隠者として、彼らはデータベース開発とデータベース研究開発チームについてどのような見解を持っているのでしょうか?この記事では、Sequoia Database のコア技術 R&D チームの「ベテラン」である Danny 氏を招き、自社開発の分散データベースの軌跡を皆さんと共有していただきます。

[[260812]]

Q: データベース業界のベテランとして、自己紹介をお願いできますか?

ダニー：私の名前はダニーです。私はSequoia DatabaseのコアR&Dチームのメンバーです。私は、データベース コアの研究開発で 20 年以上の経験を持つ上級データベース エンジニア兼アーキテクトです。 DB2カーネル研究開発チームの一員として、DB2やDPFなどの製品のアーキテクチャ設計や研究開発に携わってきました。

現在、多くのデータベース専門家とベテランが当社の北米研究開発ラボ チームに加わっており、その全員が DB2 のコア テクノロジー チーム出身者です。

私たちのチームメンバーの多くは IBM や Huawei 出身の「伝統的なエンタープライズレベルの IT 担当者」ですが、注目を浴びるのは好きではありません。しかし、今はテクノロジー界における新たな変化の時代です。当社の製品はオープンソースであるため、チーム内の技術専門家もコミュニティ活動に積極的に参加し、コアデータベースの研究開発の経験を共有し、皆様とともに進歩していきます。

Q: 元 IBM 社員として、IBM のような長い歴史を持つ IT 企業の中核となる研究開発チームについてどう思われますか?それについてあなたが最も深く感じていることは何ですか?

ダニー: IBM は「リレーショナル データベース」の概念と理論体系を提案した最初の企業です。技術的な観点から見ると、3 つの従来のリレーショナル データベースは、実際に開発の過程で多大な技術的蓄積を蓄積してきました。 DB2 は、3 つの従来のリレーショナル データベースの中で唯一の分散型製品であるため、当社チームの分散型テクノロジの蓄積は一貫しています。

DB2 に携わって 10 年以上経ちますが、その中で私が最も深く感じたのは、技術的な基盤と蓄積でした。

たとえば、Unix がスレッド メカニズムを実際にサポートする前から、マルチスレッド モデルや異なるハードウェア デバイスの論理スレッドの切り替えと呼び出しを実装するためにアセンブリ言語が使用されていました。これらのメカニズムは当時としては実に先進的なものでした。

R&D チームに関して言えば、IBM の研究所には多くの隠れた才能が集まっています。アセンブリ言語を使い始めた技術専門家は、データベース、オペレーティング システム、コンパイラの基礎的な研究開発に携わってきました。リレーショナル データベースの最も初期の概念を生み出し、データベースを汎用ソフトウェア プラットフォームに構築したのは彼らであると言えます。

Q: データベースのような基本的なソフトウェアの技術的な難しさは何ですか?

ダニー: データベース ソフトウェア、特に真のエンタープライズ対応製品は、誰もが想像するほどソフトウェアを開発するほど簡単ではありません。

技術的な観点から見ると、データベースには技術的な遺伝子の継承と革新の両方が必要です。

データベース技術は40年以上にわたって開発されてきました。技術の発展に伴い、データベース ソフトウェア/プラットフォームは、複雑な機能、巨大なアーキテクチャ、高度なセキュリティ要件を備えた巨大なソフトウェア製品システムになりました。したがって、テクノロジーには、技術の蓄積と新たなイノベーションの両方が必要です。

一方、アプリケーション側では、ユーザーは銀行や政府など 30 年間データベースを使用している古い顧客であるため、通常、完全な移行のリスクを負う余裕はありません。したがって、ビジネステクノロジーアーキテクチャでは、さまざまな時代の歴史的遺産を保持することが不可欠です。たとえば、北米の一部銀行の基幹 IT システムは、いまだに 40 年前のテクノロジー プラットフォーム上で稼働しています。また、エンタープライズ レベルの対応データベース インフラストラクチャ ソフトウェアには、古いビジネスの運用を保証するだけでなく、継続的な革新のためにも、強力な互換性が求められます。

このような革新は必要ですが、技術的には最も難しいものでもあります。

Q: データベース業界で約 20 年の経験をお持ちですが、データベース コア チームはどのようなものであるべきだとお考えですか?

ダニー: コア データベース研究開発チームの遺伝子は非常に重要だと思います。たとえば、IBM の DB2 チームは、データベース分野の「ベテラン」数名と、技術力のある上級エンジニアで構成されています。

上で述べた技術的な複雑さや製品の履歴の範囲の問題と同様に、データベース製品を大企業で使用する場合、技術チームは従来のデータベース開発の経験を持っている必要があります。これは技術ベテランの役割です。

簡単に言えば、データベース基本ソフトウェアは革新的な技術と蓄積された技術的経験の融合です。

Q: 国内と海外における基本ソフトウェア開発の違いは何ですか?

ダニー：比較的、海外には技術人材の基盤があり、IBMやOracleのようなシステムを継承しており、多くの技術人材とチームを育成してきました。そのため、北米の新世代の基本ソフトウェア製品チームの多くは、実際には依然として旧世代の「古いドライバー」を中心に構築されています。

しかし、中国では基本ソフトウェア分野の人材の蓄積がまだ不十分であり、基本ソフトウェア分野には独自の武術流派がまだ十分に形成されていない。近年、国内の基礎ソフトやAI分野の企業が人材採用に躍起になっているのも、このためだ。しかし、歴史的な理由により、中国のインターネット研究チームと科学研究チームの両方が独自の学派を形成するには時間がかかるだろう。

Sequoia のチームには、Wang Tao 氏を代表とする DB2 チームからの多くのコア技術専門家と、Huawei からのコア技術チーム メンバーがいます。それは技術的な遺伝子と技術革新の優れた組み合わせです。

Q: データベース開発は他のソフトウェアとどう違うのですか?

ダニー: 先ほど述べたような特性のため、基本ソフトウェア、特にデータベースの研究開発は、他のアプリケーション ソフトウェアとは大きく異なります。最大の違いの 1 つは、開発言語と開発モデルです。

コンピュータ開発の観点から見ると、C は最も機械語 (アセンブリ コード) 指向です。原則として、C コードの各行はいくつかのアセンブリ命令に正確にマッピングできるため、基盤となるオペレーティング システムを制御するという点では最も正確です。

C++ は、C をベースに開発されたオブジェクト指向言語です。低レベルのプログラミングでは、C++ の高度な機能はほとんど使用されませんが、その設計パターンはモジュール開発に非常に役立ちます。したがって、C++ を使用すると、基盤となるオペレーティング システムの最も正確な制御を考慮できるだけでなく、いくつかのオブジェクト指向の概念をコードに統合することができ、複雑なシステムの構築において重要な役割を果たします。

しかし、最近の新しい開発言語の中にはオブジェクト指向ではないものもあり、デザインパターンの観点から大規模で複雑なシステムの開発には適していません。同時に、これらの言語は C/C++ の最も重要なポインター概念の多くを単純化しているため、正確なメモリ操作は不可能になっています。ポインタの概念は、うまく使えば魔法のツールですが、下手に使えば役に立たないものになります。能力の低いプログラマーや、非常に完全なテスト フレームワークのないプロジェクトでは、ポインターなどの高度な機能を完全に理解することが難しく、大規模なプロジェクトの開発のあらゆる場所でメモリ リークやクラッシュの脆弱性が発生します。

しかし、Sequoia には DB2 データベース カーネルの研究開発経験があります。人員能力からコード品質管理、テスト フレームワークの改善まで、これらの高度な機能を完全に習得し、基盤となるオペレーティング システムとデータベースのパフォーマンスと処理能力を最大限に高めることができます。

Q: 分散データベースの方向性はどのようなものですか?

ダニー: ガートナーと当社の CTO である Wang Tao の共通の見解によれば、従来のリレーショナル データベースでは格納できないほど大きなテーブルの数は、比較的制御可能です。したがって、この問題を解決できる回避策は数多くあります。このため、従来、シャーディングは面倒ではあるものの、アプリケーションの問題は解決できます。

データベースが直面している本当の問題点は、「マイクロサービス」におけるデータ サービスのリソース プーリングです。

アプリケーションが従来のストーブパイプ型アーキテクチャからマイクロサービスに移行すると、各マイクロサービスに独立したデータベースを配置することは不可能になります。この場合、データ サービス リソース プールは、開発能力、アプリケーション タイプ、SLA セキュリティ レベルなどが異なるさまざまな開発者やチームからの数百または数千の上位レベルの要求に直接対応する必要があります。

したがって、リソース プールには、弾力的な拡張、リソースの分離、マルチテナント、構成可能な一貫性、マルチモード (さまざまな SQL プロトコルのサポート)、クラスター内で構成可能な災害復旧戦略などの一連の機能が必要です。同時に、各データベース インスタンスのコンピューティング機能とストレージ機能は、最大限に拡張できる必要があります。結局のところ、一部のマイクロサービスには大量のフロー データが含まれる可能性があり、各データベース インスタンスによって使用されるリソースを 1 つの物理デバイスに制限することはできません。

したがって、分散 OLTP のためだけに、厳格な要求を構成しない問題のみが解決されます (データベースとテーブルのシャーディングの問題はずっと前に解決できたはずです)。しかし、マイクロサービスアプリケーション開発の環境では、リソースプーリングの観点からデータベースが上位層にサービスを提供する必要があります。同時に、リソース プール内の各データベース インスタンスは、従来のデータベースとの完全な互換性を実現するために、分散トランザクションなどの一連の機能もサポートする必要があります。

Q: バージョン 3.0 のリリース以来、SequoiaDB はコミュニティと市場から非常に良いフィードバックを受けています。製品の新たな展開について少し教えていただけますか？

ダニー: 近い将来、OLTP シナリオのパフォーマンスと SQL 処理機能が大幅に向上する新しいバージョンをリリースする予定です。分散トランザクションベースのビジネスでは、全体的なパフォーマンスの向上は現在のバージョンと比較して 2 ～ 3 倍、類似製品と比較して 5 ～ 6 倍になります。 。

もちろん、今週の活動についても簡単にシェアさせていただきます。

3月30日土曜日の午前中には、北京中関村ロボットナイトコーヒー書店でSequoia Techdayの2回目のセッションも開催されます。また、詳細な技術情報も共有し、ライブビデオ放送も行います。皆様もぜひ注目してご参加ください！今後は、さらに「神秘的な」データベース「経験豊富なドライバー」も用意し、技術、トレンド、経験を皆さんと共有していきます〜