メインコンテンツへスキップ
見出し画像

劔"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のβリリース
    ・可能であれば分散トランザクション対応のαリリース

    あなたへのおすすめ