生体内：情報エコシステム

はじめに

データベースは決して単独で存在するわけではありません。ユーザー、アプリケーション、スクリプト、さらには他のデータベースも、生物が環境エネルギーや互いのエネルギーを消費・分配するように、情報をデータベースに入力し、そこから抽出します。データベースが地球のグローバルエコシステムほどの規模や複雑さに匹敵することはありませんが、情報システムの設計とサポートには、庭や温室、飼育施設のような小さなものを世話することと、決して少なくない共通点があります。

古典的な生態学的区分は、情報システムにおけるデータベースの役割にも当てはめることができます。動物、植物、それとも鉱物？特定のデータモデルにどのモードが適切かを特定するには、それが置かれるコンテキストを可能な限り理解する必要があります。

「動物」は、運用プロセスやワークフローに組み込まれ（あるいは、より率直に言えば、絡みつき）、適応され、プログラムされた、活動的な組織原理を表現しているようです。一言で言えば、専門化されたものです。「動物」的アプローチは、情報フローの収集器であり、唯一の真実の情報源として、単一のデータベースを中心に明示的に構築された、焦点を絞ったシステムやサブシステムで非常にうまく機能します。この焦点を失うと、「動物」データベースはナマケモノのようなジャイアントパンダに陥るリスクがあります。動きが鈍く、メンテナンスに手間がかかり、物流と官僚主義の悪夢となるでしょう。

より「植物的」なデータベースは、取得したデータを組織化するだけで、それ以上のことはしません。情報を制約し、洗練しますが、それに対して積極的な行動は取りません。これらのデータベースは、ワークフローに対する集中化と積極的な制御を適応性に換え、より厳格なデータベース構造に行動や利用の仮定をエンコードすることなく情報を収集・整理します。データベースが情報処理の唯一の場所ではないシステムや、大規模なチームやコミュニケーション構造が相互作用するシステムでは、よりプログラムされていないデータベースを、「唯一の」組織原理ではなく「ある」組織原理として扱う方がはるかに簡単です。

さらに、「鉱物」的なデータベース設計は、情報に対するその最小限の権限さえも譲り渡し、シュメール人が台帳から苦情まであらゆるものを刻印した5千年前に使われた粘土板のように、最小限の構造を持つストレージのみを提供します。確かに、ACID準拠のスプレッドシート以上のものがほとんど必要ない状況も発生しますが、そのシステムをさらに詳しく検討することは十分に正当化されます。また、既存の「鉱物」データベースの実装が、より複雑なデータモデルを考慮していないか、ぎこちなく近似している場合や、データモデル自体の一部または全体がリレーショナル表現に不適格である可能性もあります。

複数形のデータベース

データベースと対話するすべてのプログラムやシステム（設計者、ユーザー、開発者を除くわけではない）もまた、情報を消費し生成し、結合し、分離し、良い悪いに係わらずニュアンスを加えたり削除したりする生態学的役割を担っています。これらの相互作用するシステムの多くは、独自のデータモデルを持っており、その一部または全体がターゲットシステムのデータモデルのコンポーネントを形成しています（時として、予想外のVARCHAR(20)に呪われたことのある人なら誰でもわかるように、いわゆる「ガラス越しにぼんやりと」）。

これらの接続は、データベース設計がしばしば、外部の他のデータモデルの構造要素でなくとも、少なくともいくつかの仮定に対応しなければならないことを意味します。情報が分割されます。ユーザーと予約は一つのデータベースに、ホテルの空室は別のデータベースから、航空券の予約は航空会社にあり、ユーザーと予約の側にも複製されます。スキーマは絡み合い、一つのデータベースの変更が他のデータベースに影響を与えます。

より多くのものやそれらの間の相互作用を管理することは常に困難であり、データモデルを複数のストレージに分割することは特に広範囲にわたる影響を及ぼします。完全にリレーショナルなモデルのサブセクションをカプセル化して対処することは、すべての主要なRDBMSがMySQLを除くサポートするスキーマを使用することで、より安全に達成できます。しかし、様々なことが起こります。一部の情報は非リレーショナル構造により適しています。一部の情報はすでに他のシステムのデータベースに分割されているか、サービス指向アーキテクチャ（マクロまたはミクロ）の採用により、分裂が避けられなくなっています。より厳格な回復要件は、ネットワーク化された冗長ストレージを要求します。データモデルは、これまで以上に、複数の相互作用するデータストアに分散されることを考慮しなければなりません。

データモデルを分割することによって最も失われるのは、参照整合性です。単一のデータベース内では、サーバーは外部キー制約に違反する操作（例：存在しない親IDを持つレコードの挿入や更新、または他のレコードが依存するレコードの削除）を防ぐことができます。データモデルの一部を別のストアに移動すると、正確性の維持はあなた（とあなたのチーム）の問題となります。

専門ソリューション

他のあらゆるものと同様に、参照整合性は交渉可能な制約であり、十分な見返りがあれば犠牲にするという選択肢もあります。グラフ理論的な意味でデータモデルが十分に単純で、エンティティが少なく、相互接続が少ないか、ほとんど階層的である場合、あるいはその両方である場合は、そもそも問いにすらならないこともあります。パフォーマンスとスケーラビリティの要件も、リレーショナルモデル以外の選択肢を導入する理由となることがあります。データモデルの一部が、RDBMSでは容易に対応できないほど大量かつ高速な変化を伴う実情報を表す場合です。

2000年代後半には、これらの代替案がカンブリア爆発のように出現しました。突然、「NoSQL」データベースが登場し、ドキュメント、グラフ、キーバリューペアを保存するようになりました。カラム型ストアは、テーブルを横向きにし、フラットで非正規化されたデータをモデル化することで、驚異的なパフォーマンスを達成しました。新しいデータベースは、ネットワーク化されたサーバー間でのスケールアウトを採用し、ACIDの定石を捨ててBASE（"Basically Available, Soft state, Eventual consistency"）を採用し、SQLには馴染みのない概念のためのAPIとドメイン固有言語を開発しました。それだけでなく、データストレージに関する議論の再構築は、データベースという概念の境界を曖昧にしました。Kafkaのようなストリームプロセッサーはデータベースでしょうか？ElasticSearchのような検索エンジンはどうでしょうか？どちらも根本的には情報の保存と取得を容易にするものであり、どちらかを議論するにはデータベースの専門用語の多くを援用する必要があります。より根本的には、どちらも特定の種類のデータモデリング問題に対するソリューションなのです。

上記は例であり、推奨ではありません！ Kristof Kovacsは、人気のあるものからあまり知られていないものまで、多くのNoSQLオプションに関するより詳細な要約も公開しています。

デフォルト

リレーショナルデータモデル以外のギガバイト単位の例外を保存する必要がないのであれば、ACIDと参照整合性を捨てる必要さえもないかもしれません！一般的なリレーショナルデータベースは、全文検索や構造化または非構造化ドキュメントの保存に非常に優れています。特にPostgreSQLのJSONへのアプローチは広範で、インデックス可能なバイナリストレージと豊富なクエリツールセットにより、ハイブリッドなリレーショナル-ドキュメント戦略が実用的になっています。Postgresや他のRDBMSは、サーバーコンポーネント、拡張機能、ストレージエンジンを介してさらに他のモデルもサポートしており、TimescaleDBのような一部の専門ストアはリレーショナルデータベースの上に構築されています。

したがって、数十のマーケティング部門の最善の努力にもかかわらず、半世紀にも及ぶRDBMSは、汎用データストアの定番であり続け、非リレーショナルソリューションはその強みに適した専門的なニッチを見つけています。NoSQLデータベースは、リレーショナルデータベースにはできない、または簡単にはできないあらゆる種類のことを実行できますが、リレーショナルデータベースは予見可能な将来にわたって存続するでしょう。サーバーチューニング、インデックス作成、テーブルパーティショニングを行えば、単一のリレーショナルデータベースは、最も重いワークロードを除くすべてのワークロードに対応できます。そして、それでも不十分な場合は、レプリケーションがあります。

レプリケーションとアーキテクチャ

レプリケーション技術を深く掘り下げることはデータモデリングガイドの範囲外ですが、その使用は無視できない結果をもたらします。レプリケートされたデータベースは単に大きくなるだけではありません。データストレージがネットワーク化された瞬間、それは全体のシステムアーキテクチャの単一の要素ではなくなります。レプリケーションは、レイテンシー、ネットワークパーティション、メンテナンスなど、まったく新しい一連の懸念事項をもたらします。

最も一般的なレプリケーション形式は、データを単一のプライマリサーバーにのみ書き込むことを伴います。プライマリは変更を1つ以上のレプリカサーバーに転送します。レプリカサーバーは、プライマリがダウンした場合にその代わりを務める（フェイルオーバー）か、読み取りクエリに応答する役割を担います。後者の場合、ネットワークの遅延により変更がすぐに表示されないことがありますが、データの流れが一方通行であるため、整合性は保証されます。この読み取りと書き込みの分割は、適切なビューで統合されたエンティティを表現するのに自然に適しており、特にソフトウェアシステムでは、取得またはストレージのみに関連する複雑さを制御するのに役立つ設計パターンであるコマンドクエリ責務分離（CQRS）に適しています。

別の「マルチプライマリ」モードのレプリケーションでは、複数のサーバーにデータを書き込んだり読み込んだりすることができます。これらのサーバーは、ネットワーク接続されており、単一のサーバーでは決して不可能だったような、重いワークロードに対して全体として格段に高い耐障害性を発揮します。しかし、コンセンサスを得ることは複雑であり、永続性を保証するために高いレベルの書き込み検証を達成するには時間がかかります。これは、より単純なデータモデルと、競合やロールバックのより繊細な処理を必要とします。

ほとんどのNoSQLデータストアはクラスター向けに設計されており、単一のコンピューターで動作できることはほとんど後付けとさえ見なされています。特に、NoSQLはシャーディング、つまりテーブルのパーティションをクラスター内の異なるノードから提供するというアイデアを前面に押し出しました。シャーディングはこれらのデータベースが達成する規模の主要な要因ですが、レプリケーションなしではノードが失われるとデータも失われます。ほとんどのNoSQLデータベースは、通常自動フェイルオーバー機能を備えた基本的なレプリケーションを提供します。CassandraやCouchbaseのように、複数のプライマリを使用するものもあります。

CAP定理

外部情報の統合

情報は、システムのデータベースや複数のデータベースとユーザーの間だけで循環することはめったにありません。ほとんどの情報システムはオープンシステムであり、他の情報システムからデータが流れ込み、また流れ出しています。これらのフローは通常、自動化に適しており、ある程度の量になるとほとんど義務的になります。手作業でのデータ入力は、最後の最後の手段です。外部の情報源が常にオンである場合もあり、キュー、ストリームプロセッサ、または特殊なデーモンが到着するたびにレコードを追加しますが、一度に処理しすぎないようにします。しかし、リアルタイムデータが利用できない場合や、単に不必要である場合もあります。月次売上や昨日のサイト分析は、秒単位で最新である必要はありません。

一括データ取り込みのプロセスは、抽出-変換-読み込みの頭文字をとってETL（Extract-Transform-Load）と一般的に呼ばれます。抽出や変換が行われない場合でも非公式に使われます。典型的なETL手順は、cronジョブまたはスケジュールされたタスクで、外部システムからアーカイブされたデータエクスポート（CSVやTSVなどのフラットな区切り形式であることが多い）をダウンロードします。レコードはETLタスクによってデータベースに書き込まれる際に変換されることもあれば、頭文字に反して後で一括変換されることもあります。一括変換は、既存データとの結合が関与する場合に特に役立ちます。なぜなら、データベースは何千行の結合を一度に最適化する方が、数千回の単一行結合よりもはるかに効率的だからです。

データインポートのファーストパーティーツールは様々です。独自のRDBMSには、SQL Server Integration ServicesやOracle Data Integratorのような専門のETL管理プログラムが含まれていることが多い一方、主要なオープンソースおよびNoSQLオプションは、mysqlimportやmongoimportのような基本的なファイル読み込みアプリケーション、またはPostgreSQLやCassandraのサーバーサイドCOPYコマンド（Postgresはpsqlクライアントでクライアントサイドの\copy命令も提供）にとどまります。

しかし、サードパーティのETL自動化は、特に多くのデータベースがクラウドでホストされるようになるにつれて、実行可能なビジネスニッチになりつつあります。さまざまな入力フローが多数ある場合や、厳格な規制遵守要件がある場合は、これらのサービスを検討する価値があるかもしれません。彼らがあなたにすでに利用可能なツールでできないことをしているわけではありません。問題は、十分に堅牢なETLプロセスを自分で実装し、保守する時間があるかどうかです。

フェデレーション：統合された情報源

ETLだけが唯一の選択肢ではありません。2003年、SQL標準はManagement of External Data（外部データ管理）を意味するSQL/MEDという拡張機能を導入しました。ファイル、他のデータベース、他のリレーショナルまたは非リレーショナルDBMS、RESTエンドポイント、ディレクトリサービスなど、これらすべては、少なくとも正しい角度から見れば、列と行によく似たデータセットを含んでいます。そして、列と行に十分似ているものは、SQLを介して直接管理はできなくとも、問い合わせることができると考えることができます。データベースはユーザーや他の外部システムに単一のインターフェースを提供し、要求と変更を適切な宛先にルーティングします。

IBMのDB2で最初に実装された後、他のデータベースがSQL/MEDに追いつくまでに数年かかりました。現在、Oracleはフラットファイルへの読み書きアクセスを「外部テーブル」としてサポートしており、SQL ServerはMicrosoftのOLEDB APIに準拠している限り、「リンクサーバー」に接続できます。

本当に興味深いことは、オープンソースRDBMSで起こっています。PostgreSQLはバージョン9.1で外部データラッパーを導入し、その機能を拡張し続けています。MariaDBのCONNECTストレージエンジンは、多くのデータソースをラップできます。さらに、PostgresとMariaDBの両方の実装は拡張可能です。既存のラッパーでは扱えない形式の外部データがある場合は、自分で作成できます。Postgresコミュニティは、そうでなければCベースとなる外部データラッパー開発プロセスを簡素化するために、MulticornというPythonフレームワークさえ開発しました。

「フェデレーテッド」アーキテクチャのアイデアは、地域政府と中央政府（連邦政府）が共存する二元的な統治形態に由来し、他のシステム設計技術と同様に、その目的は複雑性の管理です。個々のサブシステムのユーザーは、それらのサブシステム内で作業し、それらと連携します。全体的な運用のみに関心があるユーザーは、ゲシュタルトと相互作用します。生態学的な役割の観点から見ると、これはまさにデータベース運用の「動物」モードです。フェデレーティングデータベースは、それが存在するシステムの中心です。情報フローを自身に引き込み、接続を確立し、補助スキーマの期待をエンコードします。しかし、そのような「獣」が繁栄できる情報エコシステムでは、SQL/MEDは異種のデータソースを囲い込む強力なツールとなります。