ScalarDB Clusterは、サイロ化されたデータベースを効率的に管理できます。これにより、分散したデータベースの管理が簡単になり、業務の効率化が実現します。 複数のデータベース間での整合性を維持することが可能です。システム全体で一貫性のあるデータ管理を行い、データの正確性を確保します。 データメッシュによる柔軟なデータ管理が実現します。データメッシュを活用し、複雑なデータ管理をシンプルにすることで、より適応性の高い運用が可能です。 データベース移行の負担を軽減します。移行プロセスをスムーズにし、コストや作業負荷を最小限に抑えることができます。

サイロ化されたデータベースとは、各システム内でのみ使用され、他のシステムとの連携が欠如し、孤立した状態を指します。それぞれのシステムが個別に最適化された結果、データの共有が難しくなり、データサイロ化が発生します。 例えば、部門ごとに目標や目的が異なると、各部門はそれぞれの業務プロセスに最適化されたシステムを構築します。これにより、特定の目標達成には注力しやすくなりますが、連携が取れていなければ組織全体の業務効率を低下させる可能性があります。 主な課題として、断片化されたデータベースに効果的にアクセスする方法や、データベースごとに異なるインターフェースやアクセス方法を制御する方法が挙げられます。 データが一箇所に集まっていないと、AIによる高精度なデータ分析が難しく、企業は手動でデータ分析を行うか、経験則で業務を運営せざるを得ません。 データベースの種類やアクセス方法が異なるため、他部門で収集したデータを活用することが困難になることがあります。

サイロ化されたデータベースの主な課題は、データの断片化による効率的なアクセス方法の欠如です。各データベースに個別のアクセス方法が必要となり、一元的なデータ管理が難しくなります。 各データベースが異なるインターフェースを持つため、システム全体での整合性を維持することが非常に困難です。データベースの種類ごとにアクセス方法を調整する必要があり、開発と運用コストが増加します。 各部門が個別に管理するデータベースを利用する場合、データの整合性を維持することが困難です。異なる種類のデータベース間での連携には、追加の開発が必要となり、業務効率を低下させる可能性があります。

ScalarDBは、異なるデータベースに対して統一されたインターフェイスを提供し、複数の種類のデータベースを 1 つのデータベースのように扱うことができます。 同じインターフェイスと同じアクセス方法を使用できるため、アクセスするデータベースの数が増えた場合の開発コストを削減できます。 ScalarDB は、NoSQL などの非 ACID準拠データベースに対しても ACID 機能を提供します。 その結果、NoSQL を含む複数の種類のデータベース間でトランザクションを実行できるようになり、部門データベース間のデータ整合性の管理が容易になります。

SagaパターンやTCCを使用してマイクロサービスにまたがるトランザクションシステムを開発することも可能です。 しかし、SagaパターンやTCCを使用すると、補償トランザクションが必要になります。 各データベースごとに異なるコードを書かなければならず、より複雑になり、柔軟性を失います。 様々な障害ケース、それらのテストパターンを考慮する必要があり、ロジックはさらに複雑になります。

ScalarDBは複数のマイクロサービス間でのトランザクションをサポートしており、トランザクションが必要となるマイクロサービスの開発を簡素化します。 統一されたインターフェースを使用して各データベースにアクセスできるため、異なるデータベースごとに異なるコードを記述する必要はありません。 補正トランザクションは必要なく、トランザクション実行コード自体が簡素化されます。 複数のサービスにわたる障害シナリオを考慮したり、それらのテストケースを記述したりする必要はありません。 これにより、複数のマイクロサービスにわたるアプリケーション開発が非常に効率的になります。

マイクロサービスアーキテクチャでは、各データベースは対応するサービスを通じてアクセスされます。その際、マイクロサービス間でのデータの整合性を確保することは課題となります。 アプリケーションは、SagaパターンまたはTCCを使用して補正トランザクションを実装する必要があり、これにはアプリケーションに実装する複雑なロジックが必要となります。 また、一部のNoSQLデータベースはある程度ACIDに準拠していますが、制限もあります。 マイクロサービスA、B、Cの3つのケースを考えてみましょう。マイクロサービスAはリレーショナルデータベースを管理、マイクロサービスBは制限付きのACID準拠のNoSQLデータベースを管理、マイクロサービスCはACIDに準拠していないNoSQLデータベースを管理します。 この場合、SAGAパターンなどを利用してマイクロサービスAとB間のトランザクションを実現できる可能性があります。ただし、マイクロサービスCを含むトランザクションは実現できません。

ScalarDBを使用すると、複数の種類のデータベース間でACIDトランザクションを簡単に実装でき、システム全体のデータ整合性を確保できます。 ScalarDBは、ACID非準拠のデータベースに対してもACIDトランザクション機能を提供します。NoSQLなどのデータベースでも、ACID特性を持つトランザクションが実行可能です。 複雑な補正トランザクションを実装する必要がなくなるため、開発の労力も軽減されます。開発者はよりビジネスロジックに集中でき、開発効率が向上します。

ScalarDB Clusterには、「Shared Cluster Pattern」と「Separated Cluster Pattern」の2つのデプロイパターンがあります。 Shared Cluster Patternの長所は、トランザクション管理がシンプルで、リソースの効率的な利用が可能なことです。1フェーズコミットインターフェースにより、トランザクションとエラー処理が容易になります。短所としては、マイクロサービス間のリソース分離が限定的で、マイクロサービス単位での個別リソース管理ではない点が挙げられます。 Separated Cluster Patternの長所は、マイクロサービス単位でのリソース管理が可能で、柔軟な運用ができることです。短所としては、SagaパターンやTCCと比べると容易ではありますが、トランザクション管理においてShared Cluster Patternと比べて考慮すべき点が増加します。 Separated Cluster Patternでは、複数のScalarDB Clusterインスタンスによるリソース管理の難易度が上がります。インスタンスの増加に伴い、リソースの効率化の難易度も上がりますので、最適なスケーリング戦略が必要になります。

一般的な異種データベース間での移行に関するハードルについてご説明いたします。 RDBとNoSQLの間でデータベースの適性をテストしたり、異種のデータベースに移行する際には、それぞれのデータベースに合わせてテーブル設計が必要になります。 RDBにはSQL、DynamoDBやCosmos DBにはJSONといった異なる形式でテーブル定義を行う必要があり、データベースごとに仕様やテーブル定義方法が異なることが課題になります。

ScalarDB Clusterを使用すると、JSON形式またはSQL形式で同じテーブル定義を異なるデータベースに適用できます。これにより、RDBとNoSQLの間での適性テストや移行が容易になります。 Note: Storage（Database）とNamespaceの関係は必要に応じて調整する必要があります。それぞれのデータベースの特性に合わせた設計が必要になる場合があります。 各DBの性能を最大限に引き出すためには、データベースの特性に合わせた設計が必要になります。

テーブル定義に加えて、アプリケーションのコードも通常各データベースごとに異なるため、データベースに合わせたコードが必要になります。 DynamoDB、Cosmos DB、RDBそれぞれに対して、異なるAPIやJDBCを使ったコードが必要になります。

ScalarDB Clusterを使用すると、複数の種類のデータベースに対して同じコードでデータベース操作が可能です。これにより、コードの再利用性が向上し、開発効率が向上します。 メインとなるコードに加え、当然ながらテストコードも流用可能です。テストコードの再利用は、開発時間の短縮に大きく貢献します。 Note: Storage（Database）とNamespaceの関係は適宜合わせる必要があります。それぞれのDatabaseの特性に合わせた設計が必要な場合がありますのでご注意ください。 データベースに依存しない設計、開発が行われていることが前提となります。特定のデータベースに強く依存したコードは再利用が難しくなります。

次回：1-3. ScalarDBの優位性