Cette base de données est en feu...

Permettez-moi de raconter une histoire technique.

Il y a de nombreuses années, je développais une application intégrant des fonctionnalités de collaboration. Il s'agissait d'une pile expérimentale conviviale qui tirait parti de tout le potentiel des premiers React et CouchDB. Il a synchronisé les données en temps réel via JSON OT. Il a été utilisé en interne au sein de l’entreprise, mais sa large applicabilité et son potentiel dans d’autres domaines étaient clairs.

En essayant de vendre cette technologie à des clients potentiels, nous avons rencontré un obstacle inattendu. Dans la vidéo de démonstration, notre technologie semblait et fonctionnait à merveille, aucun problème. La vidéo montre exactement comment cela fonctionne et n’imite rien. Nous avons imaginé et codé un scénario réaliste d'utilisation du programme.


En fait, c’est devenu le problème. Notre démo a fonctionné exactement de la même manière que tout le monde a simulé ses applications. Plus précisément, les informations étaient instantanément transférées d’un point A à un point B, même s’il s’agissait de fichiers multimédias volumineux. Après s'être connecté, chaque utilisateur a vu de nouvelles entrées. Grâce à l'application, différents utilisateurs pouvaient clairement travailler ensemble sur les mêmes projets, même si la connexion Internet était interrompue quelque part dans le village. Ceci est implicitement implicite dans toute vidéo de produit coupée dans After Effects.

Même si tout le monde savait à quoi servait le bouton Actualiser, personne ne comprenait vraiment que les applications web qu’ils nous demandaient de créer étaient généralement soumises à leurs propres limites. Et que s’ils ne sont plus nécessaires, l’expérience utilisateur sera complètement différente. Ils ont surtout remarqué qu’ils pouvaient « discuter » en laissant des notes aux personnes à qui ils parlaient, ils se sont donc demandé en quoi cela était différent de, par exemple, Slack. Phew!

Conception de synchronisations quotidiennes

Si vous avez de l'expérience dans le développement de logiciels, il doit être angoissant de se rappeler que la plupart des gens ne peuvent pas simplement regarder une image d'une interface et comprendre ce qu'elle fera lorsqu'ils interagiront avec elle. Sans parler de ce qui se passe à l’intérieur du programme lui-même. La connaissance que может se produire est en grande partie le résultat de la connaissance de ce qui ne peut pas arriver et de ce qui ne devrait pas arriver. Cela nécessite modèle mental non seulement ce que fait le logiciel, mais aussi comment ses différentes parties sont coordonnées et communiquent entre elles.

Un exemple classique de ceci est celui d'un utilisateur qui regarde un spinner.gif, se demandant quand les travaux seront enfin terminés. Le développeur aurait réalisé que le processus était probablement bloqué et que le gif ne disparaîtrait jamais de l'écran. Cette animation simule l'exécution d'un job, mais n'est pas liée à son état. Dans de tels cas, certains techniciens aiment rouler des yeux, étonnés de l’ampleur de la confusion des utilisateurs. Cependant, remarquez combien d’entre eux désignent l’horloge en rotation et disent qu’elle est en réalité stationnaire ?

C’est l’essence même de la valeur en temps réel. De nos jours, les bases de données en temps réel sont encore très peu utilisées et de nombreuses personnes les considèrent avec méfiance. La plupart de ces bases de données s'appuient fortement sur le style NoSQL, c'est pourquoi elles utilisent généralement des solutions basées sur Mongo, qu'il vaut mieux oublier. Cependant, pour moi, cela signifie être à l'aise avec CouchDB, ainsi qu'apprendre à concevoir des structures que plus qu'un simple bureaucrate peut remplir de données. Je pense que j'utilise mieux mon temps.

Mais le véritable sujet de cet article est celui que j'utilise aujourd'hui. Non pas par choix, mais à cause de politiques d’entreprise appliquées avec indifférence et aveuglément. Je vais donc proposer une comparaison totalement équitable et impartiale de deux produits de base de données en temps réel Google étroitement liés.

Tous deux portent le mot Feu dans leur nom. Une chose dont je me souviens avec tendresse. La deuxième chose pour moi est un type de feu différent. Je ne suis pas pressé de prononcer leurs noms, car une fois que je le ferai, nous nous heurterons au premier gros problème : les noms.

Le premier s'appelle Base de données en temps réel Firebaseet le second Firebase Cloud Firestore. Tous deux sont des produits de Suite Firebase Google. Leurs API s'appellent respectivement firebase.database(…) и firebase.firestore(…).

Cela s'est produit parce que Base de données en temps réel - c'est juste l'original Firebase avant son rachat par Google en 2014. Ensuite, Google a décidé de créer un produit parallèle une copie Firebase est basé sur une société de big data et l'appelle Firestore avec un cloud. J'espère que vous n'êtes pas encore confus. Si vous êtes toujours confus, ne vous inquiétez pas, j’ai moi-même réécrit dix fois cette partie de l’article.

Parce qu'il faut indiquer Firebase dans la question Firebase, et foyer dans une question sur Firebase, au moins pour vous faire comprendre il y a quelques années sur Stack Overflow.

S'il y avait un prix pour la pire expérience de dénomination logicielle, celui-ci serait certainement l'un des prétendants. La distance de Hamming entre ces noms est si petite qu'elle confond même les ingénieurs expérimentés, dont les doigts tapent un nom, alors que leur tête pense à un autre. Ce sont des projets bien intentionnés qui échouent lamentablement ; ils ont réalisé la prophétie selon laquelle la base de données prendrait feu. Et je ne plaisante pas du tout. La personne qui a proposé ce nom a fait couler du sang, de la sueur et des larmes.

Victoire à la Pyrrhus

On pourrait penser que Firestore est remplacement Firebase, son descendant de nouvelle génération, mais ce serait trompeur. Il n'est pas garanti que Firestore soit un remplacement approprié pour Firebase. On dirait que quelqu'un en a coupé tout ce qui était intéressant et a confondu la plupart du reste de diverses manières.

Cependant, un rapide coup d'œil sur les deux produits peut vous dérouter : ils semblent faire la même chose, via fondamentalement les mêmes API et même dans la même session de base de données. Les différences sont subtiles et ne sont révélées que par une étude comparative minutieuse d’une documentation abondante. Ou lorsque vous essayez de porter du code qui fonctionne parfaitement sur Firebase afin qu'il fonctionne avec Firestore. Même alors, vous découvrez que l'interface de la base de données s'allume dès que vous essayez de glisser-déposer avec la souris en temps réel. Je le répète, je ne plaisante pas.

Le client Firebase est poli dans le sens où il met en mémoire tampon les modifications et réessaye automatiquement les mises à jour qui donnent la priorité à la dernière opération d'écriture. Cependant, Firestore a une limite de 1 opération d'écriture par document, par utilisateur et par seconde, et cette limite est appliquée par le serveur. Lorsque vous travaillez avec, c'est à vous de trouver un moyen de le contourner et d'implémenter un limiteur de taux de mise à jour, même lorsque vous essayez simplement de créer votre application. Autrement dit, Firestore est une base de données en temps réel sans client en temps réel, qui se fait passer pour une base de données utilisant une API.

Ici, nous commençons à voir les premiers signes de la raison d'être de Firestore. Je me trompe peut-être, mais je soupçonne qu'un haut responsable de Google a regardé Firebase après l'achat et a simplement dit : « Non, oh mon Dieu, non. C'est inacceptable. Mais pas sous ma direction. »

Il sortit de ses appartements et déclara :

« Un gros document JSON ? Non. Vous diviserez les données en documents distincts, dont chacun ne dépassera pas 1 mégaoctet.

Il semble qu’une telle limitation ne survivra pas à la première rencontre avec une base d’utilisateurs suffisamment motivés. Vous le savez. Au travail, par exemple, nous avons plus d'un millier et demi de présentations, et c'est tout à fait normal.

Avec cette limitation, vous serez obligé d'accepter le fait qu'un "document" dans la base de données ne ressemblera à aucun objet qu'un utilisateur pourrait appeler un document.

"Des tableaux de tableaux pouvant contenir récursivement d'autres éléments ? Non. Les tableaux ne contiendront que des objets ou des nombres de longueur fixe, comme Dieu l'a prévu. »

Donc, si vous espériez mettre GeoJSON dans votre Firestore, vous constaterez que ce n'est pas possible. Rien de non-unidimensionnel n’est acceptable. J'espère que vous aimez Base64 et/ou JSON dans JSON.

« Importation et exportation JSON via HTTP, outils de ligne de commande ou panneau d'administration ? Non. Vous pourrez uniquement exporter et importer des données vers Google Cloud Storage. C'est comme ça qu'on l'appelle maintenant, je pense. Et quand je dis « vous », je m’adresse uniquement à ceux qui ont les qualifications de Project Owner. Tout le monde peut créer des tickets."

Comme vous pouvez le constater, le modèle de données FireBase est facile à décrire. Il contient un énorme document JSON qui associe les clés JSON aux chemins d'URL. Si vous écrivez avec HTTP PUT в / FireBase est le suivant :

{
  "hello": "world"
}

la GET /hello reviendra "world". Fondamentalement, cela fonctionne exactement comme prévu. Collection d'objets FireBase /my-collection/:id équivalent à un dictionnaire JSON {"my-collection": {...}} à la racine, dont le contenu est disponible dans /my-collection:

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

Cela fonctionne bien si chaque insert possède un identifiant sans collision, pour lequel le système dispose d'une solution standard.

En d'autres termes, la base de données est 100 % compatible JSON(*) et fonctionne très bien avec HTTP, comme CouchDB. Mais fondamentalement, vous l'utilisez via une API en temps réel qui résume les websockets, les autorisations et les abonnements. Le panneau d'administration possède les deux capacités, permettant à la fois l'édition en temps réel et l'importation/exportation JSON. Si vous faites la même chose dans votre code, vous serez surpris de la quantité de code spécialisé qui sera gaspillée lorsque vous réaliserez que patch et diff JSON résolvent 90 % des tâches de routine de gestion de l'état persistant.

Le modèle de données Firestore est similaire à JSON, mais diffère sur certains points essentiels. J'ai déjà mentionné le manque de tableaux dans les tableaux. Le modèle des sous-collections est qu'elles soient des concepts de première classe, distincts du document JSON qui les contient. Puisqu'il n'existe pas de sérialisation prête à l'emploi pour cela, un chemin de code spécialisé est requis pour récupérer et écrire les données. Pour traiter vos propres collections, vous devez écrire vos propres scripts et outils. Le panneau d'administration vous permet uniquement d'apporter de petites modifications, un champ à la fois, et ne dispose pas de fonctionnalités d'importation/exportation.

Ils ont pris une base de données NoSQL en temps réel et l'ont transformée en une base de données non-SQL lente avec jointure automatique et une colonne non-JSON distincte. Quelque chose comme GraftQL.

Java chaud

Si Firestore était censé être plus fiable et évolutif, l'ironie est que le développeur moyen se retrouvera avec une solution moins fiable que de choisir FireBase prêt à l'emploi. Le type de logiciel dont l'administrateur de base de données Grumpy a besoin nécessite un niveau d'effort et un calibre de talent tout simplement irréaliste pour le créneau dans lequel le produit est censé être bon. Ceci est similaire à la façon dont HTML5 Canvas ne remplace pas du tout Flash s'il n'y a pas d'outils de développement ni de lecteur. De plus, Firestore est embourbé dans un désir de pureté des données et de validation stérile qui ne correspond tout simplement pas à la façon dont l'utilisateur professionnel moyen aime travailler: pour lui, tout est facultatif, car jusqu'au bout tout est brouillon.

Le principal inconvénient de FireBase est que le client a été créé plusieurs années en avance, avant que la plupart des développeurs Web ne connaissent l'immuabilité. Pour cette raison, FireBase suppose que vous modifierez les données et ne profite donc pas de l'immuabilité fournie par l'utilisateur. De plus, il ne réutilise pas les données des instantanés qu'il transmet à l'utilisateur, ce qui rend la comparaison beaucoup plus difficile. Pour les documents volumineux, son mécanisme de transaction mutable basé sur les différences est tout simplement inadéquat. Les gars, nous avons déjà WeakMap en JavaScript. C'est confortable.

Si vous donnez aux données la forme souhaitée et ne rendez pas les arbres trop volumineux, ce problème peut être contourné. Mais je suis curieux de savoir si FireBase serait beaucoup plus intéressant si les développeurs publiaient une très bonne API client utilisant l'immuabilité combinée à de sérieux conseils pratiques sur la conception de bases de données. Au lieu de cela, ils semblaient essayer de réparer ce qui n'était pas cassé, et cela ne faisait qu'empirer les choses.

Je ne connais pas toute la logique derrière la création de Firestore. Spéculer sur les motifs qui surgissent à l’intérieur de la boîte noire fait également partie du plaisir. Cette juxtaposition de deux bases de données extrêmement similaires mais incomparables est assez rare. C'est comme si quelqu'un pensait : "Firebase n'est qu'une fonction que nous pouvons émuler dans Google Cloud", mais n'a pas encore découvert le concept d'identification des exigences du monde réel ou de création de solutions utiles qui répondent à toutes ces exigences. «Laissons les développeurs y réfléchir. Rendez simplement l'interface utilisateur plus belle... Pouvez-vous ajouter plus de feu ? »

Je comprends quelques choses sur les structures de données. Je considère définitivement le concept « tout dans un grand arbre JSON » comme une tentative d'abstraire tout sentiment de structure à grande échelle de la base de données. S'attendre à ce qu'un logiciel puisse simplement gérer n'importe quelle fractale de structure de données douteuse est tout simplement insensé. Je n'ai même pas besoin d'imaginer à quel point les choses pourraient être mauvaises, j'ai effectué des audits de code rigoureux et J'ai vu des choses dont vous n'aviez jamais rêvé. Mais je sais aussi à quoi ressemblent de bonnes structures, comment les utiliser и pourquoi cela devrait-il être fait. Je peux imaginer un monde dans lequel Firestore semblerait logique et où les personnes qui l'ont créé penseraient qu'elles ont fait du bon travail. Mais nous ne vivons pas dans ce monde.

La prise en charge des requêtes de FireBase est médiocre à tous égards et est pratiquement inexistante. Il a certainement besoin d'être amélioré ou au moins révisé. Mais Firestore n'est pas bien meilleur car il est limité aux mêmes index unidimensionnels que ceux trouvés dans le SQL brut. Si vous avez besoin de requêtes que les utilisateurs exécutent sur des données chaotiques, vous avez besoin d'une recherche en texte intégral, de filtres multi-plages et d'un classement personnalisé défini par l'utilisateur. En y regardant de plus près, les fonctions du simple SQL sont trop limitées en elles-mêmes. De plus, les seules requêtes SQL que les utilisateurs peuvent exécuter en production sont des requêtes rapides. Vous aurez besoin d'une solution d'indexation personnalisée avec des structures de données intelligentes. Pour tout le reste, il devrait au moins y avoir une réduction de carte incrémentielle ou quelque chose de similaire.

Si vous recherchez des informations à ce sujet dans Google Docs, vous serez, espérons-le, dirigé vers quelque chose comme BigTable et BigQuery. Cependant, toutes ces solutions sont accompagnées d’un jargon commercial si dense que vous ferez rapidement marche arrière et commencerez à chercher autre chose.

La dernière chose que vous souhaitez avec une base de données en temps réel est quelque chose créé par et pour les personnes figurant sur les échelles salariales des cadres.

(*) C'est une blague, ça n'existe pas 100% compatible JSON.

Comme la publicité

À la recherche de SDV pour les projets de débogage, un serveur pour le développement et l'hébergement ? Vous êtes définitivement notre client 🙂 La tarification journalière des serveurs de différentes configurations, les licences anti-DDoS et Windows sont déjà incluses dans le prix.

Source: habr.com