見出し画像

劔"Tsurugi"ロードマップ(2024年2月時点)

下記のロードマップはTsurugiを取り巻く社会状況や、ユーザの利用状況、また実際の開発状況によって随時更新・変更されます。
ロードマップを提示する目的は、「Tsurugiは長期的な視野をもって開発されている」という開発サイドの意思を、ユーザやTsurugiをかかわる直接・間接、顕在・潜在的利害関係に伝えること、それ自体を目的としています。

ロードマップの内容はコミットではなく、「ざっくりとした予定」程度に考えておいてください。したがって予告なく変更されることがあります。

◆長期ロードマップ

□2024-2025 βリリース後からの直近数年間

[概要]
①RC(release candidate)GA(generally available)のリリースを目標とする
FY2024/1Q(4-5月)をターゲットとする。可用性強化・バク回収・SQL強化が主たる内容になる。

②単ノードベース
・対応プラットフォームの拡充
  --Red Hat Enterprise Linuxのサポート
  --Oracle Cloudでの実行サポート
・障害対策の強化
  --既存バグの回収
  --障害対応としてのspill-outを実装し、メモリーより溢れたデータ処理を救済する。加えてreplica連携のベース実装として利用する。
・SQLサポート強化
  --優先度によりサポートされるSQLを随時実装していく
  --特にTsurugi利用者の案件からの要望を優先的に取り扱う
・パフォーマンスエンハンスメント
 SQLの実行結果についてパフォーマンスが低い項目から優先的に対応していく
・運用ツールのリリースと強化
 運用可用性向上とパフォーマンスチューニング用のツールを中心としてリリースしていく

③複数ノードベース
分散ノードベースの機能としてreplication / partitioning /分散トランザクションを実装目標としている。当該期間での分散ノードの機能は、full-replicationを除き、基本βまたは試験的なプロトタイプにとどまる。

  1. replication
    特にHA構成を意識し、同じデータを複数箇所に保持する。なお、replicationはトランザクショナルとし、partial writeを防止する。

  2. partitioning
    特にスケールアウトを意識し、一つのテーブルのデータを分割して、複数のノードに配置する。partitioningされたデータの処理はトランザクショナルとする。

  3. 分散トランザクション
    複数のTsurugiに渡りトランザクションを行う場合に、各Tsurugiで一貫性が担保できる分散トランザクションを実装する。なお、read lock/write lockは用いない。

□2026以降の中長期

[概要]
より本格的に分散処理を導入し、また次世代のN/Wへ積極的に適応させる。

①本格的な分散処理の導入
--replication / partitioning
分散ノード対応の機能をGAとしてリリースする
 ・分散ノード環境での処理の最適化を実装していく

--分散トランザクションの本格導入
 ・分散トランザクションのより広い実行環境を志向する
 ・実行パフォーマンスの向上を行う

--運用ツール/メンテナビリティの向上
 ・分散処理での対障害性の向上
 ・各分散環境での運用ツールの導入

--Asakusaの統合
 ・2024-2025に前倒しの可能性はある
 ・Tsurugi上でAsakusaが実行可能になる
現在のAsakusaユーザがすべてミッションクリティカルの基幹系システムなので、Tsurugiがかなり安定した2026以降をターゲットにAsakusa-Tsurugi対応を行う。Tsurugi上でAsakusaが実行可能になる

②新しいN/Wのアークテクチャへの対応
低遅延N/Wをベースに、Rack Scale Architectureの構築、および100km圏でのDC間でのゼロ・レイテンシー統合による分散DBの構築を行う


◆2024年度(2024/4-2025/3)見通し

□2024年度:1Q

[概要]
RC/GAリリースし、商用サポートを開始する。時期は4-5月をターゲットとする。

・可用性向上
--運用テスト等で検出されたバグの優先回収しGAとする

・SQLサポートの強化
--優先度:最優先
---ステートメント
INSERT INTO ... SELECT ...

---クエリー
LIMIT clause
HAVING clause

---式
BETWEEN
IN
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP

--優先度:高 (一部は2Q以降を予定)

---定義
GENERATED ALWAYS AS IDENTITY (identity columns)

---クエリー
UNION ALL

---式
temporal value literals
NULLIF
COALESCE
CASE ... WHEN ...

--キャスト/型変換
順次追加していく

・パフォーマンス向上

・運用ツールのリリース(有償)
--Belayer Web UI
Web API のみの提供であったTsurugi運用管理ツールBelayerについて、ブラウザベースのUIや、コマンドラインインターフェースを提供する。コマンドラインインターフェースのWindows対応
--Altimeter
Tsurugi上で発生したイベント情報をタイムシリーズデータベース上に蓄積し、条件検索や集計等を行うためのサブシステム。イベント情報には、セッション・トランザクション・SQL処理の開始終了や、それぞれのステータス情報等が含まれる

□2024年度:2Q

[概要]
サポートプラットフォームの拡大
 ・Oracle Cloudでの実行サポート
 ・Ubuntu 24.04対応

GA版の品質向上。細かなバグの改修をリビジョンを上げつつリリースしていく
・処理性能の向上

・バグ回収

・SQLサポートの強化
--優先度:中 (一部は3Q以降を予定)

---クエリー
Sub-queries

---式
LIKE
EXISTS
IN with sub-queries

---型
BINARY
BOOLEAN
TINYINT/SMALLINT
Blob(JSON)については必要性は認識しているので、検討課題としている

・運用ツールの強化(有償)
--Altimeter
監査ログやメトリクス項目の拡充を行う

・3QでGA追加可能なβ機能のリリース

□2024年度:3Q

[概要]
サポートプラットフォームの拡大
 ・Red Hat Enterprise Linuxのサポート

GAの機能エンハンスメントを予定する。現在の想定は以下になる
・C++インターフェイスの拡張(案件ベース)
・spilloutの実装リリース

□2024年度:4Q

分散環境対応の最初の機能リリースを予定
・full-replicationのβリリース
・可能であれば分散トランザクション対応のαリリース

この記事が気に入ったらサポートをしてみませんか?