Dr. Hasan Dalmaz

› SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;

▸ 要点

RAC では複数のサーバーが同じデータベースを共同で稼働させ、1 台が障害を起こしてもシステムは稼働し続ける。

✓ 強み

無停止稼働とディザスタリカバリ（Data Guard）において最も成熟したエンタープライズ向けの選択肢。

⚠ 注意点

ライセンス費用が高く専門知識を要する。小規模プロジェクトには過剰。

→ 最適な用途

ダウンタイムが許されない大規模企業システム：銀行、ERP。

› CREATE EXTENSION vector;

▸ 要点

オープンソース。拡張機能で機能を追加できる — 地図データや AI 向けのベクトル検索など。

✓ 強み

無料かつ高機能で標準準拠。単純なレコードから複雑なクエリまで対応する。

⚠ 注意点

更新/削除が多いシステムでは、定期的な VACUUM メンテナンスとチューニングが必要。

→ 最適な用途

Web・モバイルアプリのバックエンド、地図（GIS）、AI プロジェクト。

› CREATE AVAILABILITY GROUP ag_prod;

▸ 要点

Microsoft のデータベース。Windows/.NET の環境とシームレスに連携し、強力なツール（SSMS）を備える。

✓ 強み

日常のトランザクションとレポート/分析の両方をひとつのシステムでうまく処理する。

⚠ 注意点

Windows 上で最もよく動作する。Enterprise Edition のライセンスは高価。

→ 最適な用途

エンタープライズ .NET アプリケーションと BI/レポーティングシステム。

› START REPLICA;

▸ 要点

Web で最も普及しているデータベース。導入も利用も容易で、巨大なコミュニティがある。

✓ 強み

軽量かつ高速。特に読み取り中心のサイトで容易にスケールする。

⚠ 注意点

非常に複雑な分析や高度なクエリでは Oracle/PostgreSQL ほどの深さはない。

→ 最適な用途

WordPress などのサイトや、高トラフィックで読み取り中心の Web アプリ。

› db.orders.find({ status: "paid" })

▸ 要点

データを表ではなく柔軟な「ドキュメント」（JSON 形式に近い）として保存する。固定的なスキーマは不要。

✓ 強み

開発が速く、大量かつ頻繁に変わるデータに強く、容易にスケールアウトできる（シャーディング）。

⚠ 注意点

設計が不十分だと重複や不整合が生じる。厳密なリレーショナル整合性が求められる場合の第一候補ではない。

→ 最適な用途

カタログ、コンテンツ管理、構造が頻繁に変わるアプリ。

› SET session:42 online EX 3600

▸ 要点

データをディスクではなくメモリ（RAM）に保持するため、ほぼ瞬時に応答する。

✓ 強み

非常に高速。キャッシュ、セッション、リアルタイムカウンターに最適。

⚠ 注意点

データが RAM に収まり、永続化が正しく設定されていなければ、データを失うおそれがある。

→ 最適な用途

キャッシュ、セッション保存、ランキングなど、速度が重要なあらゆる場面。

› GET /products/_search?q=laptop

▸ 要点

テキスト検索のためのエンジン。転置インデックスで数百万件のドキュメントを検索し、関連度順に結果を並べる。

✓ 強み

非常に高速な検索、オートコンプリート、ログ/分析（ELK スタック）。容易にスケールアウトできる。

⚠ 注意点

プライマリデータベースではない。通常はメインのデータベースと併用し、検索/ログ層として動作する。

→ 最適な用途

サイト内・商品検索、ログ分析、オブザーバビリティ。

› SELECT * FROM orders JOIN users USING (id);

▸ 要点

データを関連付けられた表に整然と格納し、SQL で問い合わせる。数十年にわたり実績のあるモデル。

✓ 強み

強い一貫性：トランザクションは完全に実行されるか、まったく実行されないか（ACID）。複雑なクエリに非常に強い。

⚠ 注意点

多数のマシンへの分散（シャーディング）が難しく、後からのスキーマ変更には慎重な計画が必要。

→ 最適な用途

金銭、在庫など、正確性が不可欠なあらゆるシステム。

› { "user": "hd", "roles": ["dba"] }

▸ 要点

固定的な表の代わりに柔軟な構造（ドキュメント、キーバリュー…）を使う。大規模向けに設計されている。

✓ 強み

多数のマシンに容易に分散でき、高い書き込み負荷にも余裕をもって対応する。

⚠ 注意点

一般に SQL の強い一貫性保証や表の結合（JOIN）を備えない。

→ 最適な用途

大規模 Web、リアルタイム分析、柔軟な構造のデータ。

› BEGIN; UPDATE acct SET bal = bal - 100; COMMIT;

▸ 要点

2 つの一貫性の考え方：ACID はすべてのトランザクションが完全に完了することを保証し、BASE は速度と可用性のためにそれを緩和する。

✓ 強み

ACID は金銭のような重要データに信頼性を与え、BASE は大規模なスケールと常時アクセスを実現する。

⚠ 注意点

BASE ではデータが一時的に「古い」場合があり、アプリ側でそれを考慮する必要がある。

→ 最適な用途

ACID：決済システム。BASE：SNS のフィード、いいね数。

› -- OLTP: point writes · OLAP: aggregate scans

▸ 要点

2 種類のワークロード：OLTP は日常的な多数の小さなトランザクション（注文、決済）、OLAP は大量データの分析。

✓ 強み

適切に分離すれば両方が速くなる：一方が日常業務を、もう一方がレポートを担う。

⚠ 注意点

両方を同じシステムで動かすと互いに遅くなるため、通常は分離する。

→ 最適な用途

OLTP：注文/決済。OLAP：レポート、ダッシュボード、データウェアハウス。