Réunion du 21-01-2025

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Base de données

Stockage des assets

• Sur sa grille, Vincent Sylvester utilise un système basé sur SRAS (Simply Ruby Assets Service) qui ressemble à FS Assets. SRAS stocke les assets sur le disque, effectue la compression et la déduplication des assets identiques. Ce type de système stocke les assets sous forme de fichiers via leur hachage, de sorte que plusieurs uuids d'assets peuvent faire référence aux mêmes données s'il s'agit de la même chose. La déduplication permet de réduire les besoins en stockage et d'augmenter la vitesse de la recherche.
• La déduplication peut parfois permettre d'économiser 30 à 40 % d'espace disque. Bien que son efficacité ne soit pas toujours aussi grande qu'on pourrait le penser, elle reste préférable à un stockage direct de tous les fichiers dans la base de données.

Nettoyage des assets

• Vincent Sylvester a écrit une routine pour récupérer le hash d'un asset, vérifier s'il existe dans la base de données et s'il n'existe pas il le retire des assets. Ainsi il a pu supprimer environ 43000 notecards soit 210 Mo. Il a également ajusté un script pour qu'il limite le taux de spam de notecards à 60 par jour. Cela prend un certain temps à lire étant donné le nombre de fichiers, environ 7 millions.
• Il a aussi supprimé des scripts qui génèrent des notecards toutes les 5 minutes. Il estime qu'ils ne méritent pas d'exister.

Le hachage

• Les hashes, comme SHA-256, sont presque uniques, mais il existe des cas de collisions d'UUID, c'est-à-dire que le hachage de deux objets peut renvoyer le même UUID. Dans l'ensemble, la probabilité est suffisamment faible pour que les problèmes ne soient pas catastrophiques, mais ils sont possibles.
• La compression sans perte est un processus qui réduit la taille des données sans perdre d'informations. Pour que cela fonctionne correctement, il faut des algorithmes robustes qui peuvent gérer les données de manière efficace.
• Les UUID basés sur le temps utilisent des éléments comme l'horodatage pour générer des identifiants. Les collisions uuid basées sur le temps devraient être minimales.
• OpenSimulator utilise des GUID (Identifiants Globaux Uniques) par défaut de Microsoft, qui sont souvent utilisés dans les applications Windows. Ces UUID sont généralement générés à l'aide d'une méthode statique qui crée un UUID de version 4, conforme à la norme RFC 4122.
• .NET 8 utilise des UUID de type 4, ce qui est cohérent avec l'utilisation de GUID par défaut de Microsoft.

UUID et Efficacité de Recherche

• Certaines personnes pensent que les UUID réduisent les performances des bases de données en augmentant le temps de réponse des algorithmes de recherche. Ubit Umarov n'est pas forcément de cet avis, il pourrait y avoir d'autres facteurs qui entrent en jeu. Toutefois il évoque les UUID de type 7 et 8, qui pourraient avoir des modifications compatibles avec les bases de données.
• En comparant les algorithmes de recherche passés à "bogo sort" et les algorithmes de recherche actuels à "bubble sort", Vincent Sylvester souligne que les recherches dans le passé étaient extrêmement inefficaces par rapport à celles d'aujourd'hui. Il mentionne que MySQL travaille à améliorer ses algorithmes de recherche alors que MariaDB se concentre sur l'efficacité de l'utilisation de la mémoire.
• 🏗️

Cache

• 🏗️

Infos

Développement d'une application pour Zoom

• 🏗️

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-01-21