{"id":96465,"date":"2020-10-12T07:42:27","date_gmt":"2020-10-12T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne"},"modified":"2020-10-12T07:42:27","modified_gmt":"2020-10-12T05:42:27","slug":"eta-baza-dannyh-v-ogne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Cette base de donn\u00e9es est en feu\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cette
\n
\nPermettez-moi de vous raconter une histoire technique.<\/p>\n

Il y a de nombreuses ann\u00e9es, j'ai d\u00e9velopp\u00e9 une application avec des fonctionnalit\u00e9s de collaboration int\u00e9gr\u00e9es. C'\u00e9tait une pile exp\u00e9rimentale pratique, exploitant pleinement le potentiel du premier React et de CouchDB. Elle synchronisait les donn\u00e9es en temps r\u00e9el via JSON. OT<\/a><\/noindex>. Elle \u00e9tait utilis\u00e9e pour le travail interne de l'entreprise, mais son applicabilit\u00e9 et son potentiel dans d'autres domaines \u00e9taient \u00e9vidents.<\/p>\n

En essayant de vendre cette technologie \u00e0 des clients potentiels, nous avons rencontr\u00e9 un obstacle inattendu. Dans la vid\u00e9o de d\u00e9monstration, notre technologie avait l'air et fonctionnait parfaitement, il n'y avait aucun probl\u00e8me. La vid\u00e9o montrait exactement comment cela fonctionne, sans aucune simulation. Nous avons con\u00e7u et cod\u00e9 un sc\u00e9nario d'application r\u00e9aliste pour le programme.
\n<\/a><\/noindex>
\n\"Cette
\nEn r\u00e9alit\u00e9, cela a \u00e9t\u00e9 le probl\u00e8me. Notre d\u00e9mo fonctionnait exactement comme l'imitation de l'utilisation de leurs applications par tous les autres. Plus pr\u00e9cis\u00e9ment, les informations \u00e9taient transmises instantan\u00e9ment de A \u00e0 B, m\u00eame s'il s'agissait de gros fichiers multim\u00e9dias. Apr\u00e8s connexion, chaque utilisateur voyait de nouvelles entr\u00e9es. Gr\u00e2ce \u00e0 l'application, diff\u00e9rents utilisateurs pouvaient collaborer clairement sur les m\u00eames projets, m\u00eame en cas d'interruption de la connexion Internet quelque part dans un village. Cela \u00e9tait implicitement sous-entendu dans n'importe quelle vid\u00e9o d\u00e9coup\u00e9e dans After Effects sur le produit.<\/p>\n

Bien que tout le monde sache \u00e0 quoi sert le bouton de rafra\u00eechissement, personne ne comprenait vraiment que les applications Web, que l'on nous demande de cr\u00e9er, sont souvent sujettes \u00e0 leurs limitations. Et que si elles ne sont plus n\u00e9cessaires, l'exp\u00e9rience utilisateur sera totalement diff\u00e9rente. En g\u00e9n\u00e9ral, ils remarquaient qu'il \u00e9tait possible de \u00ab discuter \u00bb, en laissant des notes \u00e0 leurs interlocuteurs, se posant donc la question de la diff\u00e9rence avec, par exemple, Slack. Ouf !<\/p>\n

Le design des synchronisations quotidiennes<\/h2>\n

\nSi vous avez d\u00e9j\u00e0 de l'exp\u00e9rience dans le d\u00e9veloppement de logiciels, vous devez trouver frustrant de devoir se rappeler que la plupart des gens ne peuvent pas simplement regarder une image de l'interface et comprendre ce qu'elle fera lors de l'interaction avec elle. Sans parler de ce qui se passe \u00e0 l'int\u00e9rieur du programme lui-m\u00eame. Savoir ce qui peut<\/i> doit se produire est en grande partie le r\u00e9sultat de la connaissance de ce qui ne peut pas se produire et ce qui ne doit pas se produire. Cela n\u00e9cessite mod\u00e8le mental<\/a><\/noindex> non seulement ce que fait le logiciel, mais aussi la fa\u00e7on dont ses diff\u00e9rentes parties sont align\u00e9es et communiquent entre elles.<\/p>\n

Un exemple classique de cela est un utilisateur regardant pendant vingt minutes spinner.gif<\/i>, se demandant quand le travail prendra enfin fin. Le d\u00e9veloppeur comprendrait que le processus est probablement gel\u00e9, et que le GIF ne dispara\u00eetra jamais de l'\u00e9cran. Cette animation simule l'ex\u00e9cution d'une t\u00e2che, mais n'est pas li\u00e9e \u00e0 son \u00e9tat. Dans de tels cas, certains techniciens aiment lever les yeux au ciel, s'interrogeant sur le degr\u00e9 d'illusion des utilisateurs. Mais remarquez, qui parmi eux pointe sur l'horloge tournante et dit qu'elle est en r\u00e9alit\u00e9 immobile ?<\/p>\n

\"Cette
\nC'est l\u00e0 que r\u00e9side la valeur du temps r\u00e9el. De nos jours, les bases de donn\u00e9es en temps r\u00e9el sont encore tr\u00e8s peu utilis\u00e9es, et beaucoup s'en m\u00e9fient. La plupart de ces bases de donn\u00e9es tendent vers un style NoSQL, ce qui am\u00e8ne souvent \u00e0 utiliser des solutions bas\u00e9es sur Mongo, qu'il vaut mieux oublier. Pour moi, cela signifie le confort de travailler avec CouchDB, ainsi que l'exploration de la conception de structures capables d'\u00eatre remplies de donn\u00e9es par autre chose qu'un bureaucrate. Je pense que je g\u00e8re mon temps de mani\u00e8re plus optimale.<\/p>\n

Mais le v\u00e9ritable sujet de ce post est ce que j'utilise aujourd'hui. Non pas par choix, mais en raison d'une politique d'entreprise appliqu\u00e9e de mani\u00e8re indiff\u00e9rente et aveugle. Par cons\u00e9quent, je vais fournir une comparaison totalement honn\u00eate et impartiale de deux produits \u00e9troitement li\u00e9s pour travailler avec des bases de donn\u00e9es en temps r\u00e9el de Google.<\/p>\n

\"Cette
\nLes deux ont le mot Fire dans leur nom. L'un je me souviens avec tendresse. L'autre pour moi est un autre type de feu. Je ne me d\u00e9p\u00eache pas de dire leurs noms, car une fois que je le ferai, nous serons confront\u00e9s au premier grand probl\u00e8me : les noms.<\/p>\n

Le premier s'appelle Firebase Real-Time Database<\/i>, et le second \u2014 Firebase Cloud Firestore<\/i>. Tous deux sont des produits de la suite Firebase<\/i> de Google. Leurs API s'appellent, respectivement, firebase.database(\u2026)<\/code> et firebase.firestore(\u2026)<\/code>.<\/p>\n

Cela s'est produit parce que Real-Time Database<\/i> \u00e9tait simplement l'original Firebase<\/i> avant son acquisition par Google en 2014. Ensuite, chez Google, ils ont d\u00e9cid\u00e9 de cr\u00e9er un produit parall\u00e8le sous la forme d'une copie<\/i> de Firebase bas\u00e9 sur les big data de l'entreprise, et l'ont nomm\u00e9 Firestore with a cloud. J'esp\u00e8re que vous ne vous \u00eates pas encore perdu. Si vous \u00eates perdu, ne vous inqui\u00e9tez pas, j'ai moi-m\u00eame r\u00e9\u00e9crit cette partie de l'article dix fois.<\/p>\n

Parce qu'il faut pr\u00e9ciser Firebase<\/i> en ce qui concerne Firebase, et Firestore<\/i> en ce qui concerne Firebase, du moins pour que vous soyez compris il y a quelques ann\u00e9es sur Stack Overflow.<\/p>\n

S'il existait un prix pour le pire nommage de produits logiciels, ce cas serait certainement un des pr\u00e9tendants. La distance de Hamming entre ces noms est si faible qu'elle perturbe m\u00eame des ing\u00e9nieurs exp\u00e9riment\u00e9s dont les doigts tapent un nom alors que leur t\u00eate pense \u00e0 un autre. Ce sont des plans qui ont \u00e9chou\u00e9 avec fracas, con\u00e7us avec les meilleures intentions ; ils ont r\u00e9alis\u00e9 la proph\u00e9tie selon laquelle la base de donn\u00e9es serait en feu. Et je ne rigole pas. La personne qui a con\u00e7u un tel sch\u00e9ma de nommage a \u00e9t\u00e9 \u00e0 l'origine de sang, de sueur et de larmes.<\/p>\n

\"Cette<\/p>\n

Une victoire \u00e0 la Pyrrhus<\/h2>\n

\nOn pourrait penser que Firestore est le remplacement<\/i> de Firebase, son descendant de nouvelle g\u00e9n\u00e9ration, mais ce serait une erreur. Firestore n'est absolument pas destin\u00e9 \u00e0 remplacer Firebase. On dirait que quelqu'un a retir\u00e9 tout ce qui \u00e9tait int\u00e9ressant, et la majeure partie du reste a \u00e9t\u00e9 compliqu\u00e9e de diff\u00e9rentes mani\u00e8res.<\/p>\n

Cependant, un coup d'\u0153il rapide aux deux produits peut vous induire en erreur : ils semblent faire la m\u00eame chose, via principalement des API identiques et m\u00eame dans la m\u00eame session de base de donn\u00e9es. Les diff\u00e9rences sont peu visibles et ne se d\u00e9voilent qu'\u00e0 travers une \u00e9tude comparative minutieuse de la documentation d\u00e9taill\u00e9e. Ou lorsque vous essayez de porter un code qui fonctionne parfaitement sur Firebase pour qu'il fonctionne avec Firestore. M\u00eame alors, vous d\u00e9couvrirez que l'interface de la base de donn\u00e9es s'enflamme d\u00e8s que vous essayez de faire glisser la souris en temps r\u00e9el. Je le r\u00e9p\u00e8te, je ne rigole pas.<\/p>\n

Le client Firebase est poli dans le sens o\u00f9 il met en m\u00e9moire tampon les modifications et effectue automatiquement des tentatives de mise \u00e0 jour, en donnant la priorit\u00e9 \u00e0 la derni\u00e8re op\u00e9ration d'\u00e9criture. Cependant, Firestore a une limite de 1 op\u00e9ration d'\u00e9criture par document par utilisateur par seconde, et cette limite est impos\u00e9e par le serveur. En travaillant avec, vous devez vous-m\u00eame trouver un moyen de contourner cela et mettre en \u0153uvre une limitation de fr\u00e9quence des mises \u00e0 jour, m\u00eame lorsque vous essayez simplement de cr\u00e9er votre application. Autrement dit, Firestore est une base de donn\u00e9es en temps r\u00e9el sans client en temps r\u00e9el, qui se camoufle en tant que telle gr\u00e2ce \u00e0 l'API.<\/p>\n

C'est ici que nous commen\u00e7ons \u00e0 voir les premiers signes de la raison d'\u00eatre de Firestore. Peut-\u00eatre que je me trompe, mais je soup\u00e7onne que quelqu'un en haut de la direction de Google a regard\u00e9 Firebase apr\u00e8s son acquisition et a simplement dit : \u00ab Non, mon Dieu, non. C'est inacceptable. Pas sous ma direction \u00bb.<\/p>\n

\"Cette
\nIl est sorti de ses appartements et a proclam\u00e9 :<\/p>\n

\u00ab Un gros document JSON ? Non. Vous devez diviser les donn\u00e9es en documents s\u00e9par\u00e9s, chacun d'une taille maximale d'un m\u00e9gaoctet \u00bb.<\/i><\/p>\n

Il semble qu'une telle restriction ne survivra pas au premier affrontement avec une base d'utilisateurs suffisamment motiv\u00e9e. Vous le savez. Au travail, par exemple, nous avons plus de mille cinq cents pr\u00e9sentations, et c'est tout \u00e0 fait normal.<\/p>\n

Avec une telle restriction, vous serez contraint d'accepter le fait qu'un \u00ab document \u00bb dans la base de donn\u00e9es ne ressemblera \u00e0 aucun objet que l'utilisateur pourrait d\u00e9signer comme document.<\/p>\n

\u00ab Des tableaux de tableaux, qui peuvent r\u00e9cursivement contenir d'autres \u00e9l\u00e9ments ? Non. Les tableaux ne contiendront que des objets ou des nombres de longueur fixe, comme le veut le Seigneur \u00bb.<\/i><\/p>\n

Donc, si vous esp\u00e9riez inclure votre GeoJSON dans Firestore, vous d\u00e9couvrirez que c'est impossible. Rien de non unidimensionnel n'est autoris\u00e9. J'esp\u00e8re que vous aimez Base64 et\/ou JSON \u00e0 l'int\u00e9rieur de JSON.<\/p>\n

\u00ab Importer et exporter JSON par HTTP, outils en ligne de commande ou tableau de bord d'administration ? Non. Vous ne pourrez qu'exporter et importer des donn\u00e9es dans Google Cloud Storage. Ainsi, \u00e7a s'appelle maintenant. Et quand je dis \u00ab vous \u00bb, je m'adresse uniquement \u00e0 ceux qui ont les droits de Project Owner. Tous les autres peuvent aller cr\u00e9er des tickets. \u00bb<\/i><\/p>\n

Comme vous pouvez le voir, le mod\u00e8le de donn\u00e9es FireBase est facile \u00e0 d\u00e9crire. Il contient un \u00e9norme document JSON, liant des cl\u00e9s JSON \u00e0 des chemins d'URL. Si vous \u00e9crivez avec HTTP PUT<\/code> dans \/<\/code> FireBase le suivant :<\/p>\n

{\n  \"hello\": \"monde\"\n}<\/code><\/pre>\n
\nAlors GET \/hello<\/code> renverra \"monde\"<\/code>. En gros, cela fonctionne exactement comme vous vous y attendez. La collection d'objets FireBase \/my-collection\/:id<\/code> \u00e9quivaut \u00e0 un dictionnaire JSON {\"my-collection\": {...}}<\/code> \u00e0 la racine, dont le contenu est accessible \u00e0 \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nCela fonctionne tr\u00e8s bien si chaque insertion a un ID sans collision, pour ce \u00e0 quoi le syst\u00e8me a une solution int\u00e9gr\u00e9e.<\/p>\n
En d'autres termes, la base de donn\u00e9es est 100 % compatible avec JSON (*) et fonctionne parfaitement avec HTTP, par exemple avec CouchDB. Mais principalement, vous l'utilisez via une API en temps r\u00e9el, qui abstrait les websockets, l'autorisation et les abonnements. Le panneau d'administration offre les deux options, permettant d'\u00e9diter en temps r\u00e9el et d'importer\/exporter du JSON. Si vous suivez cela dans votre code, vous serez surpris de voir combien de code sp\u00e9cialis\u00e9 dispara\u00eetra lorsque vous comprendrez que patch et diff JSON permettent de r\u00e9soudre 90 % des t\u00e2ches r\u00e9p\u00e9titives li\u00e9es \u00e0 la gestion d'\u00e9tat persistant.<\/p>\n
Le mod\u00e8le de donn\u00e9es Firestore ressemble \u00e0 JSON, mais se diff\u00e9rencie sur certains aspects critiques. J'ai d\u00e9j\u00e0 mentionn\u00e9 l'absence de tableaux \u00e0 l'int\u00e9rieur de tableaux. Le principe des sous-collections est qu'elles sont des concepts de premier ordre, distincts du document JSON qui les contient. Comme il n'existe pas de s\u00e9rialisation pr\u00eate \u00e0 l'emploi pour cela, l'obtention et l'\u00e9criture de donn\u00e9es n\u00e9cessitent un chemin d'ex\u00e9cution de code sp\u00e9cialis\u00e9. Pour g\u00e9rer vos propres collections, vous devez \u00e9crire vos propres scripts et outils. Le panneau d'administration ne permet d'apporter que de petites modifications, champ par champ, et n'a pas de fonctionnalit\u00e9s d'import\/export.<\/p>\n
Ils ont pris une base de donn\u00e9es NoSQL en temps r\u00e9el et l'ont transform\u00e9e en une solution SQL lente avec auto-fusion et une colonne distincte non-JSON. Un peu comme GraftQL<\/i>.<\/p>\n
\"Cette<\/p>\n
Java chaud<\/h2>\n
\nSi Firestore devait devenir plus fiable et \u00e9volutif, l'ironie est que le d\u00e9veloppeur moyen obtiendra une solution moins fiable que s'il choisissait FireBase \u00ab cl\u00e9 en main \u00bb. Le logiciel dont a besoin le Administrateur de Base de Donn\u00e9es Grognon n\u00e9cessite un niveau d'efforts et un calibre de sp\u00e9cialistes qui sont simplement irr\u00e9alistes pour le march\u00e9 o\u00f9 un bon produit est cens\u00e9 \u00eatre pr\u00e9sent. C'est comme si le Canvas HTML5 n'\u00e9tait pas du tout un remplacement de Flash, s'il n'existe pas d'outils de d\u00e9veloppement et de lecteurs. De plus, Firestore est embourb\u00e9e dans la qu\u00eate de puret\u00e9 des donn\u00e9es et de validation st\u00e9rile, ce qui ne correspond tout simplement pas \u00e0 la mani\u00e8re dont un utilisateur commercial moyen aime travailler<\/i>: car pour lui, rien n'est obligatoire, car jusqu'\u00e0 la fin, tout n'est qu'un brouillon.<\/p>\n
Le principal inconv\u00e9nient de FireBase est que le client a \u00e9t\u00e9 cr\u00e9\u00e9 plusieurs ann\u00e9es avant son calendrier, bien avant que la plupart des d\u00e9veloppeurs web n'aient connaissance de l'immuabilit\u00e9. En cons\u00e9quence, FireBase suppose que vous allez modifier les donn\u00e9es et ne tire donc pas parti de l'immuabilit\u00e9 fournie par l'utilisateur. De plus, il ne r\u00e9utilise pas les donn\u00e9es dans les instantan\u00e9s transmis \u00e0 l'utilisateur, rendant ainsi l'ex\u00e9cution des diff\u00e9rences beaucoup plus difficile. Pour de gros documents, son m\u00e9canisme de transaction bas\u00e9 sur des diff\u00e9rences modifiables est simplement inad\u00e9quat. Les gars, nous avons d\u00e9j\u00e0 WeakMap<\/code> en JavaScript. C'est pratique.<\/p>\n
Si vous donnez aux donn\u00e9es la forme appropri\u00e9e et que vous ne rendez pas les arbres trop volumineux, vous pouvez contourner ce probl\u00e8me. Mais je me demande si FireBase serait beaucoup plus int\u00e9ressant si les d\u00e9veloppeurs avaient publi\u00e9 une v\u00e9ritable bonne API client exploitant l'immuabilit\u00e9, associ\u00e9e \u00e0 de solides conseils pratiques sur la structure des bases de donn\u00e9es. Au lieu de cela, ils semblent avoir essay\u00e9 de r\u00e9parer ce qui n'est pas cass\u00e9, et cela a empir\u00e9.<\/p>\n
Je ne connais pas toute la logique qui a sous-tendu la cr\u00e9ation de Firestore. R\u00e9fl\u00e9chir aux motivations se trouvant \u00e0 l'int\u00e9rieur d'une bo\u00eete noire fait aussi partie du divertissement. Une telle opposition entre deux bases de donn\u00e9es extr\u00eamement similaires, mais incomparables, est assez rare. C'est comme si quelqu'un avait pens\u00e9 : \u00abFirebase est simplement une fonction que nous pouvons \u00e9muler dans Google Cloud\u00bb<\/i>, mais sans encore avoir d\u00e9couvert le concept de d\u00e9finition des exigences du monde r\u00e9el ou de cr\u00e9ation de solutions utiles r\u00e9pondant \u00e0 toutes ces exigences. \u00abLaissez cela aux d\u00e9veloppeurs. Rendre simplement l'interface utilisateur attrayante\u2026 Peut-on ajouter un peu plus de flair ?\u00bb<\/i><\/p>\n
Je comprends quelques notions sur les structures de donn\u00e9es. Je vois clairement que le concept de \u00abtout dans un grand arbre JSON\u00bb est une tentative d'abstraire de la base de donn\u00e9es toute sensation de structure \u00e0 grande \u00e9chelle. S'attendre \u00e0 ce que le logiciel g\u00e8re simplement n'importe quel fractal douteux de structure de donn\u00e9es est tout simplement insens\u00e9. Je n'ai m\u00eame pas besoin d'imaginer \u00e0 quel point cela peut \u00eatre mauvais, j'ai effectu\u00e9 des audits de code rigoureux et j'ai vu des choses auxquelles vous, les gens, n'avez m\u00eame pas pens\u00e9.<\/i>. Mais je sais aussi \u00e0 quoi ressemblent de bonnes structures, comment les utiliser<\/a><\/noindex> et et pourquoi il est n\u00e9cessaire de le faire.<\/a><\/noindex>Je peux imaginer un monde o\u00f9 Firestore semblerait tout \u00e0 fait logique, et o\u00f9 les personnes qui l'ont cr\u00e9\u00e9e penseraient avoir fait du bon travail. Mais nous ne vivons pas dans ce monde.<\/p>\n
Le support de la construction de requ\u00eates dans FireBase est m\u00e9diocre selon n'importe quelle norme, il est pratiquement inexistant. Il n\u00e9cessite clairement des am\u00e9liorations, ou au moins une r\u00e9vision. Mais Firestore n'est pas beaucoup mieux, car il est limit\u00e9 par les m\u00eames index unidimensionnels que l'on trouve dans un simple SQL. Si vous avez besoin de requ\u00eates que les gens effectuent avec des donn\u00e9es chaotiques, vous aurez besoin d'une recherche textuelle compl\u00e8te, de filtres sur plusieurs plages et d'un ordre d\u00e9fini par l'utilisateur al\u00e9atoirement. En examinant de pr\u00e8s les fonctions du simple SQL, elles sont en soi trop limit\u00e9es. De plus, les seules requ\u00eates SQL que les gens peuvent ex\u00e9cuter en production sont des requ\u00eates rapides. Vous aurez besoin d'une solution sp\u00e9cialis\u00e9e pour l'indexation avec des structures de donn\u00e9es r\u00e9fl\u00e9chies. Pour tout le reste, il doit au moins y avoir un map-reduce incr\u00e9mental ou quelque chose de similaire.<\/p>\n
Si vous recherchez des informations \u00e0 ce sujet dans la documentation de Google, esp\u00e9rons que cela vous orientera vers quelque chose comme BigTable et BigQuery. Cependant, toutes ces solutions s'accompagnent d'un volume de jargon dense li\u00e9 aux ventes d'entreprise, si bien que vous revenez rapidement en arri\u00e8re et recommencez \u00e0 chercher autre chose.<\/p>\n
La derni\u00e8re chose dont vous avez besoin dans une base de donn\u00e9es en temps r\u00e9el, c'est quelque chose cr\u00e9\u00e9 par des humains et pour des humains, fonctionnant \u00e0 l'\u00e9chelle des salaires pour des cadres.<\/p>\n
(*) C'est une blague, il n'existe pas de concept tel que compatibilit\u00e9 JSON \u00e0 100%<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
En tant que publicit\u00e9<\/h4>\n
\nVous cherchez \u2014 serveur d\u00e9di\u00e9 virtuel.<\/a><\/noindex> un serveur pour le d\u00e9veloppement et l'h\u00e9bergement de projets ? Vous \u00eates exactement notre client \ud83d\ude42 La tarification journali\u00e8re des serveurs de diff\u00e9rentes configurations, anti-DDoS et licences Windows sont d\u00e9j\u00e0 incluses dans le prix.<\/p>\n
\"Cette<\/a><\/noindex>
\n
Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u043e\u0437\u0432\u043e\u043b\u044c\u0442\u0435 \u043c\u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e. \u041c\u043d\u043e\u0433\u043e \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043b \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0441\u043e \u0432\u0441\u0442\u0440\u043e\u0435\u043d\u043d\u044b\u043c\u0438 \u0432 \u043d\u0435\u0433\u043e \u0444\u0443\u043d\u043a\u0446\u0438\u044f\u043c\u0438 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b. \u042d\u0442\u043e \u0431\u044b\u043b \u0443\u0434\u043e\u0431\u043d\u044b\u0439 \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0439 \u0441\u0442\u0435\u043a, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0441\u044f \u043f\u043e\u043b\u043d\u044b\u0439 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b \u0440\u0430\u043d\u043d\u0435\u0433\u043e React \u0438 CouchDB. \u041e\u043d \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043b \u0434\u0430\u043d\u043d\u044b\u0435 \u043f\u043e JSON OT. \u0415\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0440\u0430\u0431\u043e\u0442\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u043e\u0434\u043d\u0430\u043a\u043e \u0448\u0438\u0440\u043e\u043a\u0430\u044f \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u043e\u0441\u0442\u044c \u0438 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b \u0432 \u0434\u0440\u0443\u0433\u0438\u0445 \u0441\u0444\u0435\u0440\u0430\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96466,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96465","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cette base de donn\u00e9es est en feu\u2026 | ProHoster","description":"Laissez-moi vous raconter une histoire technique. Il y a de nombreuses ann\u00e9es.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u042d\u0442\u0430 \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u043e\u0433\u043d\u0435\u2026 | ProHoster","og:description":"\u041f\u043e\u0437\u0432\u043e\u043b\u044c\u0442\u0435 \u043c\u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e. \u041c\u043d\u043e\u0433\u043e \u043b\u0435\u0442.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-12T05:42:27+00:00","article:modified_time":"2020-10-12T05:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"96465","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:42:30","updated":"2022-09-29 13:02:04","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/96465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}