ODCチームスペースの魅力的な世界へようこそ

本記事は、ODCチームスペースの効率的な協働をすぐに活用できるようにするための詳細ガイドです。スペースの概要、有効化方法、および適用シナリオについて説明します。

スペースの理解：個人専用 vs チーム協働

多様な開発シナリオのニーズに応えるため、ODCプラットフォームは、異なるユーザーグループの開発要件に精密に合致するよう、個人スペースとチームスペースという2種類のスペースタイプを丁寧に設計しています。

• 個人スペース：ユーザー本人のみが操作可能で、基本的なSQL開発と12種類の一般的なチケット機能を提供し、一般的な開発シナリオをサポートします。

• チームスペース：複数人協働プラットフォームであり、基本的なSQL開発と12種類の一般的なチケット機能に加え、マルチデータベース変更、論理データベース変更、開発規範、データマスキングなどの高度な機能も提供します。

個人スペースとチームスペースの機能比較：

個人スペースとチームスペースの長所と短所の比較：

チームスペースの価値

DevOps協働の課題を突破する

一般的に、企業内では、DBA（データベース管理者）チームと開発チームの人数規模には大きな差があります。一人のDBAが百人から千人規模の開発者と連携することがあり、これらの開発者は異なるビジネスラインに分散しており、ビジネス要件も複雑多様です。

プロジェクトの推進における開発、テスト、本番環境への移行などの重要な段階では、DBAはデータベース変更プロセスに深く関与する必要があります。テーブル構造の設計と調整から、データ変更などの具体的な操作に至るまで、各段階でDBAの専門的なサポートが不可欠です。想像してみてください。もしこのプロセス全体が一時的なコミュニケーションと手動操作に依存している場合、DBAと開発者の作業体験は極めて悪化するだけでなく、オンラインでの問題発生リスクも大幅に高まり、企業のビジネスに潜在的な損失をもたらすことになります。

ODCのチームスペースは、このようなシナリオで生じる多くの課題を解決するために特別に設計されています。「独りで速く進むことはできるが、みんなで歩けば遠くまで行ける」という言葉は、チーム協働の重要性を表しています。ODCは、開発チームとDBAチームが手を取り合って進むための頼れるパートナーであり、「みんなで速く、遠くまで進む」という美しいビジョンを実現するための支えとなります。

チームスペースの推奨使用シナリオ

1. DBAと開発チームの比率が1:20未満で、データベースに対する変更リクエストが頻繁な場合。

2. ビジネスにおいてSQLの記述に規範がある場合（例：テーブル名、フィールド名の命名規則、SELECT *の禁止など）、ODCチームスペースの使用を推奨します。

3. ビジネスにおいて安定性に対する要求が高い場合（例：クエリ結果のレコード数を制限する必要がある、オフラインDDLのロックフリー変更を検出する必要がある、データエクスポートを制限する必要があるなど）、ODCチームスペースの採用を推奨します。

4. 機密データを含み、暗号処理が必要なビジネスについては、ODCチームスペースを使用したセキュリティ管理を推奨します。

5. ビジネス量が多く、期限切れデータの定期的なクリーンアップ/アーカイブが必要なシナリオについて、ODCチームスペースは効果的なサポートを提供します。

6. 開発環境、テスト環境、本番環境のデータベースおよびテーブル構造を統一する必要がある場合は、ODCのチームスペースを使用した統一管理を推奨します。

7. データベースやテーブルが分散しており、定期的な構造メンテナンスが必要な業務について、ODCのチームスペースは便利なメンテナンスツールを提供します。

8. スペース内で異常が検出された場合に通知やアラートを送信する必要があるシナリオについて、ODCのチームスペースは完備したメッセージ通知メカニズムを備えています。

チームスペースを有効化する6つの手順

ODC V4.3.4では、ダッシュボードモジュールが導入されました。ダッシュボードの クイックスタート モジュールから、チームスペースを有効化する方法をすぐに確認できます。チームスペースを有効化する前に、プロジェクト内の各概念間の関係を理解しておく必要があります。

その後、以下の6つの手順でチームスペースを迅速に有効化します：

1. データソースの登録

   デフォルトでは、システム管理者（system_adminロール）のみがデータソースを作成できます。ただし、システム管理者が ユーザー権限 モジュールでデータソース管理権限を持つロールを定義している場合、そのロールもデータソース管理操作を実行できます。データソースは、まずチームスペースに登録され、その後チームスペース内でプロジェクトに割り当てられます。

   

2. プロジェクトの作成

   デフォルトでは、システム管理者（system_adminロール）のみがプロジェクトを作成できます。ただし、システム管理者が ユーザー権限 モジュールでプロジェクト管理権限を持つロールを定義している場合、そのロールもプロジェクト管理操作を実行できます。新規プロジェクト作成時には、プロジェクト管理者とDBAを指定する必要があり、デフォルトでは、プロジェクトの作成者がプロジェクト管理者とDBAに設定されます。チームスペースはプロジェクト単位での協働を前提としているため、後続の手順を進めるには、まずプロジェクトを作成する必要があります。

   

3. 業務データベースの追加

   データソース内のデータベースは、プロジェクトに追加されて初めて、プロジェクトのメンバーがアクセスできるようになります。データベースの追加操作は、プロジェクト管理者のみが実行でき、かつプロジェクト管理者は対象データソースの編集権限を持っている必要があります。もちろん、データソース内のすべてのデータベース（今後新規作成されるものを含む）をこのプロジェクトに同期させたい場合は、データソースの編集機能を利用して、データソースを対象プロジェクトに直接紐づけることができます。

   

4. チームメンバーの管理

   データベースの追加が完了したら、協働に参加する関連するメンバーをプロジェクトに追加し、関連するプロジェクトロールを付与する必要があります。各プロジェクトロールの権限と役割は、ロール説明から確認できます。【管理者】【DBA】【開発者】は、プロジェクト内のすべてのデータベースへのアクセス権限を持っています。【セキュリティ管理者】【参加者】はデフォルトでプロジェクト内のいかなるデータベースに対する権限も持ちませんが、ユーザーは自ら申請するか、プロジェクト管理者から権限を付与されることで権限を取得できます。

   

5. 研究開発規範の調整

   現在、ODCには50以上のSQLチェック規範と8つのSQLウィンドウ規範が組み込まれており、一部の研究開発規範はデフォルトで有効になっています。研究開発規範を調整する必要がある場合は、システム管理者がセキュリティ規範モジュールに移動し、対応する環境の規範を調整する必要があります。一般的な研究開発規範の調整には以下のものが含まれます：

   • 一部の規範が開発環境で適用されない場合は、開発環境の規範設定ページに移動し、該当する研究開発規範を無効にすることができます。

   • 一部の規範が特定のデータソースタイプで適用されない場合は、全環境に移動し、その環境でこの研究開発規範がサポートするデータソースタイプを個別に設定する必要があります。

   

6. 承認フローの調整

   現在ODCは高・中・低・デフォルトの4つのリスクレベルを提供しており、高リスクレベルの識別ルールが組み込まれています。変更が高・中・低リスクレベルに該当しない場合、デフォルトの中リスクレベルにマッチし、デフォルトリスクレベルは自動承認されます。変更が複数のリスクレベルに同時に該当する場合は、最も高いリスクレベルが適用され、そのリスクレベルに対応する承認フローが実行されます。システム管理者は、セキュリティ規範モジュールで、各リスクレベルの識別ルールおよび承認プロセスを調整できます。

   

これにより、チームスペースの設定は完了です。具体的なプロジェクトに移動して、関連するデータ開発操作を開始できます。

チームスペースの主要なアプリケーション

安定的な開発：SQL開発と変更承認

チームスペースが有効化されると、関連するデータベース開発作業を開始できます。ホームページの SQLコンソール をクリックするか、ワークベンチの 最近アクセスしたデータベース にある特定のデータベース名をクリックすると、SQL開発ページに移動します。

SQL開発ページに移動すると、SQLウィンドウでSQLステートメントを記述できます。現在、SQLウィンドウでは、コードスニペット、コードの自動補完、スクリプトの保存など、一連の機能を提供しています。開発のコツについては、SQL開発の便利なコツをご参照ください。SQL実行後は、実行結果に対して、リアルタイム実行解析の表示、結果セットの編集、結果セットのエクスポートなど、一連の操作を実行できます。リアルタイム実行解析については、OceanBase APのリアルタイムSQL診断機能の解説をご参照ください。

このデータベースに対してチケット変更を申請したい場合は、リソースツリーでデータベースを選択し、右クリックして申請するチケットタイプを選択すると、チケット設定ページをすばやく呼び出せます。SQL開発モジュールでは、ODCは12種類のチケットタイプを提供しており、ロックフリースキーマ変更、SQL計画、パーティション計画など、さまざまなシナリオでの構造・データ変更ニーズに対応しています。チケットタイプの使用方法の詳細については、ロックフリースキーマ変更をご参照ください。

チケット設定ページでは、関連パラメータを編集した後、送信をクリックすると、開発規範チェックおよびリスクレベル判定に入り、その結果に基づいて承認プロセスが開始されます。変更が承認フローに該当すると、関連する承認者の承認を経て、承認後にデータベースで実行されます。

規範的な開発：SQLチェック

ODCは、DDL、DML、DQLステートメントタイプを網羅する、合計50以上のルールからなる、整備されたSQL開発規範を提供しています。これらのルールは、データベースの構造設計からデータのクエリおよび操作に至るまでのあらゆる側面をカバーしており、コードの効率性、規範性、安全性を確保します。ODCは、本番環境、テスト環境、開発環境の規範要件の違いに対応するため、異なる環境に応じて開発規範の値を調整することをサポートしています。

同時に、ODCは変更申請前および変更申請中の2つのタイミングでSQLチェックを実行することもサポートしています。変更申請前のチェックエントリは以下のとおりです：

SQLチェック規範の詳細については、ODC SQLチェックが高リスク操作を自動的に検出するをご参照ください。

データベースのスリム化：履歴データベース

業務データベースが長期間稼働するにつれて、データ量は継続的に増加し、ストレージコストの上昇、データベース性能の低下、データベース運用保守の難易度上昇など、一連の問題が発生します。これらの問題に対処するために、業務上頻繁にアクセスする必要のないコールドデータを、スペックが低くストレージが安価なサーバーに移行すれば、データベースのスリム化、業務データベースの応答速度の向上、データ運用保守の難易度の低減だけでなく、大幅なコスト削減にもつながります。

ODCはこのシナリオに対して、整備されたソリューションを提供しています：データアーカイブとデータクリーンアップをサポートしています。現在ODCがサポートしているアーカイブリンクは以下のとおりです：

• OceanBase MySQL、MySQLからOceanBase MySQLへ
• OceanBase Oracle、OracleからOceanBase Oracleへ
• OceanBase MySQL、MySQLからMySQLへ
• OceanBase Oracle、OracleからOracleへ
• PostgreSQLからOceanBase MySQLへ
• OceanBase MySQL、OceanBase Oracle、MySQL、Oracle、PostgreSQLからオブジェクトストレージ（OSS、COS、OBS、S3）へ

データアーカイブとデータクリーンアップの詳細については、データベースの履歴データベースの最適化管理をご参照ください。

セキュリティとコンプライアンス：データマスキング

企業では日常の運用保守、開発、データ分析などの業務において、しばしばデータベースクエリ操作を実行する必要があります。その際、業務上必要でありながら切り離せない機密データがデータベース内に存在する可能性があります。これらのデータを直接クエリするとプライバシー漏洩のリスクが生じる可能性がありますが、アクセスを完全に制限すると作業効率が低下したり、業務が遂行できなくなったりする問題も生じます。

このような状況に対処するため、ODCのデータマスキングソリューションがこの問題を効果的に解決します。ODCは、SQLクエリやデータエクスポートなど、データが外部に出力されるシナリオにおいて、機密データをマスキング処理してから出力することができます。これにより、データベースへのアクセス可能性を確保しつつ、プライバシーデータを露出させません。現在、ODCはフルマスキング、ハッシュマスキング、デフォルトマスキング、特殊業務意味フィールドのマスキングを含む20種類以上のマスキングアルゴリズムをサポートしています。マスキングが必要なフィールドを対応するプロジェクトで設定するだけで、マスキングを実現できます。データマスキングの詳細については、データマスキング管理の実践をご参照ください。

構造一貫性の保証：複数データベースの変更

日常業務において、同一の業務データベースの開発環境、テスト環境、本番環境における構造の一貫性を保証する必要があります。そのため、構造に関する変更は、異なる環境にも同じように適用する必要があります。プラットフォームの機能に依存しない場合、毎回の変更ごとに同じ変更内容を複数の環境で実行する必要があり、これは作業効率の低下だけでなく、誤操作のリスクも伴います。

この問題を解決するため、ODCは複数データベースの変更機能をサポートしています。一つの変更票を通じて、同一プロジェクト内の同一タイプの複数データベースの変更を編成し、一度の変更で複数データベースに影響を及ぼすことで、異なる環境間の構造一貫性を保証します。一般的な変更プロセスについては、テンプレートとして保存し、次回の変更時にそのテンプレートを選択するだけで、プロセスの再利用が可能です。複数データベースの変更に関する詳細については、複数データベース変更管理をご参照ください。

データベース・テーブルのシャーディング管理：論理データベースの変更

ビッグデータ時代において、大規模なデータに対処するため、多くの企業はOceanBaseのような拡張性のある分散型データベースや、データベース・テーブルのシャーディング技術を採用しています。新規業務については、一般的に分散型データベースの使用が優先的に推奨されます。これは、より強い拡張性と低い管理コストを備えているためです。

データベース・テーブルのシャーディング技術は、データを複数のデータベースインスタンスやテーブルに分散することで、データ処理能力とクエリパフォーマンスを向上させる効果的な水平分割戦略です。既にデータベース・テーブルのシャーディング技術を導入している業務では、業務上の課題は解決できますが、大量のシャーディングデータベース・テーブルを管理する方法が、DBAや開発者にとって頭痛の種となっています。

この問題を解決するため、ODCは論理データベースをサポートしています。これにより、シャーディングデータベース・テーブルの管理負担を軽減するだけでなく、今後のシャーディングデータベース・テーブルの計画を分散型データベースの計画へとアップグレードするための基盤も提供します（ODCは今後、論理データベースのデータをOceanBaseデータベースにアーカイブすることをサポートします）。

論理データベースを設定するには、簡単な操作を行うだけで済みます。論理データベースの設定完了後、ODCは定期的に論理データベース内の論理テーブルの構造一貫性を巡回検査します。論理データベースについては、現在ODCはGUIを通じた論理テーブルの作成やDDLデータベース変更チケットの発行をサポートしており、これによりシャーディングデータベース・テーブルの構造メンテナンスの課題を解決できます。論理データベースの詳細については、ODCを通じたデータベース・テーブルのシャーディング管理と変更の実現をご参照ください。

関連ドキュメント

• SQL開発でよく使われる小技
• ODC SQLチェックが高リスク操作を自動識別する
• OceanBase APのリアルタイムSQL診断機能の解析
• OceanBase履歴データソリューション
• データマスキング管理の実践
• ODCを通じたデータベース・テーブルのシャーディング管理と変更の実現