このデータベースは燃えています...

技術的な話をしましょう。

何年も前、私はコラボレーション機能が組み込まれたアプリケーションを開発していました。 これは、初期の React と CouchDB の可能性を最大限に活用した、ユーザーフレンドリーな実験用スタックでした。 JSON経由でリアルタイムにデータを同期しました OT。 これは社内で使用されていましたが、他の分野でも幅広い適用可能性と可能性があることは明らかでした。

このテクノロジーを潜在的な顧客に販売しようとしているときに、予期せぬ障害に遭遇しました。 デモビデオでは、当社のテクノロジーは見た目も機能も素晴らしく、問題はありませんでした。 ビデオはそれがどのように機能するかを正確に示しており、何も模倣していませんでした。 私たちは、プログラムを使用するための現実的なシナリオを考え出し、コーディングしました。


実際、これが問題になりました。 私たちのデモは、他の人がアプリケーションをシミュレートしたのとまったく同じように機能しました。 具体的には、たとえそれが大きなメディア ファイルであっても、情報は A から B に即座に転送されました。 ログイン後、各ユーザーには新しいエントリが表示されます。 このアプリケーションを使用すると、村のどこかでインターネット接続が中断された場合でも、異なるユーザーが同じプロジェクトで明確に共同作業することができます。 これは、After Effects でカットされた製品ビデオに暗黙的に含まれています。

「更新」ボタンの目的は誰もが知っていましたが、構築を依頼された Web アプリケーションには通常、独自の制限があることを実際に理解している人は誰もいませんでした。 そして、それらが不要になった場合、ユーザーエクスペリエンスはまったく異なるものになるでしょう。 彼らは主に、話している相手にメモを残して「チャット」できることに気づき、これがたとえば Slack とどう違うのか疑問に思いました。 ふう！

日常の同期のデザイン

ソフトウェア開発の経験がある場合、ほとんどの人はインターフェースの画像を見ただけで、それを操作するときに何が行われるかを理解することはできないことを思い出すと、緊張するはずです。 プログラム自体の内部で何が起こるかは言うまでもありません。 という知識 缶 起こるということは主に、何が起こり得ないのか、何が起こってはいけないのかを知った結果です。 これには必要です メンタルモデル ソフトウェアが何を行うかだけでなく、その個々の部分がどのように調整され、相互に通信するかについても説明します。

この典型的な例は、ユーザーが何かを見つめていることです。 spinner.gif、ついに作品が完成するのはいつになるのだろうか。 開発者は、おそらくプロセスが停止しており、GIF が画面から消えることはないことに気づいていたでしょう。 このアニメーションはジョブの実行をシミュレートしますが、ジョブの状態とは関係ありません。 このような場合、技術者の中にはユーザーの混乱の程度に驚いて目を丸くする人もいます。 しかし、回転している時計を指して、実際には止まっていると言う人がどれだけいるかに注目してください。

これがリアルタイム価値の本質です。 最近では、リアルタイム データベースはまだほとんど使用されておらず、多くの人が疑念を抱いています。 これらのデータベースのほとんどは NoSQL スタイルに大きく傾いているため、通常は Mongo ベースのソリューションが使用されますが、これは忘れるのが最善です。 しかし、私にとってこれは、CouchDB の操作に慣れることと、一部の官僚以上にデータを入力できる構造の設計を学ぶことを意味します。 時間をより有効に使えるようになったと思います。

しかし、この記事の本当のテーマは、私が今日使用しているものです。 それは選択によるものではなく、企業ポリシーが無関心かつ盲目的に適用されたためです。 そこで、密接に関連する XNUMX つの Google リアルタイム データベース製品を完全に公平かつ公平に比較​​してみます。

どちらも名前に「火」という言葉が入っています。 懐かしく思い出されることが一つあります。 私にとっての XNUMX 番目のことは、異なる種類の火です。 私は彼らの名前を言うのを急いでいません。なぜなら、名前を言うと、最初の大きな問題、つまり名前に遭遇することになるからです。

最初のものはと呼ばれます Firebase リアルタイム データベース、およびXNUMX番目- Firebase クラウド Firestore。 どちらもこちらの商品です Firebase スイート グーグル。 それらの API はそれぞれ呼び出されます firebase.database(…) и firebase.firestore(…).

このようなことが起こったのは、 リアルタイムデータベース - それはただのオリジナルです ファイアベース 2014年にGoogleに買収される前。 その後、Google は並行製品として作成することを決定しました。 コピー Firebase はビッグデータ企業をベースにしており、クラウドを備えた Firestore と呼ばれています。 まだ混乱していないことを願っています。 まだ混乱している場合でも、心配しないでください。私自身、記事のこの部分を XNUMX 回書き直しました。

示す必要があるため、 ファイアベース Firebaseの質問で、そして ファイヤーストア Firebase に関する質問で、少なくとも数年前の Stack Overflow について理解してもらうために。

最悪のソフトウェア命名エクスペリエンスに賞が与えられるとしたら、これは間違いなく候補の XNUMX つになるでしょう。 これらの名前間のハミング距離は非常に小さいため、頭で別の名前を考えている間に XNUMX つの名前を指で入力する経験豊富なエンジニアでさえ混乱します。 これらは善意に基づいた計画ですが、惨めに失敗します。 彼らは、データベースが炎上するという予言を成就しました。 全然冗談じゃないよ。 この命名案を考え出した人は、血と汗と涙を流しました。

ピューリクスの勝利

Firestore は 交換 Firebase はその次世代の子孫ですが、それは誤解を招きます。 Firestore が Firebase の適切な代替となるとは保証されていません。 誰かがそこから興味深いものをすべて切り取り、残りのほとんどをさまざまな方法で混乱させたようです。

ただし、この XNUMX つの製品をざっと見ただけでは混乱するかもしれません。基本的に同じ API を介して、さらには同じデータベース セッション内で、同じことを実行しているように見えます。 違いは微妙であり、広範な文書を注意深く比較検討することによってのみ明らかになります。 または、Firebase で完全に動作するコードを Firestore で動作するように移植しようとしている場合。 それでも、リアルタイムでマウスをドラッグ アンド ドロップしようとするとすぐにデータベース インターフェイスが点灯することがわかります。 繰り返しますが、冗談ではありません。

Firebase クライアントは、変更をバッファリングし、最後の書き込み操作を優先する更新を自動的に再試行するという意味で丁寧です。 ただし、Firestore には、ユーザーごとにドキュメントごとに 1 秒あたり XNUMX 回の書き込み操作という制限があり、この制限はサーバーによって強制されます。 これを使用する場合、アプリケーションを構築しようとしているだけの場合でも、それを回避する方法を見つけて更新レート リミッターを実装するのはユーザーの責任です。 つまり、Firestore は、API を使用するリアルタイム クライアントを装ったリアルタイム データベースです。

ここで、Firestore の存在意義の最初の兆候が見え始めます。 私が間違っているかもしれませんが、Google の経営陣の上層部の誰かが購入後に Firebase を見て、単に「いや、なんてことだ、違う」と言ったのではないかと思います。 これは受け入れがたい。 私のリーダーシップの下ではないだけです。」

彼は部屋から現れてこう宣言した。

「1 つの大きな JSON ドキュメントですか? いいえ。 データを個別のドキュメントに分割し、それぞれのサイズが XNUMX メガバイト以下になるようにします。」

このような制限は、十分に動機付けられたユーザー ベースに最初に遭遇した後は生き残れないと思われます。 そうですよね。 たとえば、職場では XNUMX 件を超えるプレゼンテーションが行われますが、これはまったく正常なことです。

この制限により、データベース内の XNUMX つの「ドキュメント」は、ユーザーがドキュメントと呼ぶオブジェクトには似ていないという事実を受け入れる必要があります。

「他の要素を再帰的に含めることができる配列の配列? いいえ。 神が意図したとおり、配列には固定長のオブジェクトまたは数値のみが含まれます。」

したがって、GeoJSON を Firestore に入れたいと思っていたとしても、それは不可能であることがわかります。 一次元以外のものは受け入れられません。 Base64 や JSON 内の JSON を気に入っていただければ幸いです。

「HTTP、コマンドラインツール、または管理パネル経由で JSON をインポートおよびエクスポートしますか? いいえ。 Google Cloud Storage へのデータのエクスポートとインポートのみが可能になります。 今ではそう呼ばれていると思います。 私が「あなた」と言うときは、プロジェクト オーナーの資格を持つ人のみを指します。 他の人は誰でもチケットを作成できます。」

ご覧のとおり、FireBase データ モデルは簡単に説明できます。 これには、JSON キーを URL パスに関連付ける XNUMX つの巨大な JSON ドキュメントが含まれています。 と書くと HTTP PUT в / FireBase は次のとおりです。

{
  "hello": "world"
}

その GET /hello 戻ります "world"。 基本的には期待どおりに機能します。 FireBase オブジェクトのコレクション /my-collection/:id JSON辞書に相当 {"my-collection": {...}} ルートにあり、その内容は次の場所で入手できます。 /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

これは、各挿入に衝突のない ID がある場合に正常に機能します。システムにはそのための標準ソリューションがあります。

言い換えれば、データベースは 100% JSON(*) 互換性があり、CouchDB などの HTTP とうまく連携します。 ただし、基本的には、WebSocket、承認、およびサブスクリプションを抽象化するリアルタイム API を通じて使用します。 管理パネルには両方の機能があり、リアルタイム編集と JSON インポート/エクスポートの両方が可能です。 コードで同じことを行うと、patch と diff JSON が永続的な状態を処理する日常的なタスクの 90% を解決することに気づくと、どれほど多くの特殊なコードが無駄になるかに驚くでしょう。

Firestore データ モデルは JSON に似ていますが、いくつかの重要な点で異なります。 配列内に配列が存在しないことについてはすでに述べました。 サブコレクションのモデルは、それらを含む JSON ドキュメントから独立した、第一級の概念となることです。 これには既製のシリアル化がないため、データの取得と書き込みには特殊なコード パスが必要です。 独自のコレクションを処理するには、独自のスクリプトとツールを作成する必要があります。 管理パネルでは一度に XNUMX フィールドずつ小さな変更のみが可能で、インポート/エクスポート機能はありません。

彼らはリアルタイム NoSQL データベースを利用し、自動結合と独立した非 JSON 列を備えた低速な非 SQL に変えました。 GraftQLのようなもの.

ホットジャワ

Firestore がより信頼性とスケーラビリティを備えているはずだった場合、皮肉なことに、平均的な開発者は、そのまま FireBase を選択するよりも信頼性の低いソリューションを使用することになります。 気難しいデータベース管理者が必要とする種類のソフトウェアには、その製品が得意とするニッチ分野では非現実的なレベルの努力と才能が必要です。 これは、開発ツールやプレーヤーがない場合、HTML5 Canvas が Flash の代わりにならないのと同じです。 さらに、Firestore はデータの純度や不毛な検証を求める欲求に囚われており、平均的なビジネス ユーザーのやり方とはまったく一致しません。 仕事が大好き：彼にとって、すべてはオプションです。なぜなら、最後まですべてがドラフトだからです。

FireBase の主な欠点は、クライアントが時代の数年前、ほとんどの Web 開発者が不変性について知る前に作成されたことです。 このため、FireBase はユーザーがデータを変更することを前提としており、ユーザーが提供する不変性を利用しません。 さらに、ユーザーに渡すスナップショット内のデータは再利用されないため、diff はさらに困難になります。 大きなドキュメントの場合、変更可能な diff ベースのトランザクション メカニズムはまったく不十分です。 皆さん、私たちはすでに持っています WeakMap JavaScriptで。 快適ですよ。

データに必要な形状を与え、ツリーのボリュームを大きくしすぎない場合、この問題は回避できます。 しかし、開発者が不変性を使用し、データベース設計に関する本格的な実践的なアドバイスを組み合わせた非常に優れたクライアント API をリリースした場合、FireBase はさらに興味深いものになるだろうかと私は興味があります。 むしろ、壊れていないものを直そうとしたようで、それが事態をさらに悪化させました。

Firestore の作成の背後にあるロジックをすべて知っているわけではありません。 ブラックボックスの中で生まれる動機を推測するのも楽しみのひとつだ。 非常に似ているが比較できない XNUMX つのデータベースがこのように並置されることは非常にまれです。 誰かがこう思ったようです。 「Firebase は Google Cloud でエミュレートできる機能にすぎません」しかし、現実世界の要件を特定したり、それらの要件をすべて満たす有用なソリューションを作成したりするという概念はまだ発見していません。 「開発者に考えてもらいましょう。 UIだけ綺麗にして…もっと火をつけてくれませんか？」

データ構造についていくつかのことを理解しました。 私は、「すべてを XNUMX つの大きな JSON ツリーに」という概念を、データベースから大規模な構造の感覚を抽象化する試みであると確信しています。 ソフトウェアが疑わしいデータ構造のフラクタルに簡単に対処できることを期待するのは、まったく狂気の沙汰です。 事態がどれほど悪いことになるかを想像する必要さえありません。私は厳格なコード監査を行っています。 あなたたちが夢にも思わなかったことを私は見ました。 でも、良い構造がどのようなものかも知っているし、 それらの使い方 и なぜこれを行う必要があるのか。 Firestore が論理的で、それを作成した人々が良い仕事をしたと思うような世界が想像できます。 しかし、私たちはこの世界に生きているわけではありません。

FireBase のクエリ サポートはどの標準から見ても貧弱で、事実上存在しません。 間違いなく改善、あるいは少なくとも修正が必要です。 ただし、Firestore は、単純な SQL と同じ XNUMX 次元インデックスに限定されているため、それほど優れているわけではありません。 無秩序なデータに対して人々が実行するクエリが必要な場合は、全文検索、複数範囲のフィルター、およびカスタムのユーザー定義の順序付けが必要です。 詳しく調べてみると、単純な SQL の機能はそれ自体ではあまりにも制限されています。 さらに、実稼働環境で実行できる SQL クエリは高速クエリのみです。 スマートなデータ構造を備えたカスタム インデックス作成ソリューションが必要です。 他のすべてについては、少なくとも増分マップリデュースまたは同様のものがあるべきです。

これに関する情報を Google ドキュメントで検索すると、BigTable や BigQuery などの方向性が示されると思います。 ただし、これらのソリューションにはすべて、企業向けのセールス専門用語が非常に多く含まれているため、すぐに引き返して別のものを探し始めるでしょう。

リアルタイム データベースで最も望ましくないのは、管理職の給料を支払っている人によって、管理職のために作られたデータベースです。

(*) これは冗談です、そんなことはありません。 100% JSON 互換.

広告の権利について

探している VDS プロジェクトのデバッグ用、開発およびホスティング用のサーバー? あなたは間違いなく当社のクライアントです 🙂 さまざまな構成のサーバー、DDoS 対策ライセンス、および Windows ライセンスの日次価格は、すでに価格に含まれています。

出所： habr.com