主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ | コーソルDatabaseエンジニアのBlog
株式会社コーソル

コーソルDatabaseエンジニアのブログ

技術ブログ

主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ

Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。

  • 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。
  • 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。
  • 時間ができた時に随時追記予定です。
  • もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot jp

「主要RDBMS製品の比較」ページ一覧

2022/09/02 追記: 立場の表明

  • コーソルはデータベース関連製品の販売およびプロフェッショナルサービス提供を行っている営利企業です。
  • https://cosol.jp にある全てのコンテンツは、情報提供に加えて、コーソルの認知度向上、コーソルの営利活動の促進を目的としています。

Database Performance Analyzer DPA

コーソルのDbvisitサービス

著者について

論理構造（データベース、スキーマ周辺）

Oracle（従来型/非CDB）

スキーマ

  • ユーザーと同名のスキーマ名が必ず存在し、ユーザーが所有するオブジェクトはそのユーザーのスキーマに格納されます。
  • オブジェクト名にはスキーマ名を前置き可能です。スキーマ名をテーブル名に前置きしなかった場合、ユーザーに対応するスキーマ内のテーブルとなる
  • スキーマは、a) オブジェクト所有者との対応、b) オブジェクトを区分けする論理的な箱（名前空間の区分）という役割を持つ。

データベース

  • データベースを包含する概念はありません。
  • データベースとインスタンスは1対1で対応します。

Oracle（マルチテナント/CDB）

スキーマ

  • スキーマの概念は、従来型/非CDBと同じです（というか、従来型/非CDBにおけるデータベース＝PDBであるため、スキーマに限らずデータベース内の全てが基本的に同じです）。

データベース

  • 従来型/非CDBにおけるデータベース＝PDBです。一般ユーザーはPDBに接続します。
  • PDBを包含する概念としてコンテナデータベース（CDB、マルチテナント形式のデータベース）が存在します。PDBは独立性が高いです。
  • CDBとインスタンスが1対1で対応します。

MySQL

スキーマ

  • スキーマやオブジェクトの所有者という概念はありません。ただ、データベースがスキーマに若干似た特性を持ちます。

データベース

  • 1つのデータディレクトリ(datadir)に、複数のデータベースを構成できます。
  • データベース名をオブジェクト名に前置きしなかった場合、接続先データベースのオブジェクトとなります。
  • データベース名をオブジェクト名に前置きすると、指定したデータベースのオブジェクトにアクセスできます（権限がある場合）。データベースは独立性が低く、オブジェクトを区分けする論理的な箱（名前空間の区分）のような役割を持ちます。
  • データディレクトリ(datadir)とインスタンス(mysqld)が1対1で対応します。

PostgreSQL

スキーマ

  • スキーマ名をテーブル名に前置きしなかった場合のスキーマ検索順序はsearch_pathパラメータで決定されます。
  • データベースに任意のスキーマを作成できます。Oracleのように、ユーザーとスキーマが1対1で対応するような関係性はありません。
  • ただし、search_pathパラメータのデフォルトが"$user", publicであるため、スキーマ名をテーブル名に前置きしなかった場合、ユーザー名と同名のスキーマが最初に検索されます。
  • オブジェクトはある特定のスキーマに格納されます。
  • publicスキーマが事前定義済みで、状況によってデフォルトとして使用されます。

データベース

  • 1つのデータベースクラスタ(PGDATA)に、複数のデータベースを構成できます。
  • データベースの独立性が高く、接続先データベースのオブジェクトにしか基本的にアクセスできません。
  • データベースクラスタ(PGDATA)とpostgresqlインスタンスが1対1で対応します。

MS SQL Server

スキーマ

  • データベースに任意のスキーマを作成できます。Oracleのように、ユーザーとスキーマが1対1で対応するような関係性はありません。ただし、ユーザー作成時にデフォルトのスキーマを指定して、緩い関係性を作ることもできます。
  • オブジェクトはある特定のスキーマに格納されます。
  • オブジェクト名にスキーマ名を前置きすると、指定したスキーマのオブジェクトにアクセスできます。
  • dboスキーマが事前定義済みで、多くの場合のデフォルトとして使用されます。

データベース

  • 1つのインスタンス配下に、複数のユーザーデータベースを構成できます。
  • データベースはデータ格納用のユーザーデータベースと、管理用のシステムデータベースに大別されます。
  • オブジェクト名にデータベース名を前置きすると、指定したデータベースのオブジェクトにアクセスできます（スキーマ名を前置きすることも可能です）。

メモリ(インスタンス関連)

  • インスタンスを中心に、重要なメモリ領域のみ記載します。
  • 大枠はどの製品も同じですが、MySQLとPostgreSQLは実行計画を含む解析済みSQL情報をキャッシュしません。

Oracle

  • インスタンスのメモリ領域はSGA、各プロセス専用のメモリ領域はPGAです。
  • 各メモリコンポーネントのサイズ設定の自動化が進んでおり、多くの場合、メモリ総量をパラメータ（MEMORY_TARGET, SGA_TARGET, PGA_AGGREGATE_TARGET）に設定するだけで、メモリ設定が完了します。
    • 各メモリコンポーネントをサイズを個別に設定することも可能です。
    • 自動メモリ設定と各メモリコンポーネントと個別パラメータを併用すると、各メモリコンポーネントの設定値はメモリサイズの下限値として使用されます。

  • データベースバッファキャッシュ (db_cache_size) に、データブロックがキャッシュおよびバッファリングされます。
  • ログバッファ (log_buffer) に、ディスク書込み前のREDOログ（Oracleのトランザクションログ）がバッファリングされます。
  • 共有プール (shared_pool_size) に、実行計画を含む解析済みSQL情報などが、キャッシュされます。

MySQL (InnoDB)

  • InnoDBバッファプール(innodb_buffer_pool_size)に、データベースページ（≒データブロック）がキャッシュおよびバッファリングされます。
  • InnoDBログバッファ(innodb_log_buffer_size)に、ディスク書込み前のInnoDBログ（InnoDBのトランザクションログ）がバッファリングされます。
    • MySQLのトランザクションログには、InnoDBログに加えてバイナリログがあります。
  • 解析済みSQL情報をキャッシュする仕組みはありません。
  • https://dev.mysql.com/doc/refman/8.0/ja/innodb-architecture.html

PostgreSQL

  • 共有メモリバッファ(shared_buffers)に、ページ（≒データブロック）がキャッシュおよびバッファリングされます。
    • PosgreSQLはダイレクトI/Oに対応していないため、ページは共有メモリバッファとI/Oのバッファキャッシュで二重にキャッシュおよびバッファリングされます。
  • WALバッファ(wal_buffers)に、ディスク書込み前のWALログ（PostgreSQLのトランザクションログ）がバッファリングされます。
  • 解析済みSQL情報をキャッシュする仕組みはありません。

MS SQL Server (Windows)

  • メモリ関係のパラメータやメモリコンポーネントの存在すら意識することが少ないほど(!)、メモリ関連設定の自動化が進んでいます。
    • 高度な機能（列ストア インデックス、インメモリ OLTP オブジェクトなど）を使用する場合、機能に応じたメモリ設定が必要になります。
  • max server memory (MB)に、SQL Server メモリ使用サイズの上限を設定できます。SQL Serverが想定外に大きなサイズのメモリを使用してしまう事態を避けるため、適切なサイズに設定することが推奨されます。
  • バッファープールに、データページ（≒データブロック）がキャッシュおよびバッファリングされます。
  • ログプールに、ディスク書込み前のトランザクションログがバッファリングされます。
  • プロシージャキャッシュに、実行計画を含めた解析済みSQL情報がキャッシュされます。

「主要RDBMS製品の比較」ページ一覧

[PR] オンプレミス＆クラウドのマルチDB製品に対応した性能管理ツールDPA

Database Performance Analyzer (DPA) は、オンプレミス＆クラウドに対応するデータベース性能監視／分析ツールです。

Database Performance Analyzer DPA

この記事で取り上げたRDBMS製品を含む、非常に多くのデータベース製品／サービスに対応しています。

  • Oracle Database
  • MS SQL Server
  • Sybase SAP ASE
  • IBM Db2
  • MySQL / MariaDB / Percona Server for MySQL
  • PostgreSQL / Enterprise DB
  • AWS
    • Amazon RDS for Oracle Database / SQL Server / MySQL / MariaDB / PostgreSQL
    • Amazon Aurora for MySQL / PostgreSQL
  • Azure
    • Azure SQL Database
    • Azure SQL Managed Instance
    • Azure SQL for PostgreSQL
    • Azure Database for MySQL / MariaDB
  • Google Cloud
    • Google Cloud SQL for MySQL / PostgreSQL / SQL Server

以下の特徴があり、導入しやすく有用な製品です。

  • 非常に低価格。課金単位は監視インスタンスの数で、1インスタンス14.7万円/年から（2023年1月時点）。
  • インストールが容易。DBサーバへのエージェント導入は不要。
  • オンラインデモサイトですぐに使用感を確認可能 → https://cosol.jp/techdb/2022/08/dpa_online_demo/
  • 待機時間を基礎とする性能分析（近年主流の性能分析メソッド）
  • 機械学習アルゴリズムに基づく異常検知機能(Anomaly Detection)

なぜコーソルからDatabase Performance Analyzer (DPA)を購入すべきなのか

コーソルはDatabase Performance Analyzer (DPA)の一次代理店で、Database Performance Analyzer (DPA)の製品販売を行います。 SIer様、販社様がDatabase Performance Analyzer (DPA)を販売および導入することも可能です。

Database Performance Analyzer DPA

コーソルはデータベースの技術力を強みとしています。なかでもOracle Database技術力は日本随一です。MySQL、PostgreSQL、MS SQL Serverの資格や実績を持つエンジニアも多数在籍しております。

独自のDPAナレッジを公開

DPAの導入や監視設定に関する手順をナレッジとして公開しています。評価版をご利用される際の参考にしていただけると幸いです。

多数のOracle関連書籍を執筆

ORACLE MASTER Platinum取得者数 No.1

  • 単年度ORACLE MASTER Platinum取得者数7年連続No.1

7年連続ORACLE MASTER Platinum取得者数No.1！ Oracle Certification Award 2020

[PR] コーソルのデータベース運用関連製品とサービス

コーソルでは、データベース運用を製品とサービスでご支援します。

Database Performance Analyzer （DPA）

Database Performance Analyzer （DPA）は、オンプレミスとクラウド上の多くのデータベース製品に対応したデータベース性能管理製品です。低価格であるため、非常に導入しやすいです。

自動SQLチューニング機能を持つToad

Database Performance Analyzer （DPA）で検出された問題SQLをチューニングする際に、Toad for Oracle / Toad for SQL Serverの SQL Optimizer機能を使用できます。

リモートDBAサービス

リモートDBAサービスはDB・運用の専門家がお客様のデータベースに対して 必要な時に必要な対応を行うリモート接続型運用保守サービスです。

データベース運用・保守なら常駐しないリモートDBA

時間制コンサルティングサービス

時間制コンサルティングサービスは”必要な時に” ”必要な時間だけ”契約できる 時間契約型のコンサルティングサービスです。

データベース コンサルティングなら時間制コンサルティング

関連記事

プロフィール

On7tWW6m1Ul4

渡部 亮太

・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

カテゴリー

アーカイブ

一覧へ戻る