Le système au début peut tout faire fonctionner. Avec peu de données, il est facile de monter une architecture sans rencontrer de problèmes. La véritable épreuve ne vient pas du premier jour, mais au moment où les données commencent à s’accumuler de façon exponentielle.
Prenons une application de complexité moyenne pour faire un calcul : elle génère entre 50 et 100 Ko de données d’état et de comportement par jour. En un an ? 18-36 Go. Ajoutez à cela des données dérivées et des images de sauvegarde, la taille réelle double. Cela peut sembler n’être qu’un chiffre, mais le problème ne réside pas dans l’écriture, mais dans le fait que ces données ne peuvent tout simplement pas s’arrêter. Elles sont lues, vérifiées et combinées à plusieurs reprises. Si les relations de référence deviennent chaotiques, la complexité du système explose de façon exponentielle.
C’est là que commence la conception de Walrus. Il ne suppose pas que la croissance des données s’arrêtera, ni que les objets ne seront écrits qu’une seule fois. La philosophie de Walrus est la suivante : lors de la création d’un objet, celui-ci reçoit une identité stable qui ne changera jamais. Toutes les modifications sont enregistrées comme une évolution de l’état du même objet. À petite échelle, cela ne se voit pas, mais avec le temps, cet avantage de conception sera progressivement amplifié.
Regardons les données révélées par les tests : stockage d’objets supportant plusieurs Mo, garantissant la disponibilité grâce à une redondance multi-nœuds, la stabilité de la disponibilité globale dans le réseau de test dépasse 99 %. La latence de lecture reste au niveau de quelques secondes, ce qui permet une utilisation directe par des applications réelles, pas seulement pour l’archivage de données froides.
Ce qui est encore plus crucial, c’est la transformation au niveau de l’application. Lorsque les références d’objets ne changent plus fréquemment, l’application peut effectuer des optimisations en profondeur autour d’une structure de données stable, ce qui est difficile à réaliser dans un modèle de stockage traditionnel.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
6 J'aime
Récompense
6
7
Reposter
Partager
Commentaire
0/400
WhaleMistaker
· Il y a 23h
Le moment où l'explosion de données devient vraiment l'enfer, on ne peut pas le voir au début. L'idée de Walrus n'est pas mal, l'identification stable peut vraiment résoudre le problème de confusion des références. Une disponibilité de 99% est également raisonnable, non ?
Voir l'originalRépondre0
BakedCatFanboy
· 01-08 07:30
Le moment où les données s'accumulent est vraiment l'enfer, on ne le voyait pas quand on était petit. La philosophie d'identité immuable de Walrus est vraiment géniale, pas besoin de traiter à plusieurs reprises des choses en désordre liées aux références.
Voir l'originalRépondre0
OldLeekMaster
· 01-07 20:53
Lorsque la quantité de données atteint un certain seuil, cela finit par se voir, les petits projets ne montrent effectivement pas de différence. La démarche Walrus est plutôt intéressante, la solution de stabilité de l'identité + l'évolution de l'état résolvent vraiment les points sensibles. Une disponibilité de 99% et une latence en secondes, bien que cela ne semble pas exagéré, peu de projets peuvent réellement être mis en œuvre.
Voir l'originalRépondre0
NftBankruptcyClub
· 01-07 20:50
Lorsque la quantité de données explose, l'architecture révèle sa véritable nature, je le ressens profondément. J'ai déjà vu de nombreux projets qui, lors de leur lancement, se vantent énormément, mais dès que les données atteignent un certain volume, ils s'effondrent... La solution de Walrus pour une identification stable est vraiment exceptionnelle, ce n'est pas une simple solution de stockage à la mode.
Voir l'originalRépondre0
CoconutWaterBoy
· 01-07 20:49
Au moment où les données s'accumulent, le système commence à crier, cette sensation est tellement réelle… L'idée de Walrus n'est pas mauvaise, la stabilisation de l'identification est vraiment une percée.
Voir l'originalRépondre0
MemeCoinSavant
· 01-07 20:46
yo c'est vraiment le move... l'identité stable de l'objet à travers l'évolution de l'état a un impact différent une fois que tes données commencent à saturer le système, je ne vais pas mentir
Voir l'originalRépondre0
GateUser-7b078580
· 01-07 20:41
L'accumulation de données est le véritable facteur déterminant, 18-36 Go par an et cela pourrait encore doubler. Combien de temps cette échelle pourra-t-elle durer, on verra bien.
Le système au début peut tout faire fonctionner. Avec peu de données, il est facile de monter une architecture sans rencontrer de problèmes. La véritable épreuve ne vient pas du premier jour, mais au moment où les données commencent à s’accumuler de façon exponentielle.
Prenons une application de complexité moyenne pour faire un calcul : elle génère entre 50 et 100 Ko de données d’état et de comportement par jour. En un an ? 18-36 Go. Ajoutez à cela des données dérivées et des images de sauvegarde, la taille réelle double. Cela peut sembler n’être qu’un chiffre, mais le problème ne réside pas dans l’écriture, mais dans le fait que ces données ne peuvent tout simplement pas s’arrêter. Elles sont lues, vérifiées et combinées à plusieurs reprises. Si les relations de référence deviennent chaotiques, la complexité du système explose de façon exponentielle.
C’est là que commence la conception de Walrus. Il ne suppose pas que la croissance des données s’arrêtera, ni que les objets ne seront écrits qu’une seule fois. La philosophie de Walrus est la suivante : lors de la création d’un objet, celui-ci reçoit une identité stable qui ne changera jamais. Toutes les modifications sont enregistrées comme une évolution de l’état du même objet. À petite échelle, cela ne se voit pas, mais avec le temps, cet avantage de conception sera progressivement amplifié.
Regardons les données révélées par les tests : stockage d’objets supportant plusieurs Mo, garantissant la disponibilité grâce à une redondance multi-nœuds, la stabilité de la disponibilité globale dans le réseau de test dépasse 99 %. La latence de lecture reste au niveau de quelques secondes, ce qui permet une utilisation directe par des applications réelles, pas seulement pour l’archivage de données froides.
Ce qui est encore plus crucial, c’est la transformation au niveau de l’application. Lorsque les références d’objets ne changent plus fréquemment, l’application peut effectuer des optimisations en profondeur autour d’une structure de données stable, ce qui est difficile à réaliser dans un modèle de stockage traditionnel.