ScalarDB 製品概要 / ScalarDB Overview (Ver. 202601)

Transcript

1. ScalarDB 製品概要 Ver. 202601
2. © 2026 Scalar, inc. 免責事項 本資料に記載された情報は、作成時点で入手可能な情報に基づき作成されていますが、そ の正確性、完全性、最新性を保証するものではありません。 本資料の内容は予告なく変更されることがあります。本資料は情報提供のみを目的とする ものであり、契約上の義務や保証を構成するものではありません。
3. © 2026 Scalar, inc. Scalarの製品 データマネジメントの未来を創る Scalarは、独自のデータ管理技術を用いてデータマネジメントの未来を創ること目指 しています。現在は、ScalarDB と ScalarDL と呼ばれる2つの主要製品を開発・販売 しており、これらは既存のデータベースではうまく扱えない信頼性の課題を解決しま す。 汎用的なデータベース仮想化(Universal HTAP)エンジン データベースにおける改ざん検知ミドルウェア データの整合性やデータ管理の複雑性の課題を解決します。複数 のデータベースにまたがるトランザクションや分析クエリを一元 的に管理します。マイクロサービス間や企業間でデータベースを 正しく管理したいユースケースで活用いただけます。 データの真正性の課題を解決します。データベースにおける改ざ ん等の故障（ビザンチン故障）を正しく、かつ、スケーラブルに 検知します。デジタルデータに証拠姓（真正性）を付与したい ユースケースで活用いただけます。 https://github.com/scalar-labs/scalardb https://github.com/scalar-labs/scalardl 3
4. © 2026 Scalar, inc. 概要 1
5. © 2026 Scalar, inc. ScalarDB の動機 • 複数の多様なデータベースがあふれる世界 ◦ エンタープライズにおけるデータベースのサイロ化 ◦ マイクロサービス・データメッシュ化によるドメインごとのデータベース分離 ◦ “One size does not fit all” (e.g., AWSにおけるデータベース製品） Federated Transaction Manager Complex and inconsistent Simplified and consistent データベースを仮想化して複数データベースを扱う複雑性を軽減したい
6. © 2026 Scalar, inc. ScalarDB: 汎用的なデータベース仮想化（Universal HTAP）エンジン • 複数・異種のデータベースを仮想的に統合 ◦ トランザクション・分析クエリ等の多様なワークロードに対応 ◦ 複数のデータベースを扱う複雑性・煩わしさからユーザを解放 App App App BI ML Relational Databases NoSQL NewSQL Data Lakes Vector Stores Vector Store は別インターフェースにより対応 のため、トランザクション・分析クエリは非対応 Azure AI Search AlloyDB Blob Storage Cloud Storage Blob Storage Private Preview
7. © 2026 Scalar, inc. Universal HTAP: 組織の垣根を超えるHTAP • 組織の統合を必要としないHTAPエンジン ◦ トランザクション処理、分析処理、カタログ管理、ガバナンスを仮想的に統合し組織横断で実行 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Domain (Operational) Microservice 1 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Microservice 2 DWH / DL Query Engine (L2) BI / ML / AI Query Engine (L1) Catalog & Governance Catalog ETL/ELT Domain (Analytical)
8. © 2026 Scalar, inc. ScalarDB におけるデータベース仮想化 (Universal HTAP) の戦略 8 トランザクション一貫性（強い） トランザクション一貫性（弱い） OLTP OLAP トランザクション処理仮想化 (ScalarDB Cluster) ストレージ処理仮想化 (ScalarDB Cluster) アナリティクス処理仮想化 (ScalarDB Analytics) 広範なデータベース仮想化 (Universal HTAP) を実現する製品へ 少数の大量読み 出し問い合わせ 多数の少量読み 書き問い合わせ
9. © 2026 Scalar, inc. 競合製品 9 トランザクション一貫性（強い） トランザクション一貫性（弱い） OLTP OLAP トランザクション処理仮想化 ストレージ処理仮想化 アナリティクス処理仮想化 競合製品は一部の領域のみに対応 Lakehouse Federation Virtuality MicroT x
10. © 2026 Scalar, inc. ScalarDB - 他のデータベース仮想化製品との比較 10 アナリティクス仮想化 （対象ワークロード: 少数の 大量データ読み出し処理） ストレージ仮想化 （対象ワークロード: 多数の 読み書き処理に特化） トランザクション仮想化 （対象ワークロード: 多数の トランザクショナルな読み書き処理） Denodo ◦ X X Trino / Starburst ◦ X X JBoss DV △ ◦ X Oracle BI △ ◦ X Oracle MicroTx X △ △ （XA-compliantなDBのみ） Atomikos X △ △ （XA-compliantなDBのみ） ScalarDB ◦ ◦ ◦ （多様なDBに対応）
11. © 2026 Scalar, inc. ScalarDBアーキテクチャ • データベース抽象化層の上で、トランザクションと分析問合せを実行 ◦ データベースを跨るトランザクションと分析問合せが可能に … Transaction Manager Database Abstraction DB1 Shim App App App App App App DB1 DB2 DB3 DB1 DB2 DB3 CRUD Interface SQL GraphQL DB2 Shim DB3 Shim DB-specific Protocols gRPC (HTTP/2) gRPC (HTTP/2) DB-specific Protocols TxID TxID ScalarDB ScalarDB core component (Apache 2) Note: You can directly use ScalarDB core through its library. Query Engine SQL 11
12. © 2024 Scalar, inc. ScalarDB アーキテクチャ (v3.16) Third-party Connector ・・・ Vector Stores (Non-ScalarDB-managed) Data Sources (Non-ScalarDB-tran saction managed) DB Adapter 1 DB Adapter 2 DB Adapter N ・・・ Database Abstraction Transaction Manager Core Clustering Encryption AuthN/AuthZ Attribute-based Access Control Cluster Spark Catalog Intelligent Caching Analytics ScalarDB Connector Vector Store Abstraction CRUD (Library) SQL/GraphQL/CRUD (HTTP/2) SQL/Dataset Langchain4j ScalarDB-transaction-managed* tables * ScalarDB-transaction-managed tables: tables or data that are managed under ScalarDB Storage Manager. Coordinator Catalog
13. © 2025 Scalar, inc. • DBのレコードを1つの小さいデータベースと見立て、複数のレコードに対して2PC (ConsensusCommit) を実現することにより、グローバルトランザクションを実現 ◦ WALを各レコードに分散配置 (Distributed/Disaggregated WAL) ◦ CoordinatorにPaxosベースのDBを使うことで、Paxos Commitのような形態も可 User-defined tables Version TxID Before Col Before Version Before TxID Before Image TxStatus Before TxStatus Col PK After Image 1. Prepare Records w/ W-set 1. Prepare Records w/ W-set 3. Commit Records 3. Commit Records 2. Commit Status TxID Metadata TxStatus Application data managed by users Transaction metadata managed by ScalarDB R/W sets Coordinator User-defined tables 13 トランザクション仮想化の概要（トランザクションプロトコル概要） 13
14. © 2025 Scalar, inc. アナリティクス仮想化の概要 • トランザクション管理下、非トランザクション管理下のデータベースに対して統一 的な問い合わせ実現 14 SQL (OLTP) SQL (OLAP) Cluster Analytics ScalarDB-transaction- managed data sources ・・・ Read-write operations Read-only operations Non-ScalarDB-transaction- managed data sources
15. © 2026 Scalar, inc. アナリティクス仮想化の仕組み … Transaction Manager Database Abstraction DB1 Shim CRUD Interface SQL GraphQL DB2 Shim DB3 Shim Analytics SQL ScalarDB Connector Catalog Community Connectors Analytics 15 • ScalarDB Connector と Community Connectors を組み合わせて、トランザクショ ン管理下、非トランザクション管理下双方のデータベースを読み出し • ScalarDB Connector （+Read-Committed 分離）により、Analytics からの読み出 しがトランザクションの書き込みにブロックされずに実行可能 Spark
16. © 2026 Scalar, inc. 主要機能と最近の取り組み 2
17. © 2025 Scalar, inc. 認証・認可
18. © 2025 Scalar, inc. 認証・認可 • 複数データベースにおけるテーブルレベルのアクセス可否を一元的に制御 • ユーザ、ロールごとにアクセス制御が可能 User X User Y Role_Project1 Sales Marketing Role_Project2
19. © 2025 Scalar, inc. 暗号化
20. © 2025 Scalar, inc. データ暗号化 • ScalarDB のレイヤで各DBに格納するデータの暗号化（カラムレベル暗号化） ◦ 透過的であるため、アプリケーションの書き換えは不要 ◦ KMS, Encryption-as-a-service 連携して安全に鍵を管理 App App App KMS Encryption-as-a Service (Hashicorp Transit) Encrypt/Desrypt KEK K8s Master DEK
21. © 2025 Scalar, inc. 属性ベースの細粒度アクセスコントロール（ABAC)
22. © 2026 Scalar, inc. 属性ベースの細粒度アクセスコントロール（ABAC) • レコードレベルでアクセス可否を制御する機能 ◦ ユーザの属性（タグ）とデータの属性（タグ）によりアクセス制御 ▪ マッチすればアクセス可能、マッチしなければアクセス不能 ◦ 各種データベースの行レベルセキュリティ（Row-level Security）に類似の機能 • これまでの認証認可機構はテーブルレベルでのみアクセス可否を制御 Sensitive:Alpha,Beta PROJECT_NAME PROJECT_DETAILS DATA_TAG (hidden) Project A Sensitive:Alpha,Beta Project B Highly Sensitive: Beta Project C Sensitive:Gamma Project D Sensitive:Alpha ユーザ属性 ABAC 管理化のデータ 22 Attribute-Based Access Control
23. © 2026 Scalar, inc. ABAC の特徴 • ユーザとデータの属性（タグ）を定義することでマッチングロジックを定義 ◦ 通常の行レベルセキュリティの設定で用いられるストアドプロシージャは不要 • レベル、コンパートメント、グループの三つの要素から属性を定義可能 Highly Sensitive Sensitive Confidential Alpha Beta Gamma Asia Japan Korea 機密性を定義するために使用します。 例: 社外秘、秘密、極秘など。 Levels (required) Compartments (optional) Groups (optional) 同じレベルのものを区分けするために使用します。 例: 人事、財務、経理や、プロジェクト名など。 組織や階層構造を定義するために使用します。階層構造 を持つコンパートメントとして見ることができます。 例: 国や部門など。
24. © 2026 Scalar, inc. ABAC のメリット • 複数のDBに対する細かいアクセス制御を ScalarDB 上で一元管理することが可能 ◦ DB個別・固有の設定は不要 ◦ 行レベルセキュリティを有しないDBに対してもアクセス制御を実現可能 Application X Application Y ABAC ABAC
25. © 2025 Scalar, inc. ベクトルストア抽象化
26. © 2026 Scalar, inc. ベクトルストア抽象化 • RDB、NoSQL/NewSQL に加えて、Vector Store も仮想的に統合 • 主要なベクトルストアと埋め込みモデルに対応 ◦ ScalarDB Cluster 内部でLangChain4j を活用 App App App BI ML Vector Stores Azure AI Search Embedding Models Amazon Bedrock Azure OpenAI Google Vertex AI OpenAI LangChain4j
27. © 2026 Scalar, inc. ベクトルストア抽象化の特徴 • ベクトルストアの抽象化インターフェースにより特定のベクトルストアに依存しな い形でアプリケーションを記述可能 // ScalarDB Cluster 設定に基づき、 EmbeddingStore と EmbeddingModel を作成 ScalarDbEmbeddingClientFactory embeddingClientFactory = ScalarDbEmbeddingClientFactory.builder(). .withProperty("scalar.db.embedding.client.contact_points", …) .withProperty("scalar.db.embedding.client.store", “store1") .withProperty("scalar.db.embedding.client.model", "model1") .build()); EmbeddingStore<TextSegment> embeddingStore = embeddingClientFactory.createEmbeddingStore(); EmbeddingModel embeddingModel = embeddingClientFactory.createEmbeddingModel(); // 埋め込みをベクトルストアに追加 TextSegment segment = TextSegment.from("I like football."); Embedding embedding = embeddingModel.embed(segment).content(); embeddingStore.add(embedding, segment); // 埋め込みを検索 Embedding queryEmbedding = embeddingModel.embed("What is your favourite sport?").content(); EmbeddingSearchResult<TextSegment> result = embeddingStore.search( EmbeddingSearchRequest.builder().queryEmbedding(queryEmbedding).build()); } scalar.db.embedding.enabled=true # embedding store configuration scalar.db.embedding.stores=store1,store2 # Configure store1 scalar.db.embedding.stores.store1.type=opensearch scalar.db.embedding.stores.store1.opensearch.server_url=... scalar.db.embedding.stores.store1.opensearch.api_key=... scalar.db.embedding.stores.store1.opensearch.user_name=... scalar.db.embedding.stores.store1.opensearch.password=... scalar.db.embedding.stores.store1.opensearch.index_name=... # Configure store2 scalar.db.embedding.stores.store2.type=azure-ai-search scalar.db.embedding.stores.store2.azure-ai-search.endpoint=... scalar.db.embedding.stores.store2.azure-ai-search.api_key=... scalar.db.embedding.stores.store2.azure-ai-search.index_name =... scalar.db.embedding.stores.store2.azure-ai-search.dimensions =... # embedding model configuration … ScalarDB Cluster configuration
28. © 2026 Scalar, inc. ベクトルストア抽象化のメリット • LLM/RAG のための一連の処理を ScalarDB 経由で記述可能 ◦ RAG: Retrieval-Augmented Generation Training LLM Embedding Query データソース ベクトルストア 外部データソース
29. © 2025 Scalar, inc. 遠隔レプリケーション (3.16 -)
30. © 2026 Scalar, inc. 遠隔レプリケーション • 複数DC（リージョン）で半同期的にレプリーションを行う機能 ◦ プライマリ災害時に 目標復旧時点(RPO)=0 でセカンダリでサービス復旧（事業継続）が可能 ◦ 目標復旧時間(RTO) は全体のリソースを増強することにより短い時間を実現可能 Application Primary Logs Secondary Application 30
31. © 2026 Scalar, inc. 遠隔レプリケーション • コミットログ（+Coordinatorテーブル）を複数DCに同期的に跨る分散データベース に書くことにより、1DCでの大規模障害が発生時でもサービス継続が可能 • ScalarDB の特性を活かし、プライマリとセカンダリで異なるクラウドやデータベー スの組み合わせが可能 • 現状は、当該分散データベースとして、以下をサポート ◦ Azure Cosmos DB ◦ YugabyteDB • 3.16ではPrivate Previewで提供 31
32. © 2025 Scalar, inc. トランザクション処理性能の大幅な高速化 (3.16 -)
33. © 2025 Scalar, inc. トランザクション処理性能の大幅な高速化 • ScalarDBの抽象化層に、各データベースの処理特性を考慮した実行の仕組みを導入 ◦ 各DBアダプタは原子性（Atomicity）を保証できる範囲を宣言 • トランザクション処理の一部を下位のデータベースにプッシュダウン（積極的な処 理移譲）することが可能に ◦ 原子性を保証できる範囲に収まる書込みは1Txnで実行 • ScalarDBにおけるトランザクション処理のオーバーヘッドを大幅に削減 Task Push-down
34. © 2025 Scalar, inc. 単一データベースの場合の例 1.READ(x) 2.READ(y) 3.WRITE(x) 4.WRITE(y) Transaction R(x) R(y) W(x) W(y) W(c) W(x) W(y) 2R + 5W Compiled Transacton 1.READ(x) 2.READ(y) 3.WRITE(x) 4.WRITE(y) Transaction R(x) R(y) W(x,y) 2R + 1W （ScalarDBなしの場合と同じ読み書き数） Compiled Transacton
35. © 2025 Scalar, inc. 複数データベースの場合の例 Coordinator 1.READ(x) 2.READ(z) 3.WRITE(x) 4.WRITE(y) 5.WRITE(z) 6.WRITE(w) Transaction R(x) W(y) Compiled Transacton W(x) W(x) W(y) W(c) R(z) W(w) W(z) W(z)W(w) 1.READ(x) 2.READ(z) 3.WRITE(x) 4.WRITE(y) 5.WRITE(z) 6.WRITE(w) Transaction R(x) Compiled Transacton W(x,y) W(x,y) W(c) R(z) W(z,w) W(z,w) 2R + 9W 2R + 5W Coordinator
36. © 2025 Scalar, inc. トランザクションメタデータの分離 (3.17 -)
37. © 2026 Scalar, inc. トランザクションメタデータの分離 • トランザクションメタデータをアプリケーションデータと分離可能に ◦ 既存データベースからの移行においてスキーマの変更が不要に • メタデータを同一インスタンス内（の別データベースまたは別テーブル）に保持す ることにより、大幅な性能劣化は回避可能 Table X App Data Metadata Table Y Metadata
38. © 2025 Scalar, inc. 読み出し処理の高速化 (3.16 -)
39. © 2025 Scalar, inc. 読み出し処理の高速化 • Read-Committed 分離のサポート ◦ 読み出しが書き込みにブロックされずに実行可能に（AfterイメージがPrepare 中であっても、コミット済みのBeforeイメージを読み出し可能に） • Read-only トランザクションのサポート ◦ BEGIN READ ONLY / beginReadOnly() ◦ Pause 時であってもRead-only トランザクションは実行可能 • Read のみで構成されるトランザクション処理におけるコミット処理の高速化 ◦ コミット処理におけるCoordinator への書き込みをスキップ ◦ 設定により書き込みをすることも可能
40. © 2025 Scalar, inc. Batch API & Piggyback化によるレイテンシの削減 (3.17 -)
41. © 2025 Scalar, inc. Batch API & Piggyback化によるレイテンシの削減 (3.17 -) • Batch API ◦ 多数のオペレーションを一回の1ラウンドトリップで実行 ◦ 逐次的なオペレーション実行と比べて、レイテンシの大幅な削減を実現 • Piggyback化 ◦ Begin()処理やCommit()処理を他のオペレーションに合わせて実行 Client Cluster Commit Client Cluster Begin Write1 Write2 Write3 Read Begin, Write1, Write2, Read Begin Write1 Write2 Write3 Write3, Commit RTの削減によりトランザク ションレイテンシを削減
42. © 2025 Scalar, inc. デプロイのGUI化 (3.16 -)
43. © 2026 Scalar, inc. GCP Marketplace • Omnistrate社との連携によりBYOA (Bring Your Own Account) SaaSを実現 ◦ 自社のクラウド環境にGUI操作でScalarDBをデプロイを可能に ◦ Scalarとの直接契約なしにScalarDB Clusterを使用可能 44
44. © 2025 Scalar, inc. ScalarDB MCPサーバー (3.16 -)
45. © 2025 Scalar, inc. ScalarDB MCP Server • 異種・複数のデータベースに対して自然言語で問い合わせが可能に • データベースごとのMCPサーバのデプロイは不要 MCP Host / LLM (e.g., Claude Desktop) MCP Client MCP Server A DB A MCP Server B DB B MCP Server C DB C MCP Client MCP Client 自然言語問合せ MCP Host / LLM (e.g., Claude Desktop) DB A ScalarDB MCP Server DB B DB C MCP Client 自然言語問合せ
46. © 2025 Scalar, inc. ScalarDB MCP Server 問い合わせ: Show me customer information along with their order details for customers located in São Paulo state. I want to see the customer ID, city, state, order ID, and order status.Please join the customers and orders tables and limit the results to 10 records. 実行クエリ: SELECT c.customer_id, c.customer_city, c.customer_state, o.order_id, o.order_status FROM olist.customers AS c INNER JOIN olist.orders AS o ON c.customer_id = o.customer_id WHERE c.customer_state = 'SP' LIMIT 10
47. © 2026 Scalar, inc. 詳細 3
48. © 2026 Scalar, inc. ScalarDBの技術的選択 49 Multi-level Transaction Management (e.g., Oracle Tuxedo, Atomikos, Seata XA) Single-level Transaction Management (e.g., Deuteronomy [CIDR’11], Cherry Garcia [ICDE’15]) Pros: XAなど 既存製品がある Pros: 性能を上げやすい Cons: データベース依存度が高い Cons: アプローチが 侵襲的 Pros: データベース依存度が低い Pros: アプローチが侵襲的でない Cons: 弱い分離性 Cons: 性能が上げにくい TM (Coordinator) Abstraction Abstraction TM Abstraction TM DB1 Global Transactions Local Transactions DB2 TM: Transaction Manager TM (Coordinator) Abstraction DB1 Global Transactions Local Transactions DB2 CC: Concurrency Control No CC is required No CC is required
49. © 2026 Scalar, inc. ScalarDBの技術的選択 50 Pros: XAなど 既存製品がある Pros: 性能を上げやすい Cons: データベース依存度が高い Cons: アプローチが 侵襲的 Pros: データベース依存度が低い Pros: アプローチが侵襲的でない Cons: 弱い分離性 Cons: 性能が上げにくい ScalarDB アプローチ ScalarDBが解決 Multi-level Transaction Management (e.g., Oracle Tuxedo, Atomikos, Seata XA) Single-level Transaction Management (e.g., Deuteronomy [CIDR’11], Cherry Garcia [ICDE’15]) TM (Coordinator) Abstraction Abstraction TM Abstraction TM DB1 Global Transactions Local Transactions DB2 TM: Transaction Manager TM (Coordinator) Abstraction DB1 Global Transactions Local Transactions DB2 CC: Concurrency Control No CC is required No CC is required
50. © 2026 Scalar, inc. ScalarDBの設計目標 • データベース非依存性（Database Agnoticism） ◦ グローバルトランザクションが様々なデータベースに対して動作 ◦ これを最も重要なゴールとして位置付け • 強い正確性（Strong Correctness） ◦ グローバルトランザクションがACIDかつStrict Serializabilityを保証* • 妥当な性能（Reasonable Performance） ◦ グローバルトランザクションの調停が性能のボトルネックにならない • 高いスケーラビリティ（High Scalability） ◦ グローバルトランザクションの性能が下位データベースに性能に基づきスケール • 高い可用性（High Availability） ◦ グローバルトランザクションの調停において高い可用性を実現可能 * Analytics Read-Committedを保証 51
51. © 2026 Scalar, inc. ScalarDBのトランザクションプロトコル概要（１） • Cherry Garcia [ICDE’15] をベースに拡張 ◦ 下位データベースへの条件： ▪ レコードの読み書きがLinearizableにできること ▪ レコードにメタデータを付与できること • コミットプロトコル：二相コミットの拡張 ◦ Prepareフェーズ -> Commitフェーズ1 -> Commitフェーズ2 ◦ 分散WAL（Write Ahead Logging）により多様なデータベースに対応（後述） • 並行性制御：楽観的並行性制御（OCC） ◦ Linearizableな条件付き書き込みにより競合を検出 ◦ Cherry Garciaを改善し、Strict Serializababilityを保証（後述） 52
52. © 2026 Scalar, inc. （補足）Strict Serializability, Linearizability, Serializability • Strict Serializability: Linearizability + Serializability • Linearizability: ◦ 一つのオブジェクトに対するオペレーションの挙動においてリアルタイム性を保証する性 質 ◦ 書き込みが完了したら、その後の読み込みは、その書き込みまたはその後の書き込みの結 果を読む • Serializability: ◦ 複数のトランザクションの実行結果が、それらを逐次実行した結果と同一になることを保 証する性質 • 例）T1でAを書き込んでコミットして、その後に、T2でAを読み込む ◦ Serializabilityのみを保証するデータベース ▪ T1 -> T2 または T2 -> T1 で実行された結果と同一になることを保証 ◦ Strict Serializabilityを保証するデータベース ▪ T1 -> T2 で実行された結果と同一になることを保証 53
53. © 2026 Scalar, inc. ScalarDBのトランザクションプロトコル概要（２） • 分散WAL（Write Ahead Logging）により多様なデータベースに対応 ◦ ログをレコードに分散させ、一つのレコードを一つのデータベースに見立てる ◦ CoordinatorテーブルをPaxos等で複製を管理するDBで保管すればPaxos Commit のような 形態も可能 • 異種のデータベースに対しても同じ抽象化を実施することによりデータベース間の 差異を吸収 Version TxID Before Col Before Version Before TxID Before Image TxStatus Before TxStatus Col PK After Image TxID Metadata TxStatus アプリケーション が管理するデータ ScalarDBが管理す るメタデータ User-defined Table Coordinator Table 54
54. © 2026 Scalar, inc. トランザクションの挙動 - 実行フェーズ Database 1 UserID Balance Status Version 1 100 C 5 TxID XXX Database 2 UserID Balance Status Version 2 100 C 4 TxID YYY 55
55. © 2026 Scalar, inc. トランザクションの挙動 - 実行フェーズ Tx1 Tx1’s memory space Database 1 UserID Balance Status Version 1 100 C 5 TxID XXX Database 2 UserID Balance Status Version 2 100 C 4 TxID YYY 56
56. © 2026 Scalar, inc. トランザクションの挙動 - 実行フェーズ Tx1 Tx1’s memory space Database 1 UserID Balance Status Version 1 100 C 5 TxID XXX Database 2 UserID Balance Status Version 2 100 C 4 TxID YYY UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY Linearizableな読み込み 57
57. © 2026 Scalar, inc. トランザクションの挙動 - 実行フェーズ Tx1 Tx1’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 Tx1: Transfer 20 from 1 to 2 Database 1 UserID Balance Status Version 1 100 C 5 TxID XXX Database 2 UserID Balance Status Version 2 100 C 4 TxID YYY 58
58. © 2026 Scalar, inc. トランザクションの挙動 - Prepareフェーズ Tx1 Tx1’s memory space Database 1 UserID Balance Status Version 1 100 C 5 TxID XXX Database 2 UserID Balance Status Version 2 100 C 4 TxID YYY UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 Linearizableな書き込み （TxIDとバージョンが読んだも と変わってなかったら） 59
59. © 2026 Scalar, inc. トランザクションの挙動 - Prepareフェーズ Tx1 Tx1’s memory space Database 1 UserID Balance Status Version 1 80 P 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 P 5 TxID Tx1 UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 60
60. © 2026 Scalar, inc. トランザクションの挙動 - Prepareフェーズ Tx1 Tx1’s memory space Database 1 UserID Balance Status Version 1 80 P 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 P 5 TxID Tx1 UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 Tx2 Tx2’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 70 P 6 Tx2 2 130 P 5 Tx2 Tx2: Transfer 30 from 1 to 2 61
61. © 2026 Scalar, inc. トランザクションの挙動 - Prepareフェーズ Database 1 UserID Balance Status Version 1 80 P 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 P 5 TxID Tx1 書き込み失敗 （TxIDとバージョンが 読んだも と変わってい るから） Tx1 Tx1’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 Tx2 Tx2’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 70 P 6 Tx2 2 130 P 5 Tx2 62
62. © 2026 Scalar, inc. トランザクションの挙動 - Commitフェーズ1 Database 1 UserID Balance Status Version 1 80 P 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 P 5 TxID Tx1 Coordinator (on Database 1 or 2 or 3) Status C TxID XXX C YYY A ZZZ Tx1 Tx1’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 63
63. © 2026 Scalar, inc. トランザクションの挙動 - Commitフェーズ1 Coordinator (on Database 1 or 2 or 3) Status C TxID XXX C YYY A ZZZ C Tx1 Linearizableな書き込み （TxIDが存在しなけれ ） Tx1 Tx1’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 Database 1 UserID Balance Status Version 1 80 P 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 P 5 TxID Tx1 64
64. © 2026 Scalar, inc. トランザクションの挙動 - Commitフェーズ2 Database 1 UserID Balance Status Version 1 80 C 6 TxID Tx1 Database 2 UserID Balance Status Version 2 120 C 5 TxID Tx1 Coordinator (on Database 1 or 2 or 3) Status C TxID XXX C YYY A ZZZ C Tx1 Linearizableな書き込み （TxIDが自分であるなら） Tx1 Tx1’s memory space UserID Balance Status Version 1 100 C 5 TxID XXX 2 100 C 4 YYY 1 80 P 6 Tx1 2 120 P 5 Tx1 65
65. © 2026 Scalar, inc. リカバリー処理 Prepare フェーズ Commit フェーズ1 Commit フェーズ2 TX1 • トランザクションのリカバリー処理は遅延的に実行 ◦ 未コミットのデータが外界に見えることはない リカバリー不要 （DBに 何も書き込 みがないため） リカバリー処 理 TX1が書いたレコード を別 トランザクション が読み込んだ際に、 Beforeイメージを使っ てロールバック TX1が書いたレコード を別 トランザクション が読み込んだ際に、 ロールフォワード（ Pを Cに書き換える） リカバリー不要 Crash 66
66. © 2026 Scalar, inc. TrueTime等の信頼できるクロックへの依存を排除 • ScalarDBのベースとなるCherry GarciaプロトコルはTrueTime依存 • ScalarDBにおいては、高い適用性とスケーラビリティを考慮して、TrueTime等の信 頼できるクロックへの依存を排除 ◦ 1バージョンOCCのみを提供（Cherry Garciaは、2バージョンOCC/MVCC） ◦ 排除するだけでは、弱い分離性のみを保証（read-committed SI / RCSI） • HLC（ハイブリッド論理クロック）は不使用 ◦ ScalarDBでHLCを実装するには、オペレーションの前後関係（happened-before relation）を管理するために追加でデータベースへの書き込みが必要なため 67
67. © 2026 Scalar, inc. トランザクションを Strict Serializable へ • 基本戦略：反依存 (anti-dependency) を暗に追跡 ◦ ScalarDBは、明に反依存を追跡する方法 (e.g., SSI [SIGMOD’08], SSN [VLDBJ’15]) との 相性が悪い ◦ SSI/SSNより保守的だが、ScalarDBアーキテクチャとの相性を重視 TM TM R/W sets R-set ScalarDB クライアントベース プ ロトコルと相性が悪い TM TM R/W sets Write R-set 多数 DB読み書きが発生 R-set Read R/W sets Re-read R-set 多数 DB読み書きなしに 効率的に実行可能 ScalarDB approach 68
68. © 2026 Scalar, inc. 性能最適化 W(X) W(Y) P(X) P(Y) C C(X) C(Y) Prepare フェーズ Commit フェーズ1 Commit フェーズ2 並列 Commit 非同期 Commit W(X) W(Y) P(X) P(Y) C C(X) C(Y) W(X) W(Y) P(X) P(Y) C C(X) C(Y) • 並列Commit：レコードのPrepare処理とCommit処理（一部）を並列に実行 • 非同期Commit：レコードのCommit処理を非同期に実行 こ 時点で クライアントに返却 69
69. © 2026 Scalar, inc. トランザクション一貫性を保持したバックアップ • ScalarDBサーバを一時停止してアクティブなトランザクションが存在しない状態 （静止状態）を作成 • データベース固有のバックアップ機構によりバックアップを取得 • 楽観的並行性制御の手法を応用して、静止状態が壊れていないことを確認して、 バックアップ成功を応答 Pod (container) 自動修復や自動スケールにより新し いPodが作られる可能性あり ・・・ 1. ScalarDBサーバ群を特定 . 2. アクティブなトランザク ションを終了した後一時 停止 3. バックアップを取得 4. ScalarDBサーバ群を再度チェックし、状態 等（Pod数やPod 状態）に変更がないかを 確認 Kubernetes cluster 70
70. © 2026 Scalar, inc. ScalarDBの性能特性 • 各DBインスタンス: AWS. c5d.9xlarge (18 cores, 72GB DRAM, NVMe SSD) • クライアント: c5.4xlarge • ワークロード: YCSB (1000B x 100M records), TPC-C (200-1000 warehouse) • 比較対象: Atomikos (XA), Seata (XA), ScalarDB 71 C* DL … C* DL C* DL Clients Cassandraを使用 DB DB DB PostgreSQL Scalar DL PostgreSQL Scalar DL Clients PostgreSQLおよびMariaDBを使用 ScalarDB ScalarDB PostgreSQL Scalar DL Clients PostgreSQL & Cassandra を使用 ScalarDB C* DL … C* DL C* DL DB DB DB
71. © 2026 Scalar, inc. YCSB Workload F MariaDB x 2 MariaDB & PostgreSQL PostgreSQL & Cassandra 低いオーバーヘッドでデータベース非依存性なグローバルトランザクションを実現 グローバルトランザクションのスループット (YCSB) 72
72. © 2026 Scalar, inc. Strict Serializable 化のオーバーヘッド 低いオーバーヘッドで Strict Serializabilityを保証 TPC-C MariaDB PostgreSQL 15% slowdown at most 11% slowdown at most 73
73. © 2026 Scalar, inc. スケーラビリティ (TPC-C) 下位データベース ノード数 増加に比例してスループットがほぼ線形に増加 74
74. © 2026 Scalar, inc. ユースケース 4
75. © 2026 Scalar, inc. サイロ化されたデータベースの仮想統合 Oracle Applications SQL Server PostgreSQL • アプリケーションのシンプル化を実現 • 横断の問合せ・分析が容易に
76. © 2026 Scalar, inc. マイクロサービス、データメッシュにおける安全かつ効率的なデータの管理 • 組織の統合を必要としないHTAPエンジン ◦ トランザクション処理、分析処理、カタログ管理、ガバナンスを仮想的に統合し組織横断で実行 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Domain (Operational) Microservice 1 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Microservice 2 DWH / DL Query Engine (L2) BI / ML / AI Query Engine (L1) Catalog & Governance Catalog ETL/ELT Domain (Analytical)
77. © 2026 Scalar, inc. AI駆動開発におけるデータベース基盤 • AI駆動開発の進展より、アプリケーションのマイクロサービス化が加速 ◦ マイクロサービス化によりデータベースが分離 • 複数のデータベースの効率的管理や整合性保証が肝要 Microservice 1 Microservice 2 Microservice 3 • アプリケーションコードは決定的であ るため、AI駆動開発の得意分野 • マイクロサービス化することでAIによ るコード生成の精度を確保 • データベース処理（トランザクショ ン）は非決定的であるため、AI駆動開 発の不得意分野 • ScalarDBを用いることで、データベー スの構成や種類、クラウドに依存しな いアプリケーションを構成可能
78. © 2026 Scalar, inc. 補足：マイクロサービスにおけるScalarDBの活用ポイント • 密に連携しているサービス、ドメイン間で整合性を正確に保証したい場合（かつ、 それらをモノリスでやるには複雑度が高い場合） • すべてのマイクロサービスのScalarDBでの連携はアンチパターン Microservice 1 Microservice 2 Microservice 3 Microservice 4 同期 非同期 非同期 密に連携しているサービス群
79. © 2026 Scalar, inc. アプリケーションとデータベースの疎結合化 Application Oracle • データベースの移行や一部のデータ・ワークロードの別データベースへのオフロー ドなどがアプリケーションの変更なく実現可能 Application Amazon Aurora 移行 設定変更のみ 移行不要 Application Oracle Application Oracle 設定変更のみ 移行不要 DynamoDB 一部移行
80. © 2026 Scalar, inc. 複数の用途特化型データベースの効率的な管理 • 複数データベースを操作することによるコードベースの肥大化を抑止 • データベースに依存しない統一的な操作による再利用可能なモジュール化が容易に RDB NoSQL Vector Store RDB NoSQL Vector Store Application Application
81. © 2026 Scalar, inc. ロードマップ 5
82. © 2026 Scalar, inc. 直近ロードマップ • ビュー (3.18) • 統一的な認証・認可 (3.18) • 統一的なデータカタログ (3.18) • https://scalardb.scalar-labs.com/docs/latest/roadmap
83. © 2026 Scalar, inc. ビュー（読み取り専用ビュー） Oracle Applications SQL Server PostgreSQL • 複数のDBに対して問合せた結果を別の仮想DB（ビュー）として扱うことが可能 • ビューの利用者・アプリケーションは複数のDBを意識せずにアプリケーションを作成可能に
84. © 2026 Scalar, inc. データカタログ・認証認可も仮想的に統合 • ScalarDB ClusterとScalarDB Analyticsでデータカタログ管理・認証認可を仮想的に統合 • 複数ドメインのデータカタログを仮想的に統合 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Domain (Operational) Microservice 1 Transaction Manager Query Engine (L2) Catalog & Governance Query Engine (L1) Microservice 2 DWH / DL Query Engine (L2) BI / ML / AI Query Engine (L1) Catalog & Governance Catalog ETL/ELT Domain (Analytical)