その結果、1974年に世界に初めて紹介されたSQLが生まれました。 その後数十年にわたり、SQLは絶大な人気を誇ることになります。 System R、Ingres、DB2、Oracle、SQL Server、PostgreSQL、MySQL などのリレーショナル データベースがソフトウェア業界を席巻する中、SQL はデータベースと対話するための卓越した言語として確立され、ますます混雑し、競争が激化するエコシステムの共通語となりました。
しばらくの間、SQLはその使命を見事に果たしたかのように思われました。
Part 2: NoSQLの逆襲
ChamberlinとBoyceがSQLを開発している間、カリフォルニアの第2のエンジニア グループが、後に広く普及してSQLの存在を脅かすことになる別の新進プロジェクトに取り組んでいたことを、彼らは知りませんでした。
しかし、別のエンジニアが現れて1989年にWorld Wide Webを発明するまでは、実はSQLは問題なかったのです。
雑草のように繁茂したインターネットとWebは、無数の方法で私たちの世界を大規模に破壊しましたが、データコミュニティにとっては、ある特別な頭痛の種が生まれました。 まるで100万個のデータベースが泣き叫んで突然過負荷になったかのように、力に乱れが生じたのです。
そこで新たに2つのインターネットの巨人がブレークスルーを起こし、この新しいデータの猛攻撃を助けるために、独自の分散型非リレーショナルシステムを開発しました。 Googleの「MapReduce」（2004年発表）と「Bigtable」（2006年発表）、そしてAmazonの「Dynamo」（2007年発表）です。 これらの重要な論文は、Hadoop（MapReduce論文に基づく、2006年）、Cassandra（Bigtable論文とDynamo論文に大きく影響された、2008年）、MongoDB（2009年）など、さらに多くの非リレーショナルデータベースを生み出しました。
そして、ソフトウェア開発者のコミュニティはNoSQLを受け入れ、GoogleやAmazonの著者が意図していたよりもはるかに広い範囲で受け入れました。 その理由を理解するのは簡単です。 NoSQLは新しくて輝いていて、スケールとパワーを約束し、エンジニアリングの成功への近道のように見えました。
開発者たちはすぐに、SQLを持たないことが実はかなりの制限になることに気づきました。
これらのNoSQL言語は新しいものであるため、完全には開発されていませんでした。 例えば、リレーショナルデータベースでは、SQLに必要な機能（JOINなど）を追加する作業が何年も前から行われていましたが、NoSQL言語の未熟さは、アプリケーションレベルでより複雑さが求められることを意味します。 また、JOINの欠如は非正規化につながり、データの肥大化と硬直化を招きました。
一部のNoSQLデータベースは、CassandraのCQLのように、独自の「SQLに似た」クエリ言語を追加しました。 しかし、これはしばしば問題を悪化させました。
コミュニティの一部は、早くからNoSQLの問題点を認識していました（例えば、2008年のDeWitt氏とStonebraker氏）。
パート 3: SQL の復活
最初はダークサイドに誘惑されましたが、ソフトウェア コミュニティは光明を見出し、SQL に戻り始めました。
まず、Hadoop（そして後にはSpark）の上にSQLインターフェイスが登場し、NoSQLを「Not Only SQL」と「バック・クロニム」するようになりました（ええ、いい試みです）。 MITとブラウン大学の研究者によるH-Store（2008年発表）は、最初のスケールアウトOLTPデータベースの一つでした。 また、Googleは、最初のSpanner論文（2012年発表）で、地理的に複製されたSQLインターフェイスのデータベースをリードしました（この論文の著者には、MapReduceのオリジナルの著者も含まれています）。その後、CockroachDB（2014年）などの先駆者たちが続きました。
同時に、PostgreSQLコミュニティが復活し始め、JSONデータ型（2012年）のような重要な改良が加えられ、PostgreSQL 10（パーティショニングとレプリケーションのより良いネイティブサポート、JSONのフルテキスト検索サポートなど）とPostgreSQL 11（並列化されたデータ定義機能の追加、ジャストインタイム・コンプリメンテーションの導入など）では大量の新機能が追加され、PostgreSQL 12ではさらに多くの機能が追加される予定です。 CitusDB（2016年、現在はMicrosoftが所有）や私のような会社（TimescaleDB、2017年にリリース）は、特殊なデータワークロードのためにPostgreSQLを拡張する新しい方法を見つけました。
実際、私たちがTimescaleDBを開発する道のりは、業界が歩んできた道のりを密接に反映しています。 TimescaleDBの初期の内部バージョンには、”ioQL “と呼ばれる独自のSQLライクなクエリ言語が搭載されていました。 私たちもダークサイドに誘惑されたことがあります。 しかし、一見簡単そうに見えても、構文の決定、各種コネクタの構築、ユーザーへの教育など、多くの作業が必要であることにすぐに気づきました。
ある日、私たちは、独自のクエリ言語を構築することは意味がないと気づきました。 重要なのは、SQL を採用することです。 これは、私たちが行った最高の設計上の決定の 1 つでした。 すぐにまったく新しい世界が広がりました。
でも、私たちの言葉を鵜呑みにしないでください。
Google は明らかに 10 年以上前からデータ エンジニアリングとインフラストラクチャの最先端を走っています。
Googleの2つ目の主要なSpanner論文（Spanner: Becoming a SQL System, May 2017）を見てみると、私たちの独自の調査結果を補強していることがわかります。
例えば、GoogleはBigtableの上に構築を始めましたが、その後、SQLの欠如が問題を引き起こすことを発見しました（以下、すべての引用文の強調は私たちのものです）:
「これらのシステムは、データベースシステムの利点のいくつかを提供していましたが、アプリケーション開発者がしばしば依存する多くの伝統的なデータベース機能を欠いていました。 例えば、堅牢なクエリ言語は、開発者がアプリケーションのデータを処理したり集計したりするために複雑なコードを書かなければならないことを意味します。 その結果、私たちはSpannerをフル機能のSQLシステムにすることを決定しました。クエリ実行は、Spannerの他のアーキテクチャ機能（強力な一貫性やグローバルレプリケーションなど）と緊密に統合されています。”
論文の後半では、NoSQL から SQL への移行の理由をさらに詳しく説明しています。
Spanner の元々の API は、個々のテーブルやインターリーブされたテーブルのポイント ルックアップやレンジ スキャンのための NoSQL メソッドを提供していました。 NoSQLメソッドは、Spannerを起動するためのシンプルなパスを提供し、シンプルな検索シナリオでは引き続き有用ですが、SQLは、より複雑なデータアクセスパターンを表現したり、データに計算を押し付けたりする上で、大きな付加価値を提供しています。
この論文では、SQL の採用が Spanner に留まらず、実際に Google の他の部分にまで及んでおり、今日では複数のシステムが共通の SQL 方言を共有していることも説明しています。
SpannerのSQLエンジンは、「Standard SQL」と呼ばれる共通のSQL方言を、F1やDremelなどの内部システムを含むGoogleの他のいくつかのシステムと共有しています（中略）。
Google社内のユーザーにとっては、システム間での作業の障壁を低くすることができます。 Spannerデータベースに対してSQLを書いている開発者やデータアナリストは、構文やNULL処理などの微妙な違いを気にすることなく、その言語の理解をDremelに移すことができます。
このアプローチの成功が物語っています。 Spanner は、AdWords や Google Play など、Google の主要なシステムですでに「真実のソース」となっており、「潜在的なクラウドの顧客は、圧倒的に SQL の使用に興味を持っています」
そもそも Google が NoSQL の動きを始めたことを考えると、今日 SQL を採用しているのは非常に注目に値します。
そもそもGoogleがNoSQLのムーブメントを起こしたことを考えると、現在SQLを採用していることは非常に注目に値する。 “
このことがデータの将来にとって何を意味するのか。
このアイデアは、ある重要な問題を解決するために生まれました。任意のネットワークデバイスにおいて、下にハードウェアのレイヤー、上にソフトウェアのレイヤーがあるスタックを想像してみてください。 ネットワークのハードウェアにはさまざまなものがあり、同様にソフトウェアやアプリケーションにもさまざまなものがあります。
ネットワークにおけるユニバーサル・インターフェースの役割は、インターネット・プロトコル（IP）が担っており、ローカル・エリア・ネットワーク用に設計された低レベルのネットワーク・プロトコルと、高レベルのアプリケーションおよびトランスポート・プロトコルとの間の接続層として機能しています。
私たちは、SQL がデータ分析のための普遍的なインターフェイスになったと考えています。
私たちは、データが「世界で最も貴重な資源」になりつつある時代に生きています。 その結果、特殊なデータベース（OLAP、時系列、ドキュメント、グラフなど）、データ処理ツール（Hadoop、Spark、Flink）、データバス（Kafka、RabbitMQ）などがカンブリア爆発的に増えています。
ネットワークのように、下にインフラ、上にアプリケーションと、複雑なスタックを持っています。 一般的には、このスタックを動作させるために多くのグルーコードを書くことになります。
必要なのは、このスタックの一部が互いに通信できるようにするインターフェースです。 理想的には、業界ですでに標準化されているものです。
これが SQL の力です。 IP のように、SQL は普遍的なインターフェイスです。
しかし、SQL は実際には IP よりもはるかに重要です。 なぜなら、データは人間によっても分析されるからです。
SQLは完璧でしょうか？
SQLは完璧でしょうか？いいえ、しかし、コミュニティのほとんどの人が知っている言語です。 そして、より自然言語指向のインターフェイスに取り組んでいるエンジニアがすでに存在していますが、それらのシステムは何に接続するのでしょうか。
だから、スタックの一番上には別のレイヤーがあるのです。
SQL is Back
SQL が戻ってきました。 NoSQL ツールを組み立てるために接着剤のコードを書くのが面倒だからというだけではありません。 無数の新しい言語を学ぶために従業員を再教育するのが大変だからというだけではありません。
それだけではなく、世界がデータで満たされているからです。 データは私たちを取り囲み、結びつけています。 最初は、人間の感覚と感覚神経系に頼ってデータを処理していました。 今では、ソフトウェアやハードウェアのシステムも十分に賢くなってきています。
脆弱なシステムと100万ものインターフェースの世界に住むか、SQLを採用し続けるか。 あるいは、SQLを採用し続けるか。
この記事が気に入ったら、さらに詳しく知りたいですか？
GitHubをチェックしたり、Slackコミュニティに参加したり、コミュニティのメーリングリストに登録したりすることができます。
GitHubをご覧ください。
データベースの歴史についてもっと知りたい方にお勧めの本（将来の「TimescaleDBデータベース入門クラス」のシラバスのようなもの）です。
- A Relational Model of Data for Large Shared Data Banks (IBM Research, 1970)
- SEQUEL: A Structured English Query Language (IBM Research, 1974)
- System R: Relational Approach to Database Management (IBM Research, 1976)
- MapReduce: Simpleized Data Processing on Large Clusters (Google, 2004)
- C-Store: A Column-oriented DBMS (MIT, others, 2005)
- Bigtable: A Distributed Storage System for Structured Data (Google, 2006)
- Dynamo: Amazon’s Highly Available Key-Value Store (Amazon, 2007)
- MapReduce: A major step backwards (DeWitt, Stonebreaker, 2008)
- H-Store: A High-Performance, Distributed Main Memory Transaction Processing System (MIT, Brown, others, 2008)
- Spark: Cluster Computing with Working Sets (UC Berkeley, 2010)
- Spanner: Googleのグローバル分散型データベース（Google、2012年）
- Early History of SQL（Chamberlin、2012年）
- How the Internet was Born（Hines、2015年）
- Spanner: SQLシステムになるために（Google, 2017）