ITプロジェクトでは、誰もがコードを記述します。 エンジニアは数行を使用してKubernetesクラスターを管理し、Terraformクラウドを分散させ、多数の構成をAnsible、Chef、およびPuppetに変換します。 QAは、SpockとCucumberでビジネス向けのテストスクリプトを作成します。 アナリストは流developersで、多くの場合開発者より優れており、SQLを話します。 Markdown、AsciiDoc、またはLaTEX形式のプロジェクトドキュメントは、ビルドサーバー上で目的の形式に「コンパイル」されます。 開発者自身、これらのコードテイマーは、クライアント、サーバー、スクリプト、機能など、あらゆるライフケースでさまざまな言語を即座に話します。

コードは長い間神秘的な意味不明なものでなくなっており、現在では多くの首相でさえも 、何らかの形でアクセス可能で理解できるようになっています。 そして、このすべてのコードは標準のライフサイクルに関与しています。VCSによって管理され、コードレビュー、自動テスト、CI、CDを受けます。 一般的なツールとアプローチ、パフォーマンスと品質の指標が使用されます。 そしてすべてを合わせて、「コードとしてのすべて」という誇りのある名前が付けられています。

しかし、データベースの世界は伝統的に、この進歩とテクノロジーの贅沢とは一線を画しています。 データベースの開発と保守のプロセスは長年にわたって変わらず、世界中の開発者、管理者、ユーザーに恐怖と恐怖を植え付け続けています。 しかし、通常のコードの形式でデータベースを提示することは可能ですか？ メインの開発プロセスに近づき、一般的なツールとアプローチを使用しますか？ カットの下でこれについて。

典型的なプロジェクト

私たちのほとんどは、欲しいかどうかに関係なく、毎日さまざまなデータベースを処理する必要があります。 パフォーマンスの問題、競争力のあるアクセスなどを設計、開発、管理、解決するだけです。 同時に、データの収集、処理、および保存の要件は常に厳しくされています。一部の人には100％の整合性が必要ですが、他の人には必要ありません。 数年保存されるものもあれば、数秒保存されるものもあります。 一部の損失は数百万件の損失をもたらしますが、他の損失は事業にとって目立たないでしょう。

この点で、 Polyglot Persistenceアプローチは長い間登場しており、成功裏に使用されています。その結果、最近では、あらゆるプロジェクトで単一のDBMSを満たすことができます。 代わりに、特定のタスクごとに、古き良きリレーショナルのすべての問題をなんとかして解決しようとせずに、最適なベースが選択されます。 また、たとえば、マイクロサービスアーキテクチャを使用すると、プロジェクト全体のクリーンアーキテクチャを損なうことなく、単一のサービス内で特定のDBMSとの作業を分離し、最大のメリットを引き出すことができます。 その結果、「 リレーショナル 」（それがない場合）+「 キーバリューDB 」+「 ワイドカラムDB 」+「 ドキュメント指向DB 」+「 検索エンジンDB 」+「 グラフDB 」+「 その他DB 」 =「 成功！ 」。 さらに、これらのデータベースのインスタンス（インスタンス）の数は増加しています-シャーディング、レプリケーション、分散DBMS。 さらに、これらはすべて、開発、テスト、本番などのさまざまな環境で「拡張」され、維持される必要があります。

根拠のないように、データベース管理および開発の分野のソリューションに関する巨大企業の最近のアンケートからの抜粋を引用します。Quest Software- DBA問題：DB管理のトレンド （ダウンロードするには、簡単な登録が必要ですが、それだけの価値があります）：

• 質問2：「 あなたの会社で実行されているリレーショナルデータベースのインスタンスはいくつですか？ 」-結果によると、回答者の24％が100から500のインスタンスを使用し、19％が500を超えています。
• 質問4：「 あなたの会社ではいくつの異なるDBMS（SQLおよびNoSQL）が使用されていますか？ 」-56％が2〜3の異なるDBMSを使用し、40％が5を超え、回答者の4％のみが使用しています DBMS
• 質問番号18：「 プロジェクト内のデータベースインスタンスの数はどうなりますか？ 」-回答者の2/3が毎年の増加を指摘しています。
• 質問30（結果）：「 今後3年間でDBAが直面する主な問題は何ですか？ 」
  
  1. 51％-「 DBMSインスタンスの数を増やす 」
  2. 40％-「 新しい非リレーショナルデータベースを管理する機能 」
  3. 32％-「 IT予算の削減」（予想どおり、最初の2つの問題により膨れ上がります）

これの準備はできていますか？

特定のDBMSを効果的に使用するには、IDEマネージャーやDBマネージャー、監視、モデリング、スキーマ移行ツールなど、特別なツールが必要であることは周知の事実です。 ただし、これらのツールと環境の大部分は、単一のリレーショナルDBMSがすべてのプロジェクトに十分であり、「 アジャイル 」、「 DevOps 」、「 CI / CD 」などの流行語で栄えた時代に発明され開発されました。現れなかった。 それ以来、ほとんど変わっていない データベースの開発と保守の分野は常に閉鎖的で保守的であり、ほとんどの開発者はそれを古くて複雑で理解できないものに関連付けています。 今日、最も多様なDBMSのいくつかとそのインスタンスの数十/数百がほぼすべてのプロジェクトエコノミーで同時に動作しているとき、開発者とDBAの通常の日常的な問題はさらに深刻になっています。

従来、データベースを操作するための最も一般的で不可欠なツールは、すべての種類のIDEです。 通常、これは、単一の作業環境での開発と管理のための最も多様な機能を主にグラフィカルなインターフェースの下で組み合わせた包括的なソリューションであり、データベースとの作業をより生産的で快適にします-目的のメニュー項目をクリックするだけです。 確かに、 EMS SQL Manager 、 Toad 、 dbForge 、 その他の多くのクールなものなしでやる人はほとんどいません。

このような「ボックス」の主な問題の1つは、新機能と新しいDBMS（市場に出ることを止めない）のプレッシャーの下で、かなり複雑になり、毎回より複雑になり続けることです。 さらに、使用中（多くの場合、特定のDBMSの機能をマスターする必要はありませんが、IDE自体のトリックと機能を習得する必要はありません）および実装（したがって、このようなシステムは通常閉鎖され、非常に有償です）の両方です。 オープンソースDB IDEの旗艦である多くの（私を含む）最愛のDBeaverでさえ 、 そのEnterpriseバージョンでのみ NoSQLソリューション（および現在、それなしで実行しているプロジェクト）をサポートしています。 これらすべてに加えて、非常に必要で興味深いDBMS機能のサポートは、IDE開発者がそれをプッシュする必要があると考えるまで（または、カウントしてプッシュすることすらまったくできない）、期待できないという非例示的なリスクが残っています。

この状況に対応して、ユーザー自身が新しいDBMSに必要な機能やサポートが現れるまで待たずに、自分自身やプロジェクトに最適な方法で、入ってくる問題を個別に解決します。 GitHubは、さまざまな程度の複雑さのソリューションに満ちています。 基本的に、これらはすべての場合のSQLスクリプトのセットです（ dataegret / pg-utils 、 NikolayS / postgres_dba 、 gwenshap / Oracle-DBA-Scripts 、 ktaranov / sqlserver-kit 、 lestatkim / opensql ）。 または、トップのようなpg_activityやpgcenterなどのコンソールユーティリティ。 また、完全に独立したクライアントと監視ツール（ pg_web 、 pg_hero ）から始まり、たとえば、単純にシステムテーブル上のhtmlラッパー（ pg_web_stats 、 pg_stats_viewer ）で終わる、あらゆる種類のWebベースのツール。 その結果、「プログラマーのためのプログラマー」、「DBAのためのDBA」などのソリューションのクラス全体が形成され、その助けを借りて、DBMSユーザーはお互いの経験を直接共有します。

コードとしてのすべて

サーバー管理とソフトウェア構成管理で、以前にも同様の状況が観察されていました。 その後、新しい要件と技術が絶えず出現するにつれて、プロジェクトのインフラストラクチャが著しく複雑になり始め、そこで実行されるサーバーとソフトウェアの数が劇的に増加しました。 また、新しいビジネス機能を備えたソフトウェアをより頻繁に、そして継続的に顧客に提供する必要もありました。 この経済全体を構成および管理するための既存のツールは貧弱な仕事をしました。その結果、インフラストラクチャが特別なDSLで構成された「コードとしてのインフラストラクチャ」アプローチとAnsible、Chef、Salt、P​​uppetなどのツールが登場しました。 これにより、柔軟性と創造性の自由が得られます。 そして、そのようなDSLのコードは、メインアプリケーションコード（Java、C＃、Rubyまたはその他のプログラミング言語）とともに標準のライフサイクルに参加します。つまり、バージョン管理システムに格納されます（すべての結果-ブランチ、フォーク、コードレビュー）。アセンブリサーバーでのビルド、自動テストの実行など。

将来、このアプローチの影響は他の分野でも顕著になりました。

• 「 コードとしてテスト 」- スポック 、 キュウリ 、 ガトリング 、 ポストマン
• 「 コードとしてのパイプライン 」- ジェンキンスパイプライン
• 「 コードとしてのドキュメント 」-Markdown、AsciiDoc、LaTeX
• 「 図としてのコード 」 -PlantUML 、 Graphviz 、 Mermaid 、 フローチャート .js
• 「 コードとしてのDNS 」 -DNSControl 、 OctoDNS
• 「 コードとしてのプレゼンテーション 」 -rename.js

ますます多くの人々がコードを書くことを恐れなくなり、これが標準になりつつあります。 これにより、より柔軟な構成が可能になり、一般的なフローで一般的なツール（バージョン管理、メトリック、視覚化、レポート、テストなど）を使用することもできます。 多くの専用ツールでは、グラフィカルインターフェイスが、より柔軟なプログラミングインターフェイス、さまざまなDSLおよび構成ファイルに置き換えられるか、補足されます。

このトピックに関する詳細は、Alexander Tarasov（ aatarasoff ） "Everything as a Code"のレポートに記載されています。

コードとしてのデータベース

そして、データベースの広大な世界でこれはどうですか？ Googleに「 コードとしてのデータベース 」という簡単なフレーズを入力したので、DZoneに投稿された（ただし何！）-「 データベースとしてのデータベース：斬新なコンセプト 」を除いて、興味深いものは見つかりませんでした。

データベースファーストのアプローチについて多くのことを話します。 データが企業の最も貴重な資産であるという事実について多くのことを話します。 しかし、ダンノースが彼のプレゼンテーションの 3番目のスライドで提示したコンセプトはどうでしょうか。 データベースをコードとして扱うとどうなりますか？

魅力的ですが、スライド＃5および＃6（残念ながら、ビデオは見つかりませんでした）データベーススキーマを「コードを介して」管理する2つのアプローチについて説明します。インクリメンタルマイグレーション（Liquibase、Flyway）およびべき等DDLスクリプト（ Redgate ）です。 したがって、回路もコードであり、VCSの制御下にあり、ビルドサーバーで組み立てられ、自動テストが実行されます。

データベースを扱う分野での考え方を変えるには何が必要ですか？ データベースを魔法のアーティファクトまたは一意のスクリプトとして扱うのをやめ、アプリケーションの通常のコードを見るのと同じ角度からそれを見る必要があります。

再び力強く言いました、私はすでに私の目に涙を浮かべています。 残念ながら、レポートと投稿自体は、「コードとして」、 データベーススキーマへの変更のみを考慮します （ データベーススキーマの移行）。

アプリケーションのソースコードを宝物として扱います。 そして、これは絶対に真実です。コードはあらゆるアプリケーションの中心です。 しかし、 データベースの変更もバージョン管理システムの管理下にあり、自動化され、オンデマンドでリリースする準備ができていて、メインコードのように「DevOps-laws」に従うべきではないでしょうか。

しかし、ちょっと待って...

データベースはスキーマだけではありません！

最新のDBMSのほとんどは独自のクエリ言語を提供し、その助けを借りて、格納されているデータ（いわゆるDML）を受け取って変更するだけでなく、そのスキーマ（いわゆるDDL）を操作するだけでなく、一般的にそれを受け取ります（私はこの言葉を恐れていません）現在のデータベースとその状態に関するメタ情報（システムテーブルとビューから）およびそのほとんどすべての操作（データベースの起動、停止、読み取り専用への転送、統計の収集、メモリの管理など）を実行します。 また、このようなコードは、前の段落で説明した概念にも非常によく適合しています。

そして、データベースとクエリ言語に関して言えば、最初に思い浮かぶのはもちろん、 古くて良いSQLです。 しかし、NoSQLソリューションの需要が大幅に増加している現在、近い将来に（そして、ほとんどが密接に関連しているリレーショナルデータベースにも）頼りにすることができますか？

「結局のところ、SQLがすべてですか？...」

あなたは私に正しく尋ねることができます-「 ほこりの多い関係がエンタープライズの血なまぐさいだけで彼らの人生を生き延びたとき」、私はここでNoSQLとスキーマレスデータベースの時代にどんな種類のSQLについて話しているのですか。 初期のHabr（テクノロジーの世界のトレンドのリトマステストとして）は、かつてSQLとリレーショナルテーブルに関する否定性で満たされ、スピーディーな死を予示しました（投票数は括弧内に示され、コメント数はスラッシュで示されます）。

• 2009- 「MongoDBまたはSQLを愛するのをやめる方法」 （ +115 / 99 ）
• 2010- NoSQLコレクションポイント （ +53/45 ）
• 2011- 「リレーショナルデータベースの運命は？」 （ +77 / 131 ）
• 2012- 「NoSQLデータベース：本質を理解する」 （ +129 / 75 ）

ただし、12歳頃から、Habréの雰囲気は著しく変わりました。

• 2012- 「noSQLを使用する前に考える1000回」 （ +109 / 130 ）
• 2013- 「NoSQLとビッグ​​データ-労働者を欺く？」 （ +75 / 286 ）
• 2014- 「MongoDBを使用しない理由」（+143/245） （ +143 / 245 ）
• 2017- 「SQLがNoSQLに勝る理由と、今後SQLがもたらすもの」 （ +22 / 105 ）
• 2018- 「いいえ、機械学習は必要ありません。SQLが必要です」 （ +102 / 417 ）

同時に、反SQLと反リレーショナルの感情は引き続き発生しますが、それらに対するコミュニティの反応はまったく異なります。

• 2014- 「RDBMSまたはRDBMSとNoSQLの欠点」 （ -34 / 79 ）
• 2015- 「履歴をダンプするのはリレーショナルデータベースの時間ではないですか？」 （ -7 / 309 ）

これらの感情の確認は、Konstantin Osipov （ kostja ）による「NewSQL：SQLはどこにも行きません」およびAndrey Nikolayenkoによる「Non-Relational SQL」による最近のレポートに記載されています 。 私は両方の声明の要約を提供する責任を負います：

• 「 NoSQLのSQL 」 -SQL （奇妙なことに）はNoSQL環境で非常に快適です。 ほとんどすべてのNoSQLデータベースでは、CassandraおよびScyllaDBのCQL 、AerospikeのAQL 、CouchbaseのN1QL 、および本格的な（または可能な限り近い）ANSI SQLなど、ある種のsqlに似たクエリ言語を使用できます。 Tarantool 、 ClickHouse 、 CrateDBのように 。
• 「クラウド内のSQL 」-クラウドジャイアントは、 Amazon RDS 、 Amazon Aurora 、 Oracle Cloud 、 Google Cloud SQL 、 Microsoft SQL Azure 、 Alibaba Cloud ApsaraDB 、 Yandex Managed Databasesなど 、さまざまなSQLストアをサポートしています 。
• 「 BigDataのSQL 」 -SQLはHadoopインフラストラクチャに長く緊密に統合されています。 2009年にHiveがHiveQLとともに登場し、年々、すでに直接サポートされているSQL- Impala （2011）、 Spark （2013）、 Kudu （2014）、 Presto （2015）、 Phoenix （2017）をサポートするソリューションが登場し始めました。
• 「 SQL in Streaming 」 -SQLは 、ストリーミングデータハンドラーのほとんどの標準になりました： Flink 、 Samza 、 Storm 、 Apex 、そして最近ではKafka 。
• 「 SQL in NewSQL 」-多くの最新DBMSは、SQLの幅広いサポート（ CockroachDB 、 FoundationDB 、 MemSQL ）を含むNoSQLと従来のリレーショナルソリューションの両方の利点を兼ね備えたNewSQLの方向で積極的に開発しています。

一般に、SQLは、リレーショナル条件をはるかに超えるものも含め、現代の条件では非常に快適です。 ほとんどすべてのデータソースは、SQLまたはSQLに似た言語で「通信」でき、リポジトリのデータまたはメタデータに関する必要な情報を取得し、任意の操作（作成、削除、開始、停止など）を実行できます。

これ以降（便宜上、許可を得て）「SQL」とは、「同じ」標準リレーショナルSQLだけでなく、そのすべてのサブタイプ（リレーショナルから遠く離れたものも含む）、および実際には組み込みQL DB。これにより、何か役に立つことができます。

なんでこんなこと？

また、92年目には素晴らしいANSI規格が登場しました。これにより、リレーショナルDBMSは、その内部構造を特別なスキーム（ 情報スキーマ）で記述できなければなりません。 T.O. サービスのテーブル/ビューに標準のクエリ言語を使用すると、任意のデータベースのメタデータを取得できます-スキーマ、テーブル、インデックス、列などを含む方法。しかし、実際には、これは単一のデータスキーマに限らず、標準外）、プロセス、セッション、クエリ実行計画、ディスクサブシステム、メモリ使用率などに関する情報を取得できます。

この標準は、四半世紀ほど前にリレーショナルデータベースにのみ登場したという事実にもかかわらず、ほとんどすべての最新のNoSQLおよびNewSQLデータベースも同様のものを実装しています。 たとえば、Cassandraには、 いくつかのシステムスキーム （またはkeyspace'ov-system、system_auth、system_schema、system_traces）があり、既に言及したCQLを使用してアクセスできます。 ClickHouseには特別な「システム」スキームがあります。 CockroachDBの開発者は通常、標準のinformation_schemaを実装するために振る舞いました。 そして、Mongoのドキュメントでさえ、 システムコレクションに満足しています 。

同時に、そのような体系的表現の数と拡張は絶えず増加しています。 たとえば、Postgresql（最もアクティブなコミュニティの1つを持つデータベースとして）では、information_schema自体、独自のpg_catalogスキーム、およびpg_stat表現の実装に加えて、 pg_stat_statementsおよびpg_buffercache表現の形式でいくつかの公式の拡張機能があります。 pg_active_session_history 、 pg_store_plans 、 pg_stat_kcacheなどの追加のサードパーティビューと同様。

ほとんどすべてのノードは、その構造や状態を表示するシステムテーブルに対応しています。 つまり、データベース自体は、クエリ言語を通じてその内部構造と状態について知ることができます。 さらに、多くのDBMSは、クエリ言語を使用して有用なメタデータを取得するだけでなく、何らかの操作を停止する、開始する、クリアする、統計を収集するなどの公式操作を実行する機会を提供します。テーブルまたは列だけでなく、たとえばセッション（ " alter session set sql_trace = true "）、データファイル（ " alter tablespace add datafile "）、またはシステム全体（ " alter system kill session "）などの他のオブジェクトにも。

これらのテーブルとクエリの知識は、開発と管理の両方、および次の新しいDBMSの開発に役立ちます。 一部のデータベースではそのような機能が高度に開発されており、ほとんどすべてが「コード」で実行できることは明らかですが、他のデータベースでははるかに控えめですが、DBMS開発者が製品でそのような機能を開発する傾向があることは間違いありません。それらを効率的に操作します。

結論と履歴書の代わりに

残念ながら、SQLは長い間、「低レベル」言語、つまりデータベースの一種の「バイトコード」として多くの人にしっかりと認識されてきました。 これは受け入れられません。また、一部の社会では、「手で書く」ことや、一般的に何らかの方法で彼に連絡することは、非常に卑劣です。 多数のDBツールとフレームワーク自体がシステムに対して「 トリッキーで複雑な 」SQLクエリを生成および実行し、このプロセスしか観察できないという事実に長い間慣れてきました。 しかし、ウォームチューブグラフィカルインターフェイスとコードジェネレーターの快適ゾーンを離れ、通常のコードの観点からDBMSを見てみましょう。 さらに、これに必要なものはすべて揃っています。

ケースに移ります。 DBMSのユーザーは、多くの言語に馴染みのあるシンプルで理解しやすいコードの形で、データベースを操作するほぼすべての側面を説明する機会があります。 これはANSI SQLではなく、使用するデータベースに応じて、SQLに似た方言、または独自の組み込みQLまたはAPIである場合があります。 これはどのように役立ちますか？

• ツールに縛られることなく、データベースに関する情報を適切な形式で取得したり、データベースに対して操作を実行したりできます。
• なぜなら まだ通常のコードであるため、他の「実際の」コードと同様に扱う必要があります。 つまり、承認された標準に従って理解、構造化、およびフォーマットされ、標準コードライフサイクルのすべての段階に参加する必要があります。VCSの管理下にあり、コードレビューを受け、CI / CDパイプラインに参加します。 「SQLトリック」と呼ばれるフォルダ内のどこかにうろついています。 それにより、チームの品質と価値が向上します。

このテーマに関するあなたの意見は興味深いです、コメントに書いてください-私たちは議論します。

次の投稿では、上記のアイデアを具体的な例で説明するとともに、CROCでそれらを研究プロジェクトの一部として開発されている実験的なオープンソースのグラフィカルDBマネージャーにどのように適用するかについても話します。