データベース・ランドスケープの概要
ライセンスとデータ・モデリングを通じて、データベースのランドスケープを詳しく見ていきます。
データベースの世界に足を踏み入れたばかりであれば、おそらく 2 つのことをすでにご存じでしょう。データを効果的に使用すれば利益が得られるということ、そしてそのデータを管理するためのデータベースの選択は大変な作業になる可能性があるということです。
確かに、データが売上高を向上させる力はますます高まっています。データはエクスペリエンスを最適化し、機械学習を強化します。しかし、それは何百ものベンダーがあなたのデータを保管・分析するために競い合っていることを意味します。どのようにして選ぶか？人生のほとんどのことと同様に、知識が力となります。
データベース・ランドスケープの概要、特にデータベースをビジネス・コンテキストに組み込む方法をご覧ください。まず、ライセンスとデータ モデリングについて詳しく説明します。
ソフトウェアライセンスは、控えめに言っても複雑です。知的財産権だけでなく (これに関する推奨資料：Besen & Raskind社の「An Introduction to the Law and Economics of Intellectual Property」、Rosen氏の「Open Source Licensing: Software Freedom and Intellectual Property Law」)、具体的にライセンスに配慮すべき理由を確認することをお勧めします。ビジネスに影響を与えるオープンソース・データベース・ランドスケープのトレンドについてです。
準備はいいですか？
まずライセンスについてお話しましょう
すべてのソフトウェア・ライセンスには、テクノロジーの使用方法に関して従う必要のある規則や規制があります。つまり、導入するソフトウェアのライセンスがビジネスのやり方に具体的な影響を与える可能性があるということです。これらのルールを無視したり違反したりすると、法的リスクや経済的損失にさらされ、率直に言って会社の評判が損なわれる可能性があります。ソフトウェアを購入する場合でも、オープンソース・テクノロジーを採用する場合でも、このライセンスは、最終的にはコードの使用を一定の範囲で制限します。つまり、長期的な法的リスクを軽減するために、製品を開発する際にはこれらの制約に注意する必要があります。
次に、ライセンスは固定されていないことに注意してください。実際、現在、オープンソース・データベース・プロジェクトを支援する多くの企業は、データベース・ライセンスをより制限の厳しいものに変更する過程にあります。ユースケースによっては、データベースを無料で使用していた場合、法的措置にさらされる可能性があります。あなたを怖がらせる意図はありません。ただ、注意を怠らないようにするための警告です。これらの変化に際し、適切に対応することが重要です。場合によっては、ライセンスの変更にあたり、サービスの再構築、別データベースの採用、またはベンダーとの商業契約の締結が必要になる場合があります。
この問題空間をもう少し調べてみましょう
Hacker NewsやTechCrunch をよく読む人は、オープンソースおよび商用データベース ソフトウェアに関する会話に馴染みがあるはずです。要点は次のとおりです。過去 3 年間、主要なパブリッククラウドのベンダーの成長や、オープンソース中心のデータベース プロバイダーの市場での成功、あるいはその欠如などのさまざまな要因が重なり、議論が勃発しました。
そうは言っても、フリーソフトウェアとプロプライエタリソフトウェアの関係は二元的なものではなく、必ずスペクトルとなります。
注：図示されている距離は科学的ではなく、相対的な値の方が重要です。
上のスペクトルを見ると、一番左に、Oracle、IBM® Db2、Microsoft SQL Serverなどの商用またはプロプライエタリのデータベース ソフトウェア ライセンスがあります。これらは、あらゆる業種・業務のワークロードを強化する強力で機能が豊富なテクノロジーです。このソフトウェアをベンダーから購入する場合、またはクラウド・サービスとして購入する場合、以下にアクセスするためにプレミアム料金を支払うことになります。
コードレベルのサポート
ツールの堅固なエコシステム
専門サービスとコンサルタント
そのデータベースのロードマップに対する可視性と影響力
右側にはパブリックドメインのソフトウェアがあります。このソフトウェアには著作権は一切ありません。つまり、無制限に変更、配布、販売できるということです。スペクトルの右端に近いプロジェクトは、Apache Software FoundationやLinux Foundationなど、公平でバイアスのないサードパーティの基準によって管理されていることがよくあります。
オープンソース・イニシアティブ (OSI) は、オープンソース・ライセンスとそうでないものについて一般的に受け入れられているリストを管理しています。一般的に、オープンソース ソフトウェアは、「コードをフォークする」機能を備えているのが特徴です。つまり、プロジェクト (ソフトウェア) の方向性が、必要なものや希望するものと矛盾する場合は、必要に応じてコードを変更または編集することができます。
オープンソース テクノロジーの使用は、ライセンス コストがゼロであること、開発の透明性が高いこと、そして多様な利害関係者、メンテナンス担当者、問題領域から生まれるイノベーションにより、特に魅力的です。商用ソフトウェアと比較して、オープンソース ソフトウェアでは、ロードマップの影響やバグの修正プログラムやセキュリティパッチに関する保証、契約を放棄し、ベンダー・ロックインをゼロにし、事業部門の柔軟性を向上させることができます。（これは、あなたがチームと共に慎重に検討する必要があるトレードオフであることがわかります。）
上記のグラフを左から右に辿ると、Apache 2.0、MPL、GPL 3.0など、さまざまなレベルのライセンス許容度が存在します。
ライセンスにマッピングされたデータベースの例
Apache 2.0 : Apache Cassandra、Apache CouchDB
Mozilla Public License: RabbitMQ
BSD : Redis
GPL 3.0: Neo4j
独自仕様: IBM Db2、Microsoft SQL Server
背景となる歴史の概要
2000年代後半には、新興データベース・ベンダーのほとんどが、採用の促進と開発者の関心を得やすくするために、「オープンソース」として市場に参入していました。この路線に属する企業としては、Mongo Inc.、Redis Labs、Elastic などをご存じかもしれません。これらの企業は、 MongoDB 、 Redis 、Elasticsearch などのコミュニティ プロジェクトを開発しましたが、その投資をEnterpriseライセンス バージョン、マネージドクラウド実装、またはプロフェッショナル サービスで収益化することを検討していました。
しかし、クラウド・コンピューティングのパラダイム シフトにより、大手ベンダーがこれらのテクノロジーを第一級のプラットフォーム ネイティブの管理サービスとして簡単に提供できるようになったため、このビジネス モデルは不安定になっています。これらの製品は、ソフトウェアの作成者に保証された報酬を提供することなく、それぞれのクラウドでセキュリティー、コンプライアンス、監視、ロギングのための魅力的な統合とともに提供されます。
近年、企業は市場へのルートを再評価しています。現在では、開発への投資を保護するライセンス・モデルを採用していることが多くなっています。例えば、MongoDB、Redis Labs、そしてConfluentはいずれも、程度の差こそあれ、他社がそのコードの一部を対価なしにサービスとして運用することを防ぐために、ライセンスを変更しています。
「ジョシュ、アドバイスは何かありますか？」いい質問ですね。
商用データベースとオープンソースデータベースの両方を使用するのには十分な理由があります。重要なのは、あなた自身とあなたの会社が何に踏み込もうとしているのかを理解していることです。アプリケーションを構築する前にライセンスを確認し、プロジェクトがコンプライアンスに準拠していることを確認してください。オープンソースプロジェクトのライセンスを選択する場合は、Githubの「ライセンスの選択」というページを参照してください。
誰も訴訟は望んでいませんので、重要な考慮事項の1つはライセンスです。もう1つはデータモデル・ファミリーですが、その理由は異なります。アプリケーションを構築するときに、データモデルの種類を理解しておくと、作業に適したツールを選択するのに役立ちます。
ライセンスについて理解したところで、データベースを選択する際のもう１つのクリティカルな考慮事項であるデータモデルについて説明します。
IBM で働き始めた当初、すぐに慣れる必要があったので、マーティン・ファウラー著の『NoSQL Distilled』に頼りました。
彼の著書、そしてこの業種・業務全体では、データベースをドキュメント、キー・バリュー、グラフ、リレーショナル、ワイドカラムの5つの「データモデル」ファミリーに分類する傾向があります。ここでは、ユースケースやデータベース固有の例を含め、それぞれの簡単な概要を説明します。これは、データセットとビジネスニーズに基づいて、どのデータベースが必要かを判断するのに役立ちます。
1. ドキュメント
この場合、データは行と列ではなくJSONのようなドキュメントでモデル化されます。これらのデータベースは本質的に、トランザクションの一貫性よりも可用性を重視します。ドキュメント・データベースは、シンプルさと拡張性、および開発における迅速なイテレーションに適しています。
ビジネス・ユースケース:
高速なイテレーションを必要とするモバイル・アプリケーション
イベントロギング、オンライン・ショッピング、コンテンツ管理、詳細な分析処理
製品属性を持つ小売カタログ
以下に例を示します。
Firebase
2. キー・バリュー
このタイプのモデルは、最も基本的なタイプの非リレーショナル・データベースを表しており、データベース内の各項目は、対応する値を持つ属性名（キーと呼ばれる）として保管されます。
ビジネス・ユースケース:
ユーザー設定とプロファイル保管
閲覧データに基づく製品のレコメンデーション
ショッピングカート
以下に例を示します。
DynamoDB
Redis
etcd
3. グラフ
ここでのデータは頂点とエッジ (値と接続) としてモデル化されます。人間が情報を考察し処理するのと同じように、グラフ・データベースはデータの個別の単位間の関係性を記憶・参照します。これらのデータベースは、データと関係の永続化、探索、視覚化をより直感的に行います。
ビジネス・ユースケース:
不正アクセス検知
リアルタイム・レコメンデーション・エンジン
マスター・データ管理
ネットワークおよびITオペレーション
ID およびアクセス管理
以下に例を示します。
Neo4j
AWS Neptune
4. リレーショナル
IBM在籍時のR.F. コッド氏により紹介されたリレーショナルモデルは、業界において重要な存在です。データは行と列としてテーブルに保管され、多くの場合、分析と探索のために高度なクエリー・エンジンが使用されています。リレーショナル データベースはトランザクションの保証と ACID (原子性、一貫性、独立性、永続性) 準拠に役立つ一方で、他の 4 つのファミリーのほとんどのデータベースは最終的に一貫性があります。
ビジネス・ユースケース:
Eコマース
エンタープライズ・リソース・プランニング
顧客関係管理（CRM）
以下に例を示します。
IBM Db2
5. ワイドカラム
カラムファミリー・ストアは、行キー、カラム名、セルのタイムスタンプを使い、非常に高速なデータ・アクセスを可能にします。これらのタイプのデータベースの柔軟なスキーマは、列がレコード間で一貫している必要がなく、すべてのレコードに列を追加せずに特定の行に列を追加できることを意味します。ワイドカラム・ストアはGoogleのBigTable論文 から派生したものです。これらのデータモデルをカラム指向ストレージモデルと混同すべきではありません。後者は、ディスク上のデータ圧縮の向上や CPU の効率的な利用により、データウェアハウジング技術や分析的アクセスパターンとの関連性がより高いものです。
ビジネス・ユースケース:
セキュリティーと株式市場分析
クリックストリーム分析
IoT（モノのインターネット）とテレメトリー
以下に例を示します。
Apache Cassandra
DataStax エンタープライズ
Google Cloud BigTable
要するに、主要なデータモデルにはそれぞれ長所と短所があります（ここでは、ほんの表面に触れただけです）。しかし、迷った場合は、PostgreSQL のように実績があり普及しているものを選んでください。データモデル・ファミリーのアーキタイプについての詳細は、マーティン・ファウラーの書籍『NoSQL Distilled』（特に第8章から11章）を参照してください。
データベースについてさらに学ぶ準備はできていますか？
さて。ここでは、少し掘り下げましたが、さらに詳しく知りたい方は、所要時間に基づくいくつかの推奨事項をご覧ください。
15分：「データベースの選び方」ベン・アンダーソン
15分：「 SQLとNoSQLデータベースの違いは何か？ 」ベン・アンダーソン / ブラッド・ニコルソン
3時間：分散システムの安全性に関するジェプセンの分析
1週間：「データ集約型アプリケーションの設計」マーティン・クレップマン
開発を始めたいですか？IBM Cloud には、チームが迅速に動き出せるよう支援する幅広いマネージドデータベースサービスがあります。