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

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



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



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





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



[更新]ボタンの目的は誰もが知っていましたが、作成を依頼したWebアプリケーションには通常、独自の制限があることを誰も理解していませんでした。そして、それらが不要になった場合、ユーザーエクスペリエンスは完全に異なります。基本的に、彼らはあなたが対話者にメモを残すことによって「チャット」できることに気づいたので、彼らはそれが例えばスラックとどう違うのか疑問に思いました。Uf-f-f！

日常の同期設計

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



この典型的な例は、spinner.gifを20分間見ているユーザーです。仕事が最終的にいつ終わるのか疑問に思います。開発者は、プロセスがおそらくフリーズし、gifが画面から消えることは決してないことを理解するでしょう。このアニメーションは作業の実行をシミュレートしますが、その状態には関連付けられていません。このような場合、一部の技術者は、ユーザーの混乱の程度に驚いて目を転がすのが好きです。しかし、それらのどれが回転時計を指していて、実際には静止していると言っているかに注意してください。





これがリアルタイムの価値の本質です。リアルタイムデータベースは、最近でもほとんど使用されておらず、多くの人がそれらを疑っています。これらのデータベースのほとんどは、積極的にNoSQLスタイルに傾いています。そのため、通常、より優れたMongoベースのソリューションを使用しています。しかし、私にとっては、CouchDBでの作業の快適さ、および一部の官僚だけでなくデータで埋めることができる構造の設計の研究を意味します。私は自分の時間をよりよく過ごしていると思います。



しかし、この投稿の本当のトピックは、私が今日使用しているものです。選択によるのではなく、無関心かつ盲目的に適用された企業ポリシーのためです。したがって、密接に関連する2つのGoogleリアルタイムデータベース製品の完全に正直で偏りのない比較を示します。





どちらも名前にFireという単語が含まれています。私が愛情を込めて覚えていることの1つ。私にとっての2番目は別の種類の火です。名前を言うのは急いでいません。そうするとすぐに、最初の大きな問題である名前に直面するからです。



1つ目はFirebaseReal -Time Databaseと呼ばれ、2つ目はFirebase CloudFirestoreです。どちらもGoogleのFirebaseスイートの製品です。それらのAPIには、それぞれ、、firebase.database(…)およびという名前が付けられていますfirebase.firestore(…)。



これは、リアルタイムデータベースが2014年にGoogleが購入する前の元のFirebaseにすぎないためです。その後、Googleはのコピーを作成することにしました同社のビッグデータに基づくFirebaseは、クラウドを備えたFirestoreと呼ばれています。まだ混乱していないことを願っています。混乱しても心配しないでください。私自身、記事のこの部分を10回書き直しました。FirebaseはFirebaseの質問で引用



する必要があり、FirestoreはFirebaseの質問で引用する必要があるため、少なくとも数年前のStackOverflowで理解する必要があります。



ソフトウェア製品の最悪の命名に対して賞があった場合、このケースは間違いなく候補の1つになります。これらの名前の間のハミング距離は非常に小さいため、頭が別の名前を考えているにもかかわらず、指が1つの名前を入力している経験豊富なエンジニアでさえ混乱します。これらは惨めに失敗した計画であり、最善の意図を持って発明されました。彼らは、データベースが燃えるという予言を果たしました。そして、私は冗談ではありません。この命名スキームを思いついた男は、血、汗、涙を引き起こしました。

幽霊の勝利

Firestoreは、次世代の子孫であるFirebaseの代わりになると思われるかもしれませんが、それは誤解です。FirestoreはFirebaseの代わりにはならないことが保証されています。誰かがそれから面白いものをすべて切り取って、残りのほとんどをさまざまな方法で混乱させたようです。



ただし、2つの製品をざっと見てみると、混乱する可能性があります。ほとんど同じAPIを介して、同じデータベースセッションでも、同じことをしているように見えます。違いは微妙であり、広範なドキュメントを注意深く比較して初めて明らかになります。または、Firestoreと完全に連携するコードをFirebaseに移植してFirestoreと連携させようとする場合。それでも、リアルタイムのドラッグアンドドロップを実行しようとするとすぐにデータベースインターフェイスが点灯することがわかります。繰り返しますが、私は冗談ではありません。



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



これにより、Firestoreの存在の意味の最初の兆候が見え始めます。私は間違っているかもしれませんが、グーグルのリーダーシップの上位にいる誰かがFirebaseで購入した後、「いや、いや、いや。これは受け入れがたい。私のリーダーシップの下だけではありません。」





彼は自分の部屋から出てきて、



「1つの大きなJSONドキュメント？番号。データを個別のドキュメントに分割します。各ドキュメントのサイズは1メガバイト以下になります。」



そのような制限は、合理的に動機付けられたユーザーベースとの最初の出会いを乗り切ることはできないようです。あなたはそれがそうであることを知っています。たとえば、職場では1,500を超えるプレゼンテーションがありますが、これは完全に正常です。



この制限により、データベース内の1つの「ドキュメント」は、ユーザーがドキュメントと呼ぶオブジェクトのようにはならないという事実に同意する必要があります。



「他の要素を再帰的に含むことができる配列の配列？番号。配列には、主が意図した固定長のオブジェクトまたは数値のみが含まれます。」



したがって、GeoJSONをFirestoreに配置することを望んでいた場合、これは不可能であることがわかります。不均一なものは許可されません。 JSON内のBase64および/またはJSONを気に入っていただければ幸いです。



「JSONはHTTP、コマンドラインツール、または管理パネルを介してインポートおよびエクスポートしますか？番号。 Google CloudStorageにのみデータをエクスポートおよびインポートできます。だから今呼ばれているようです。そして、私が「あなた」と言うとき、私はプロジェクトオーナーの力を持っている人だけを指します。他の誰もが行ってチケットを作成できます。」



ご覧のとおり、FireBaseデータモデルは簡単に説明できます。これには、JSONキーをURLパスにリンクする1つの巨大なJSONドキュメントが含まれています。FireBaseで次のようHTTP PUTに/記述した場合：

{
  "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でうまく機能します。ただし、ほとんどの場合、Webソケット、認証、およびサブスクリプションを抽象化するリアルタイムAPIを介して使用します。管理パネルには両方の機能があり、リアルタイム編集とJSONインポート/エクスポートの両方が可能です。コード内で同じコードを使用している場合、パッチと差分JSONがルーチンの永続状態タスクの90％を解決することに気付くと、カスタムコードがどれだけ無駄になっているのかに驚かれることでしょう。



FirestoreデータモデルはJSONに似ていますが、いくつかの重要な点で異なります。アレイ内にアレイがないことについてはすでに説明しました。サブコレクションモデルは、含まれているJSONドキュメントとは別のファーストクラスの概念になります。これにはすぐに使用できるシリアル化がないため、データの取得と書き込みには専用のコードパスが必要です。独自のコレクションを処理するには、スクリプトとツールを作成する必要があります。管理パネルでは、一度に1つのフィールドにのみ小さな変更を加えることができ、インポート/エクスポート機能はありません。



彼らはリアルタイムのNoSQLデータベースを取得し、それを自動結合と個別の非JSON列を備えた低速の非SQLに変換しました。GraftQLの精神に基づく何か。

ホットジャバ

Firestoreの信頼性と拡張性が向上した場合、皮肉なことに、平均的な開発者は、FireBaseをそのまま選択するよりも信頼性の低いソリューションを入手できます。気難しいデータベース管理者が必要とするソフトウェアは、そのようなレベルの努力と専門家の能力を必要とするため、製品が優れていると思われるニッチにとっては非現実的です。これは、開発ツールとプレーヤーがない場合、HTML5CanvasがFlashの代わりにならない方法と似ています。さらに、Firestoreは、データのクリーン性と無菌検証の追求に行き詰まっています。これは、平均的なビジネスユーザーが好む作業方法とはまったく一致していません。彼にとって、すべてが最後までドラフトであるため、すべてがオプションです。



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



必要に応じてデータを整形し、ツリーを大きくしすぎないようにすることで、この問題を回避できます。しかし、開発者が不変性とデータベース設計に関する確かで実用的なアドバイスを組み合わせた非常に優れたクライアントAPIを発表した場合、FireBaseがはるかに興味深いものになるかどうか興味があります。代わりに、彼らは壊れていないものを修正しようとしたようであり、それはそれを悪化させました。



Firestoreの作成の背後にあるすべてのロジックを知りません。ブラックボックス内で発生する動機についての推論も楽しみの一部です。 2つの非常に類似しているが、比較できないデータベースのこの並置は非常にまれです。誰かが考えているかのように、「FirebaseはGoogleCloudでエミュレートできる機能にすぎません」。しかし、実際の要件を定義したり、これらの要件をすべて満たす有用なソリューションを作成したりするという概念はまだ発見されていません。「開発者にそれについて考えさせてください。 UIをきれいにするだけです...もっと火を追加できますか？」



データ構造についていくつか理解しています。 「1つの大きなJSONツリーのすべて」の概念は、データベースから大規模な構造の感覚を抽象化する試みであることがはっきりとわかります。ソフトウェアが疑わしいデータ構造を単純に処理することを期待するのはおかしいです。私はすべてがどれほど悪いか想像する必要さえありません、私は厳密なコード監査を行い、あなたの人々が夢にも思わなかった何かを見ました。しかし、私はまた、良い構造がどのように見えるか、それらをどのように使用するか、そしてなぜそれがなされるべきなのか。 Firestoreが論理的に見え、Firestoreを作成した人々が自分たちが良い仕事をしたと思った世界を想像することができます。しかし、私たちはこの世界に住んでいません。



FireBaseでクエリを作成するためのサポートは、どの標準でも不十分であり、実際には存在しません。それは間違いなく改善または少なくとも修正が必要です。ただし、Firestoreは、プレーンSQLにあるのと同じ1次元インデックスに制限されているため、それほど優れていません。混沌としたデータを使用してユーザーが実行するクエリが必要な場合は、全文検索、複数の範囲でのフィルター、および任意のユーザー定義の順序が必要です。よく調べてみると、プレーンSQLの機能はそれ自体では制限されすぎています。また、人間が本番環境で実行できるSQLクエリは高速クエリだけです。高度なデータ構造を備えた特殊なインデックス作成ソリューションが必要になります。他のすべてについては、少なくともインクリメンタルmap-reduceまたは同様のものが必要です。



これに関する情報についてGoogleのドキュメントを見ると、BigTableやBigQueryのような方向に向けられていることが期待されます。ただし、これらの決定にはすべて、大量の企業向け販売の専門用語が伴うため、すぐに戻って別の何かを探し始めることになります。



リアルタイムデータベースの場合に最後に必要なのは、人間が作成したものであり、リーダーシップのために給与スケールで作業している人々のためのものです。



（*）これは冗談です。100％のJSON互換性などはありません。

---

広告

プロジェクトをデバッグする ためのVDS、開発と展開のためのサーバーをお探しですか？あなたは間違いなく私たちのクライアントです:)さまざまな構成のサーバーの毎日の請求、アンチDDoSおよびWindowsライセンスはすでに料金に含まれています。