はじめに
OCIのAutonomous Databaseの特徴として、マルチデータ及びマルチワークロードの利用が可能であることはよく話に聞く。
本記事ではマルチデータに注目して、1つのAutonomous Database（ADB）で、どのように複数タイプのデータを扱うことができるのか確認してみる。
今回は1つのADBで、RDBで取り扱うような構造化データ、ドキュメントDBで取り扱うJSONのようなドキュメントデータ、グラフDBで取り扱うグラフ型データと、3つのデータタイプを取り扱う。（構造化データについては詳細は触れないが、グラフDBの操作過程で作成。)
今回ADBで取り扱ったデータタイプと、データ操作に利用した手法（言語）を先に紹介する。
| データタイプ | DBタイプ | 操作 |
|---|---|---|
| 構造化データ | リレーショナル | SQL |
| JSON（非構造化データ） | ドキュメント | SODA API、SQL |
| グラフ（非構造化データ） | グラフ | PGQL |
ドキュメントデータベース
ドキュメントデータベースはその名前の通り、JSON等のドキュメント形式でデータを保存して操作する非リレーション型のデータベースである。
ADBはOracle DBなのでリレーショナルデータベースとして利用できるが、ドキュメントDBとしてJSONデータも利用することができる。
なお、ADBのワークロードタイプに"JSON"があるが、これはJSONワークロードに特化している（ちょっと安い）というだけであり、ADBのどのワークロードでもJSONを利用することができる。本記事では、Autonomous Datawarehouse（ADW）で検証を行なった。
JSONデータの操作
Simple Oracle Document Access(SODA) を利用することで、API経由でADBでJSONデータを取り扱うことができる。
- SODA
- Oracle DBのドキュメントデータ（JSONに限らない）へのアクセスに利用するAPI。
- SODAを利用して、ドキュメントデータへCRUD操作を実施することができる。
また、SODAを利用しなくても、SQLでドキュメントデータに対して操作することは可能。
（json_document等のJSON操作関数を利用）
JSONデータ操作を試してみる
本記事ではADW内にJSONデータを作成して、SODA/SQLで操作してみる。
SODA APIを叩くことができるDatabase Actionsから本操作は実施する。
（OCI コンソール ＞ Autonomous Database ＞詳細＞データベース・アクション＞SQL）
また、本項目はOCI公式のチュートリアルの内容を参考に実施している。
106: ADBでコンバージド・データベースを体験しよう（JSONデータの操作）
https://oracle-japan.github.io/ocitutorials/database/adb106-json/
SODA APIでJSONデータを作成して確認する
まずは、JSONでドキュメントを格納するコレクションを作成する。
コレクションはRDBにおける表のようなものであり、ここでは"docsample"として作成。
（Database Actionsから操作するときはsoda apiの呼び出しのため最初にsodaを宣言する）
soda create docsampl
続いて、作成したコレクション（docsample）へJSON形式でデータを挿入する。
soda insert docsample {"name":"spa metsa Otaka", "Area":"Tokyo", "rank":"1","year":"2022"}
soda insert docsample {"name":"Thermal Climb Studio Fuji", "Area":"Shizuoka", "rank":"2","year":"2022"}
soda insert docsample {"name":"The Sauna", "Area":"Nagano", "rank":"3","year":"2022"}
JSONデータの作成が完了したので、SODA API経由でデータを確認する。
作成したJSONドキュメントが格納されていることを確認できる。
soda get docsample
soda get docsample -f {"year":"2022"}
SQLでの操作
SODAを利用してJSONデータの操作を確認できたので、続いてSQLを利用してSODAで作成したJSONデータの操作を試してみる。
SQLでJSONドキュメントを操作する際はjson_document関数を利用することで、RDB形式で操作することが可能となる。
データを操作
soda get docsample
soda get docsample -f {"year":"2022"}
JSON形式で出力する際はjson_serialize関数を利用する。コンテンツの列をカッコの中で指定しており、"JSON_DOCUMENT" コレクションのデフォルトの列名である。
select json_serialize(json_document) from docsample
グラフデータベース
ADBはグラフデータベースとして操作することもできる。
グラフデータベース触れる機会は多くないかもしれないが、データ構造がRDBのようなリレーショナルでなく、ネットワークにような構造となっている。
RDBはテーブル同士を関連付けているのに対し、グラフデータベースはデータ同士を関連付けているため。リレーションを辿った検索が高速であると言われ、ソーシャルネットワーキング等で利用されている。
グラフデータの操作（Graph Studio）
ADBをグラフデータベースとして操作する手法はいくつかあるが、今回はADBの付属ツールの、「Graph Studio」を利用する。
Graph Studioを利用することで、GUI直感でグラフデータの操作が可能
- Graph変換：リレーショナルDBとしての既存テーブルをグラフ構造に変換
- Query：PGQLでのTxクエリ
- Note Book：分析目的でのノートブックサービスでのPGQLクエリ、グラフ可視化。
Graph Studioでのグラフデータ操作はPGQLを利用する。PGQLの詳細は下記サイトを参照。
PGQL詳細
https://docs.oracle.com/cd/F32587_01/spgdg/property-graph-query-language-pgql.html
グラフデータ操作を試してみる
Graph Studioを利用することで、先ほどJSONドキュメントを格納したADWへグラフデータを作成してPGQLで操作してみる。
また、本項目はOCI公式のチュートリアルの内容を参考に実施している。
215 : Graph Studioで金融取引の分析を行う
https://oracle-japan.github.io/ocitutorials/database/adb215-graph/
Graph Studioを利用したGraphデータの作成
Graph Studioを利用するにあたっての事前準備は上記チュートリアルがまとまっているので
詳細割愛するが、大まかな準備の流れと注意点だけ記載
- DB ActionsからGraph Studioを利用できるユーザを作成する
- AdminユーザはGraph Studioを操作できないので、必ず別ユーザを作成する。
- 既存テーブルを変換したい場合は、新規作成ユーザのスキーマ配下に作成しておくか、権限付与する等、作成したユーザがアクセス可能な状態とする必要があるので注意。
- ADBの「ツールバー」か、Database Actionsのメニューから「Graph Studio」へログイン
- Database Actionsからログインする場合は、一度Adminからログアウトすること
Graph Studioを利用したGraphデータへの変換
リレーショナル表のデータをグラフデータに変換する。
検証で利用するデータはチュートリアルで取得できるサンプルデータを使用した。
（実行内容はチュートリアルサイトと同様となるため詳細は割愛。）
- ログイン後、左のメニューバーからModels（上から2つ目）を選択。最初ならStart Modeling。（以降はCreateを選択）
- 自身のスキーマ配下の先ほど作成したJSONデータと、サンプルデータが確認できる。
変換するテーブルを選択して、「NEXT」を選択。
3.グラフとのマッピングを確認する
- Sorce：PGQLとしての変換コードを確認可能
- Preview：グラフの構造を確認可能
- Designer：Vertex(頂点)とEdge(辺）のマッピング
エラー等でない場合は、Create Graphを選択。
ジョブ実行画面に遷移するのでジョブが完了したら、グラフデータの作成完了。
Graph Studioを利用したグラフデータの操作
作成したグラフの操作はGraphメニューから「Query」でPGQLを発行する方法と、ノートブックメニューからPGQLを発行する手法がある。
使い分けとしてはTx系の処理を行う場合は、Graphメニューを利用、分析系の処理を行う場合はノートブックメニューから実行することが推奨されている。
Graphメニューより実行
ノートブックメニューより実行
ノートブックメニューから実行時は、何の言語で実行するか(pgql/sql等）宣言する必要がある。
終わりに
本記事では1つのAutonomous Databaseへ複数タイプのデータを格納して、リレーショナル、ドキュメント、グラフと異なるデータベースのように利用してみた。
他のクラウドプロダクトでも、例えばAWSはドキュメントDBは「Amazon Document DB」、グラフDBは「Neptune」が用意されており同様のことを実現できるが、機能ごとにサービス化するのでなく、『Converged Database」として、1つのDBマルチデータ操作を実現させるのはOCIの特徴だと考える。
SoIのような分析用途では、様々な種類のデータをデータを抽出/加工して組み合わせて分析する必要がある。データタイプごとに異なるサービスに格納している場合、連係コストが大きくなる場合もある。
一方Autonomous Database は、最初から1つの場所でマルチデータを管理することができるので、分析基盤用途として他のクラウド製品にはない強みを持っているかもしれない。