生体内：情報生態系

はじめに

データベースは決して単独ではありません。ユーザー、アプリケーション、スクリプト、そして他のデータベースでさえ、生物が環境エネルギーや互いのエネルギーを消費および分配する方法で、情報をデータベースに供給したり、データベースから抽出したりします。地球規模の生態系の規模や複雑さに匹敵するデータベースはありませんが、情報システムの設計とサポートは、庭、温室、またはテラリウムのようなより小さな生態系の世話と多くの類似点があります。

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

「動物」は、運用プロセスやワークフローに組み込まれた（または、優しくない言い方をすれば、絡み合った）、適応され、プログラムされた、つまり一言で言えば、特化された、アクティブな組織原理を表しているようです。「動物」のアプローチは、情報の流れの収集者および唯一の信頼できる情報源として単一のデータベースを中心に明示的に構築された、焦点を絞ったシステムまたはサブシステムで非常にうまく機能します。この焦点を失うと、「動物」データベースは、ジャイアントパンダのようになるリスクがあります。つまり、動作が緩慢で、メンテナンスに手間がかかり、ロジスティックおよび官僚的な悪夢となります。

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

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

複数のデータベース

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

これらの接続は、データベースの設計が、構造の要素ではないにしても、少なくともいくつかの仮定を、自身に外部の他のデータモデルの仮定を受け入れる必要があることを意味します。情報は分割されます。1つのデータベースのユーザーと予約、別のデータベースのホテルの空室状況、航空会社のフライト予約、およびユーザーと予約側で複製されます。スキーマが絡み合い、1つのデータベースの変更が他のデータベースに影響を与えます。

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

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

特化されたソリューション

他のすべてと同様に、参照整合性は交渉可能な制約であり、十分な見返りを得られる場合は、それを犠牲にすることも選択肢の1つです。データモデルがグラフ理論的な意味で十分に単純で、エンティティが少なく、エンティティ間の接続が少ないか、ほとんどが階層的な接続であるか、またはその両方である場合、尋ねられている質問ですらない場合があります。パフォーマンスとスケーラビリティの要件も、リレーショナルモデルの代替案を導入する理由になる可能性があります。データモデルの一部が、RDBMSで簡単に対応できるよりも、より大量で高速なフラックスで実際の情報を表す場合です。

2000年代後半には、これらの代替案のカンブリア爆発が見られました。突然、ドキュメント、グラフ、キーと値のペアを格納する「NoSQL」データベースが登場しました。カラム型ストアは、テーブルを横向きにし、フラットで非正規化されたデータをモデル化することで、驚異的なパフォーマンスを実現しました。新規参入者は、ネットワーク化されたサーバー全体へのスケールアウトを採用し、ACIDプレイブックを放棄してBASE（「基本的に利用可能、ソフトステート、最終的な整合性」）を支持し、SQLにはなじみのない概念のAPIとドメイン固有の言語を開発しました。それだけでなく、データストレージに関する会話の再構築により、データベースの概念としての境界が曖昧になりました。Kafkaのようなストリームプロセッサはデータベースですか？ElasticSearchのような検索エンジンはどうですか？それぞれが基本的に情報の保存と取得を容易にします。どちらかを議論するには、データベースの技術用語の多くを呼び出す必要があります。より根本的には、それぞれが特定の種類のデータモデリング問題に対するソリューションです。

上記は例であり、推奨ではありません！ Kristof Kovacsは、人気のあるものからあいまいなものまで、多くのNoSQLオプションの詳細な概要も維持しています。

デフォルト

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

そのため、数十のマーケティング部門の最善の努力にもかかわらず、古くて半世紀前のRDBMSは、依然として頼りになる汎用データストアであり、非リレーショナルソリューションは、その強みに適した特殊なニッチを見つけています。NoSQLデータベースは、リレーショナル対応データベースが簡単またはまったくできないあらゆる種類のことを実行できますが、リレーショナルデータベースは当面の間存続します。サーバーチューニング、インデックス作成、およびテーブルパーティショニングにより、単一のリレーショナルデータベースで最も重いワークロードを除くすべてに対応できます。それでも十分でない場合は、まだレプリケーションがあります。

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

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

最も一般的なレプリケーションの形式には、単一のプライマリサーバーにのみデータを書き込むことが含まれます。プライマリは、変更を1つ以上のレプリカサーバーに転送します。レプリカサーバーは、プライマリサーバーがダウンした場合（フェイルオーバー）にプライマリサーバーを置き換えるために待機するか、読み取りクエリに応答する作業を肩代わりします。後者の場合、ネットワークレイテンシは、変更がすぐに表示されない可能性があることを意味する可能性がありますが、変更は一方向にのみ流れるため、整合性は依然として保証されます。この読み取りと書き込みの分割は、必要に応じてビューで統合されたエンティティを表すのに自然に適しており、特にソフトウェアシステムでは、コマンドクエリ責務分離（検索またはストレージのみに関連する複雑さを制御するのに役立つ設計パターン）に適しています。

代替の「マルチプライマリ」レプリケーションモードでは、複数のサーバーに対してデータの書き込みと読み取りを行うことができます。ネットワーク化されたこれらのサーバーは、単一のサーバーよりも、重いワークロード下では全体としてはるかに回復力があります。ただし、コンセンサスを解決することは複雑であり、耐久性を保証するために高レベルの書き込み検証を達成するには時間がかかる場合があります。これは、より単純なデータモデルと、競合とロールバックのより繊細な処理が必要になる傾向があります。

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

CAP定理

外部情報の統合

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

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

データインポート用のファーストパーティツールは異なります。独自のRDBMSには、SQL Server Integration ServicesやOracle Data Integratorなどの特殊なETL管理プログラムが含まれていることがよくありますが、主要なオープンソースおよびNoSQLオプションは、通常、mysqlimportやmongoimportなどのアプリケーションを使用した基本的なファイルロード、またはPostgreSQLおよびCassandraでのサーバー側のCOPYコマンド（Postgresはpsqlクライアントでクライアント側の\copy命令も提供しています）で止まります。

ただし、サードパーティのETL自動化は、特にクラウドでホストされるデータベースが増えるにつれて、実行可能なビジネスニッチになりつつあります。さまざまな受信フローまたは厳格な規制遵守の制約がある場合は、これらのサービスを調査する価値があるかもしれません。これらのサービスは、既に利用可能なツールでできないことは何もしていません。問題は、十分に堅牢なETLプロセスを自分で実装および維持する時間があるかどうかです。

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

ETLがすべてではありません。2003年、SQL標準は、外部データ管理のための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フレームワークも開発しました。

「フェデレーション」アーキテクチャのアイデアは、地域政府と中央（連邦）政府が共存する二重政府の形態から派生しており、他のシステム設計手法と同様に、その目的は複雑さの管理です。個々のサブシステムのユーザーは、それらのサブシステム内で、およびそれらのサブシステムを使用して作業します。全体Operationのみに関心のあるユーザーは、ゲシュタルトと対話します。生態学的役割の観点から見ると、これはまさに「動物」モードのデータベース運用です。フェデレーションデータベースは、それが存在するシステムの中核です。それは、情報の流れを自身に引き込み、自身を介して流れさせ、接続を行い、補助スキーマの期待をエンコードします。しかし、そのような獣が繁栄できる情報生態系では、SQL/MEDは、異種データソースをまとめるための強力なツールです。