@@ -22,76 +22,90 @@ import TranslationBanner from '/src/components/_translation-ja-jp.mdx';
2222
2323:::
2424
25- ### CY2024 Q4
25+ ### CY2025 Q1
2626
2727#### 新しい機能
2828
29- - ** 分析のためのデータ仮想化**
30- - ユーザーは、ScalarDB Analytics を介してさまざまなデータソースで読み取り専用の OLAP SQL クエリを実行できるようになります。ScalarDB Analytics は現在、ScalarDB 管理のデータストアのみをサポートしているため、この機能強化により、データソースが ScalarDB トランザクションによって管理されているかどうかに関係なく、リレーショナルデータベースや NoSQL データベースなどのさまざまなデータストアと、Amazon S3 などのクラウドオブジェクトストア内のファイルが仮想的に統合されます。
3129- ** ベクトルストアの抽象化**
32- - ユーザーは、ScalarDB の新しいベクトルストアインターフェイスを介して、ベクトルストアに埋め込み (ベクトル) を保存したり、ベクトルストアから埋め込みを検索したりできるようになります 。この機能により、ユーザーは、既存の ScalarDB インターフェイスを介してデータベースからデータを読み取り、データから埋め込みを作成し、新しいインターフェイスを介してベクトルストアに埋め込みを保存したり、ベクトルストアから埋め込みを検索したりすることで 、大規模言語モデル (LLM) を使用した検索拡張生成 (RAG) を実現するプロセスを簡素化できます。
30+ - ユーザーは、ScalarDB の新しいベクトルストアインターフェースを介して、ベクトルストアに埋め込み表現 (ベクトル) を保存および検索できるようになります 。この機能により、ユーザーは、既存の ScalarDB インターフェースを介してデータベースからデータを読み取り、データから埋め込み表現を作成し、新しいインターフェースを介してベクトルストアに埋め込み表現を保存および検索することで 、大規模言語モデル (LLM) を使用した検索拡張生成 (RAG) を実現するプロセスを簡素化できます。
3331
3432#### セキュリティ
3533
36- - ** きめ細かなアクセス制御 **
37- - ユーザーは、基盤となるデータベースへのアクセスをよりきめ細かに承認できるようになります 。ScalarDB は、ユーザーが特定の操作を発行する権限を持っているかどうかを確認する現在の単純な承認に加えて、ユーザーが特定のレコードにアクセスできるかどうかも確認します 。
34+ - ** 属性ベースのアクセス制御 **
35+ - ユーザーは、基盤となるデータベースへのアクセスをよりきめ細かく制御できるようになります 。ScalarDB は、ユーザーがテーブルに対して特定の操作を発行する権限があるかどうかを制御する現在の単純な認可に加えて、ユーザーとレコードの属性に基づいて、ユーザーが特定のレコードにアクセスできるかどうかを制御します 。
3836
3937#### ユーザビリティ
4038
4139- ** 時間関連のデータ型の追加**
42- - ユーザーは時間関連のデータ型を使用できるようになり、既存のアプリケーションの移行が容易になります。
43- - ** 追加書き込み戦略の削除**
44- - ユーザーは、トランザクションをシリアル化可能にするために追加書き込み戦略を使用できなくなります。ScalarDB は現在、トランザクションをシリアル化可能にするために追加読み取り戦略と追加書き込み戦略の2つの戦略を提供していますが、追加書き込み戦略にはいくつかの制限があります。たとえば、ユーザーは同じトランザクションで書き込み操作とスキャン操作を発行できません。したがって、この戦略は削除され、ユーザーはアプリケーションを作成するときにこのような制限を心配する必要がなくなります。
45-
46- #### パフォーマンス
47-
48- - ** 1フェーズコミットの最適化**
49- - ユーザーは、単一のパーティションに書き込む単純なトランザクションの実行速度が速くなります。ScalarDB は、基礎となるデータベースの単一パーティション線形化可能な操作を利用して、トランザクションが1つのパーティションのみを更新する場合、正確さを犠牲にすることなく、レコード準備フェーズとコミット状態フェーズを省略します。
50- - ** ScalarDB メタデータの管理に必要なストレージ領域の削減**
51- - ユーザーは、ScalarDB を実行するために使用するストレージ領域が少なくなる可能性があります。ScalarDB は、コミットされたトランザクションがコミットされた後に、コミット前のイメージを削除します。ただし、コミットされたトランザクションが実際のストレージ領域に影響を与えるかどうかは、基礎となるデータベースによって異なります。
52- - ** 読み取り専用トランザクションのコーディネータ書き込みの削除**
53- - 読み取り専用トランザクションのコーディネータ書き込みを削除することで、ユーザーは読み取り専用トランザクションの実行速度が向上します。
40+ - ユーザーは時間関連のデータ型を使用できるようになり、既存のアプリケーションから移行が容易になります。
5441
5542#### クラウドサポート
5643
5744- ** Azure Marketplace でのコンテナオファリング**
58- - ユーザーは、 Azure コンテナオファリングを使用して ScalarDB Cluster をデプロイできるようになります。これにより、ユーザーは従量課金制のサブスクリプションモデルを利用できるようになります 。
45+ - ユーザーは Azure コンテナオファリングを使用して ScalarDB Cluster をデプロイできるようになります。これにより、ユーザーは従量課金制のサブスクリプションモデルを使用できます 。
5946- ** Google Cloud Platform (GCP) のサポート**
60- - ユーザーは、 GCP の Google Kubernetes Engine (GKE) に ScalarDB Cluster をデプロイできるようになります。
47+ - ユーザーは GCP の Google Kubernetes Engine (GKE) に ScalarDB Cluster をデプロイできるようになります。
6148
62- ### CY2025 Q1
49+ ### CY2025 Q2
6350
6451#### 新しい機能
6552
6653- ** ネイティブセカンダリインデックス**
6754 - ユーザーは柔軟なセカンダリインデックスを定義できるようになります。既存のセカンダリインデックスは、サポートされているデータベースのセカンダリインデックスの共通機能に基づいて実装されているため、制限があります。したがって、たとえば、複数列のインデックスを定義することはできません。新しいセカンダリインデックスは ScalarDB レイヤーで作成されるため、複数列のインデックスなど、より柔軟なインデックスを作成できます。
6855
56+ #### 追加のデータベース
57+
58+ - ** Databricks**
59+ - ユーザーは、ScalarDB Cluster を介して基盤となるデータベースとして Databricks を使用できます。
60+ - ** Snowflake**
61+ - ユーザーは、ScalarDB Cluster を介して基盤となるデータベースとして Snowflake を使用できます。
62+
6963#### ユーザビリティ
7064
71- - ** 集計用の SQL 操作の追加**
72- - ユーザーは ScalarDB SQL で集計操作を発行できるようになります。
73- - ** 大規模なスキャンによるメモリ不足エラーの排除**
74- - ユーザーはメモリ不足エラーを経験することなく大規模なスキャンを発行できるようになります。
75- - ** 一時停止期間中の読み取り操作の有効化**
76- - ユーザーは一時停止期間中でも読み取り操作を発行できるため、バックアップを取りながらデータを読み取ることができます。
77- - ** より多くのデータタイプの追加**
78- - ユーザーはより多くのデータタイプを使用できるようになるため、既存のアプリケーションの移行が容易になります。
65+ - ** 10進データ型の追加**
66+ - ユーザーは10進データ型を使用できるため、10進数を高精度で処理できます。
67+ - ** Extra-write strategy の削除**
68+ - ユーザーは、トランザクションをシリアライザブルにするためのオプションである extra-write strategy を使用できなくなります。ScalarDB は現在、トランザクションをシリアライザブルにするために2つの戦略 (extra-read strategy と extra-write strategy) を提供していますが、extra-write strategy にはいくつかの制限があります。たとえば、ユーザーは同じトランザクションで書き込み操作とスキャン操作を発行できません。したがって、この戦略は削除され、ユーザーはアプリケーションを作成するときにこのような制限について心配する必要がなくなります。
69+ - ** ScalarDB Analytics のガバナンスの改善**
70+ - ユーザーは、ScalarDB Core 機能を使用して認証および認可できるようになります。
7971
80- ### CY2025 Q2 -
72+ #### パフォーマンス
73+
74+ - ** ScalarDB Analytics での WAL-interpreted view の削除**
75+ - ユーザーは、WAL-interpreted view の代わりに ScalarDB Core を使用してコミットされたデータを読み取ることができます。これにより、性能の改善が期待できます。
76+
77+ ### CY2025 Q3
8178
8279#### ユーザビリティ
8380
8481- ** ビュー**
85- - ユーザーはビューを定義して、複数の異なるデータベースをより簡単かつ簡素化された方法で管理できるようになります。
82+ - ユーザーは、複数の異なるデータベースをより簡単でシンプルな方法で管理できるように、ビューを定義できるようになります。
83+ - ** 集計用の SQL 操作の追加**
84+ - ユーザーは、ScalarDB SQL で集計操作を発行できるようになります。
85+ - ** 大規模スキャンによるメモリ不足エラーの排除**
86+ - ユーザーは、メモリ不足エラーを経験することなく、大規模スキャンを発行できます。
87+ - ** 一時停止期間中の読み取り操作の有効化**
88+ - ユーザーは、一時停止期間中でも読み取り操作を発行できるため、バックアップを取りながらデータを読み取ることができます。
8689
8790#### スケーラビリティと可用性
8891
8992- ** 半同期レプリケーション**
90- - ユーザーは、災害復旧可能な方法で ScalarDB ベースのアプリケーションを提供できます。たとえば、東京でプライマリサービスを提供し、大阪でスタンバイサービスを提供するとします。東京で壊滅的な障害が発生した場合、プライマリサービスを大阪に切り替えることで、データ損失や長時間のダウンタイムなしにサービスを継続できます。
93+ - ユーザーは、災害復旧可能な方法で ScalarDB ベースのアプリケーションのデータを複製できます。たとえば、東京でプライマリサービスを提供し、大阪でスタンバイサービスを提供するとします。東京で壊滅的な障害が発生した場合、プライマリサービスを大阪に切り替えることで、データ損失や長時間のダウンタイムなしでサービスを継続できます。
94+
95+ ### CY2025 Q4
96+
97+ #### パフォーマンス
98+
99+ - ** 1フェーズコミットの最適化**
100+ - ユーザーは、単一のパーティションに書き込む単純なトランザクションの実行速度が速くなります。ScalarDB は、基礎となるデータベースの単一パーティション線形化可能な操作を利用して、トランザクションが1つのパーティションのみを更新する場合、正確さを犠牲にすることなく、レコード準備フェーズとコミット状態フェーズを省略します。
101+ - ** ScalarDB メタデータの管理に必要なストレージ領域の削減**
102+ - ユーザーが ScalarDB を実行するために使用するストレージ領域が少なくなる可能性があります。ScalarDB は、コミットされたトランザクションがコミットされた後に、コミットされたトランザクションの以前のイメージを削除します。ただし、コミットされたトランザクションが実際のストレージ領域に影響を与えるかどうかは、基礎となるデータベースによって異なります。
103+ - ** 読み取り専用トランザクションのコーディネータ書き込みの省略**
104+ - ユーザーは、読み取り専用トランザクションにおけるコーディネータ書き込みを省略することで、当該トランザクションをより早く実行できるようになります。
91105
92106#### クラウドサポート
93107
94- - ** Red Hat OpenShift のサポート **
95- - ユーザーは、OpenShift 環境で ScalarDB Cluster 用の Red Hat 認定 Helm Charts を使用できるようになります 。
96- - ** Google Cloud Marketplace でのコンテナの提供 **
97- - ユーザーは、Google Cloud コンテナの提供を使用して ScalarDB Cluster をデプロイできるようになります 。これにより、ユーザーは従量課金制のサブスクリプションモデルを利用できるようになります 。
108+ - ** Red Hat OpenShift サポート **
109+ - ユーザーは、OpenShift 環境で ScalarDB Cluster 用の Red Hat 認定 Helm Charts を使用できます 。
110+ - ** Google Cloud Marketplace のコンテナオファリング **
111+ - ユーザーは、Google Cloud コンテナオファリングを使用して ScalarDB Cluster をデプロイできます 。これにより、ユーザーは従量課金制のサブスクリプションモデルを使用できます 。
0 commit comments