SQLがNoSQLを引き継ぐ理由と、それが将来何をもたらすか

SQLが起動し、闇の勢力に反撃する-NoSQL

コンピュータ時代の初期から、人類は指数関数的に増加するデータを収集してきました。それに伴い、データストレージ、処理、分析システムの要件が増大しています。 このため、過去10年間で、ソフトウェア開発者はSQLを、増加するデータ量に合わせて拡張できない旧式のテクノロジーとして放棄しました-その結果、NoSQLデータベースが登場しました：MapReduceおよびBigtable、Cassandra、MongoDBなど。

ただし、SQLは今生まれ変わりました。 すべての主要なクラウドサービスプロバイダーは、人気のあるマネージドリレーショナルデータベースサービスを提供しています。AmazonRDS 、 Google Cloud SQL 、 Azure Database for PostgreSQL （文字通り今年開始）などです。 Amazonによると、PostgreSQLとMySQLに準拠したAuroraデータベースは「 AWSの歴史の中で最も急成長しているサービス 」 になりました。 HadoopおよびSparkプラットフォームの上位にあるSQLインターフェースも人気を失うことはありません。 そして先月、KafkaはSQLサポートを開始しました 。 この記事の著者は、自分自身がSQLを完全にサポートする新しい時系列データベースを開発していることを控えめに認めています。

この記事では、振り子がSQLに戻った理由と、データベースの開発と分析の専門家に期待することを理解しようとします。

Alconostに翻訳

パート1.新しい希望

SQLが返される理由を理解するために、最初に戻って、このテクノロジーが登場した理由を見てみましょう。


すべての良い物語のように、私たちのものは70年代に始まります

このリレーショナルデータベースは、70年代初頭にIBM Researchで生まれました。 当時、クエリ言語は複雑な数学論理に基づいており、それほど複雑ではない表記法に基づいていました。 焼きたての2つの科学候補、ドナルドチェンバリンとレイモンドボイスは、リレーショナルデータモデルに感銘を受けましたが、同時に、使用されたクエリ言語がその普及を妨げることに気付きました。 彼らは、「 数学やコンピュータープログラミングのコースを受講していないユーザーにとってより便利な 」新しいクエリ言語を開発することを決めました。



SQL（項目A、B）とSQL（ ソース ）の前のクエリ言語

想像してみてください。インターネットもパソコンもありません。Cが出版されたばかりで、コンピューターシステムの分野の2人の若い専門家は、「 コンピューター業界の成功はユーザーカテゴリの発展により大きく依存し、訓練を受けたコンピューターの専門家ではありません 。」 彼らは英語と同じくらい簡単に読むことができるクエリ言語を必要としていましたが、同時にデータベースの管理と操作を可能にしました。

その結果がSQLであり、1974年に世界に初めて導入されました。今後数十年で非常に普及します。 リレーショナルデータベースがソフトウェア業界（たとえば、System R、Ingres、DB2、Oracle、SQL Server、PostgreSQL、MySQL、その他多数）に定着するにつれて、SQLはデータベースインタラクション言語として広く普及し、競争が激化するエコシステムで一般的に受け入れられるようになりました。

（残念ながら、レイモンド・ボイスはSQLの成功を見ることができませんでした。SQLに関する最初の報告の1か月後の1か月で脳動脈瘤で亡くなりました。26歳で、彼にはまだ妻と娘がいました。）

しばらくの間、SQLがそのタスクを完了し、すべてが順調に進んでいるように見えました...しかし、インターネットが登場しました。

パート2. NoSQLの逆襲

チェンバリンとボイスは、SQLの開発中、カリフォルニアが別の有望なプロジェクトに取り組んでいることを知りませんでした。 このプロジェクトはARPANETで 、その生年月日は1969年10月29日です。


アルパネットネットワークの作成者（すべてではありません）が最終的に現代のインターネット（ ソース ）になりました

しばらくの間、SQLは静かな存在を導きました-1989年に別のエンジニアがWorld Wide Webを発明しました。


インターネットを発明した物理学者（ ソース ）

Webとインターネットは雑草のように成長し、広がり、使い慣れた世界を数え切れないほど変化させていますが、データベーススペシャリストには非常に具体的な頭痛の種があります。

インターネットの成長に伴い、ソフトウェア開発者は、リレーショナルデータベースがこのような負荷を処理できないことを発見しました。 数百万のデータベースが恐怖で叫び、まるで突然沈黙し、過負荷になったかのように、フォースにはinがありました。

その後、2つの新しいインターネットジャイアントが突破口を開きました-データ量の増加の問題を解決するために設計された独自の分散非リレーショナルシステムを開発しました：MapReduce（ 2004年の公開 ）およびGoogleのBigtable（ 2006年の公開 ）およびDynamo（ 2007年の公開 ）アマゾンから。 肥沃な土壌に落ちたパブリッシュされた記事は、非リレーショナルデータベースの良い収穫をもたらしました：Hadoop（MapReduce、 2006に基づく）、Cassandra（著者はBigtableとDynamoに触発されました、 2008 ）、MongoDB（ 2009 ）など。新しいシステムは主にゼロから作成されたため、SQLを使用しなかったため、「NoSQLの動き」が拡大しました。

GoogleとAmazonの作成は、著者自身が想定したよりもはるかに広範に広がっているようです。 そして、これが起こった理由は理解できます。NoSQLシステムは新しいものでした。 スケーラビリティとパワーを約束しました。 開発を成功させるための手っ取り早い方法のように思えました。 そして、問題が出始めました。


NoSQLの誘惑に負けた開発者。 そうしないでください。

開発者はすぐに、SQLの欠如が実際に大幅に制限することに気付きました。 各NoSQLデータベースには独自のクエリ言語があり、次のことを意味しました。より多くの言語を学習する（および同僚を訓練する）必要がありました。 これらのデータベースをアプリケーションに接続することはより困難であり、それにより大量の不安定なミドルウェアを作成する必要がありました。 サードパーティのエコシステムがない-これは、企業がデータベースを視覚化して操作するための独自のツールを開発する必要があることを意味します。

NoSQL言語が登場したばかりなので、完全に呼び出すことはできませんでした。たとえば、リレーショナルデータベースでは、長年にわたって、必要な機能をSQLに追加する作業を行いました（たとえば、JOIN）。 そのような未熟さは、アプリケーションレベルでの複雑さを意味します。 JOIN演算子が存在しないことも非正規化につながり、データの膨張と柔軟性の欠如をもたらしました。

NoSQLキャンプの一部のデータベースには、独自のSQLに似たクエリ言語が追加されています（CassandraデータベースのCQLなど）。 そして、しばしばより悪くなるだけです：より一般的なものとほぼ一致するインターフェースを使用すると、実際には、より多くの精神的な努力が必要になります。


SQLに似たクエリ言語は、スターウォーズの「ホリデースペシャルエディション」に似ています。 模倣を避けます。 （そして、「特別な休日の問題」を見ないでください。）

すでに初期段階にある一部の専門家は、NoSQLで問題を発見しました（たとえば、 DeWittやStonebreaker-2008年 ）。 時間が経つにつれて、彼らは彼ら自身のハードな経験からこれらの問題を感じたますます多くのソフトウェア開発者によって加わりました。

パート3. SQLリターン

最初は「ダークサイド」に誘われて、ソフトウェア開発者はすぐに光を見て、徐々にSQLに戻り始めました。

最初は、SQLインターフェースがHadoopおよび（少し後で）Sparkプラットフォームの上に登場したため、業界は「SQLだけでなく」を「NoSQL」として理解し始めました（良い試みです）。

次に、NewSQLが登場しました。「new SQL」は、完全なSQLサポートを備えたスケーラブルなデータベースです。 オンライントランザクション処理（OLTP）を備えた最初のスケーラブルなデータベースの1つは、マサチューセッツ工科大学とブラウン大学のHストア（ 2008年に公開 ）でした。 また、Googleは開発なしではできませんでした：Spannerに関する最初の記事（ 2012年の出版物 、著者の中にはMapReduceのクリエイターもいます）、同社はSQLインターフェイスを使用したジオレプリケーションデータベースへの動きを主導し、CockroachDB（ 2014 g。 ）。

同時に、PostgreSQLコミュニティが復活し始めました：たとえば、JSONデータタイプ（2012）、 PostgreSQL 10の新機能のサラダなど、重要な改善が登場しました：セクショニングとレプリケーションの組み込みサポートの改善、JSONの全文検索のサポートなどその他（今年10月にリリース）。 CitusDB（ 2016 ）やこれらの行の著者（ TimescaleDB 、 今年リリース ）などの他の開発者は、特殊なワークロード向けにPostgreSQLをスケーリングする新しい方法を発見しました。



TimescaleDBの開発で辿った道は、業界全体と非常によく似ています。 初期の内部バージョンでは、TimescaleDBには独自のSQLライクなクエリ言語「ioQL」がありました。はい、ダークサイドも私たちを誘惑しました。私たち自身のクエリ言語が大きな利点であるように思われました。 最初は、これは複雑に見えませんでしたが、やがて予想以上に多くの作業があることがわかりました。たとえば、構文を決定し、「コネクタ」を開発し、ユーザーにこの言語を教える必要がありました。私たちは自分の言語でいるということです！ -クエリの正しい構文を常に探しており、SQLで安全に表現できます。

したがって、独自のクエリ言語を開発することは無意味であることに気付いたときです。 これにより、SQLに切り替え、最高の技術ソリューションの1つであることが判明しました。まったく新しい世界が私たちに開かれました。 現在、私たちのデータベースはまだ5か月前であり、ユーザーは既にデータベースを使用してすぐに使用でき、すぐに「視覚化ツール（Tableau）」、人気のORMのコネクター、多くのバックアップツールとオプション、マニュアルとヒントに関する多くの素晴らしい機能を備えています構文など

私たちの言葉を受け入れる必要はありません。Googleが何をするのか見てみましょう。

10年以上にわたり、Googleはデータベース開発と関連インフラストラクチャの最前線にいます。 したがって、彼らがしていることに細心の注意を払う必要があります。

最近リリースされたSpannerデータベースに関する2番目の主要なGoogleの出版物（ Spanner：Becoming a SQL System-「Spanner into a SQL system」、2017年5月）を見ると、私たちが到達した結論が確認されていることがわかります。

たとえば、GoogleのエンジニアはBigtableでシステムを構築し始めましたが、SQLがないために問題が発生することがわかりました。

「これらのシステムはデータベースとしていくつかの利点を提供しましたが、アプリケーション開発者がしばしば依存する従来のデータベース機能の多くが欠けていました。 重要な例は、よく考え抜かれたクエリ言語の欠如です。そのため、データを処理および集計するアプリケーションの開発者は複雑なコードを書く必要がありました。 その結果、Spannerを、クエリの実行がデータベースの他のアーキテクチャ機能（厳密な一貫性やグローバルレプリケーションなど）と密接に関連する完全に機能するSQLシステムに変えることにしました。

記事の後半で、彼らはNoSQLからSQLへの移行をより詳細に実証しています。

「元のSpannerデータベースAPIには、ポイント検索を実行し、さまざまな範囲のインターリーブテーブルを検索するためのNoSQLメソッドがありました。 「NoSQLのメソッドを使用すると、システムの起動が簡単になり、単純な検索タスクにも便利になりましたが、データへのアクセスやデータの計算のより複雑なパターンを記述する場合、SQLには大きな利点があります

また、この記事は、SQLへの移行がSpannerプロジェクトで止まったのではなく、実際には会社の他のテクノロジーにも広がっていると述べています。今日では、SQLの一般的な方言がいくつかのシステムで使用されています：

「SpannerデータベースのSQLコアは、内部（F1とDremelの間）と外部システム（BigQueryなど）の両方を含む他のいくつかのGoogleシステムと組み合わせて「標準SQL」を使用します...
社内のユーザーにとって、このアプローチは複数のシステムで作業する際の障壁を減らします。 SpannerでSQLクエリを作成する開発者またはデータアナリストは、構文の複雑さやNULL処理などを心配することなく、Dremelシステムでスキルを使用できます。

このアプローチの成功は、それ自体を物語っています。 現在、Spannerは、AdWordsやGoogle Playなどの主要なGoogleシステムのプラットフォームであると同時に、「 潜在的なクラウドプラットフォームの顧客は、SQLの使用に圧倒的に関心を持っています」。
NoSQLの動きをもたらしたGoogleが今日SQLに戻っていることは注目に値します。 （したがって、一部の人は疑問に思った：「 Googleの開発者はビッグデータ業界を10年間邪魔しなかったのか？ 」）

データ処理業界の未来：ボトルネックとしてのSQL

コンピュータネットワークには、ボトルネックなどがあります。

このアイデアは、次のように定式化できる主な問題を解決するために生まれました。 ネットワークデバイスを取り、下の機器層と上のソフトウェア層の一種の「パイ」を想像してください。 ネットワークデバイスは大きく異なる場合があります。 多くの異なるアプリケーションやソフトウェアも同様です。 タスクは、使用する機器に関係なく、ソフトウェアがネットワークに接続できるようにすることです。 ネットワーク機器は、ソフトウェアに関係なく、ネットワーク要求の処理方法を知る必要があります。


ネットワーク技術のボトルネック（ ソース ）

ネットワークでは、IPのボトルネックはボトルネックです。これは、ローカルネットワーク向けの低レベルネットワークプロトコルと、高レベルのアプリケーションおよびトランスポートプロトコルとの間の共通インターフェースとして機能します。 （ ここに良い説明があります。）そして、簡素化するために、このインターフェースはコンピューターシステムで一般的に受け入れられています。これにより、ネットワークを接続し、デバイス間でデータを交換できます。 そして、この「ネットワークのネットワーク」は、今日知られているように、さまざまな情報に満ちた多面的なインターネットに変わりました。

この記事の著者は、SQLがデータ分析のボトルネックになったと考えています。

私たちは、データが「世界で最も貴重なリソース」になりつつある時代に生きています（ エコノミスト、2017年5月 ）。 その結果、特殊なデータベース（OLAP、時系列データベース、ドキュメント用データベース、グラフなど）、データ処理ツール（Hadoop、Spark、Flink）、データ転送バス（Kafka、RabbitMQ）の「カンブリア爆発」を観察することができました。 ）など。サードパーティの視覚化ツール（Tableau、Grafana、PowerBI、Superset）、Webフレームワーク（Rails、Django）、またはデータベースを使用する特別に設計されたアプリケーションなど、このようなデータインフラストラクチャで動作する多数のアプリケーションが登場しています。


コンピュータネットワークの場合と同様に、下部にインフラストラクチャがあり、上部にアプリケーションがある複雑な「パイ」があります。 原則として、このパイを機能させるには、多くの接続コードを作成する必要があります。 しかし、そのようなコードは信頼できません。慎重に保守する必要があります。

このパイの各部分が相互にやり取りできるようにする共通のインターフェースが必要です。 何よりも、すでに業界標準となっているものがあります。 最小限の労力で異なるレイヤーを交換できるようにするもの。

そして、ここがSQLの場所です。IPと同様に、SQLは一般的なインターフェイスです。

しかし、SQLは依然としてIPプロトコルよりも普遍的です。人々はデータを分析する必要があり、SQL言語のクエリは意図したとおりに人が読むことができます。

SQLは完璧ですか？ いや しかし、ほとんどのデータベースの専門家によく知られているのはこの言語です。 もちろん、どこかで、自然言語により焦点を当てたインターフェイスの作業がすでに進行中ですが、そのようなシステムは何に接続されますか？ SQLへ。

したがって、パイの最上部には別のレイヤーがあり、このレイヤーが私たちです。

SQLが返す

SQLが返す-これの主な理由は、NoSQLツールを接続するためのミドルウェアを書くのが退屈だからではありません。 そして、多くの新しい言語で専門家を訓練することは難しいということではありません。 そして、その基準を考えるべきではありません。

主な理由は、私たちの世界はデータでいっぱいだからです。 むかしむかし、私たちは自分の感覚と神経系に頼ってそれを処理していました。 今、私たちのハードウェアシステムとソフトウェアは、私たちを助けるのに十分スマートになっています。 私たちは私たちの周りの世界をよりよく理解したいので、より多くのデータを収集しています-したがって、このデータを保存、処理、分析、視覚化するシステムの複雑さはますます大きくなります。


依田データ処理ウィザード

私たちには選択肢があります：脆弱なシステムと数百万のインターフェースの世界に住むか、SQLに戻ってフォースの不均衡を回復します。


翻訳者について

この記事はAlconostによって翻訳されました。

Alconostは、 ゲーム 、 アプリケーション、およびサイトを68言語でローカライズしています。 ネイティブ言語の翻訳者、言語テスト、APIを備えたクラウドプラットフォーム、継続的なローカリゼーション、24時間365日のプロジェクトマネージャー、あらゆる形式の文字列リソース。

また、Google PlayとApp Storeの販売、画像、広告、教育、ティーザー、エクスプライナー、予告編のサイト向けに、 広告および教育用ビデオを作成しています。

詳細： https : //alconost.com