Comme j'écris une simple application de serveur Minecraft à Erlang, je suis désormais préoccupé par la question de savoir comment stocker et modifier efficacement les données du morceau.
Pour ceux qui ne connaissent pas les internes de Minecraft: je dois stocker beaucoup de binaires (100-1000) d'une taille maximale de 32 Ko en mémoire. Jusqu'à ce moment-là, les fichiers binaires intégrés d'Erlang sont suffisants. Mais le serveur doit lire et modifier certains octets (par leur identifiant) dans ces billets assez souvent et je ne veux pas les copier tout le temps.
Une fonctionnalité agréable serait importée et exporter des fichiers binaires standard d'Erlang.
Y a-t-il une extension ou une base de données Erlang ou tout ce que je pourrais utiliser pour cela?
3 Réponses :
1000 binaires 32kb n'est pas une grosse affaire. Vous dites changer quelques octets? Peut-être que ce serait mieux si vous venez de faire un enregistrement des différentes parties que le binaire peut contenir ou qui sont souvent modifiés, de cette façon, vous pouvez modifier des parties du binaire sans copier les autres. Avec ETS, vous n'avez pas à vous soucier d'un tas de copies binaires en attente d'être GC'ed. Il en fait toujours une copie et c'est toujours GC'ed mais pas de la même manière qu'un processus. Vous pouvez également utiliser FULLWEEP_AFTER OPS pour créer un nettoyage de processus plus souvent.
Depuis que les fichiers binaires sont en lecture seule, je peux penser aux approches suivantes (en supposant que vous vous attendez à un taux élevé de changements):
World: Nouveau (x, y, z) -> ref (); Monde: obtenez (ref, x, y, z); Monde: Set (Ref, X, Y, Z, Valeur);
Merci pour votre grande réponse! Je suppose que je vais utiliser la deuxième façon, car les modifications ne sont pas si souvent (pas plus de 5 octets par seconde et joueur).
Ma suggestion est d'utiliser une structure "corde". Fondamentalement, une structure en forme d'arbre, généralement une arborescence ou une arborescence dans laquelle vous permettez uniquement de changer de parties de l'arbre. Cela vous permet d'avoir le meilleur des deux mondes: immuabilité avec des mises à jour rapides.
Je ne connais pas une mise en œuvre de la corde, mais c'est ce que vous voulez faire.
Une alternative consiste à utiliser ETS comme une matrice mutable. Il est assez rapide pour ce genre de chose.
La troisième option consiste à utiliser une structure arborescente spatiale pour représenter votre monde. Les octrees ou une structure semblable à une BSP sont quelque chose que je saisis, aveuglément.
En fin de compte, le problème a été résolu à l'aide de binaires de taille 4 Ko et de les modifier pour chaque changement de bloc. Bien que ce n'est pas le dernier mot en termes d'efficacité de la mise à jour, mais cela enregistre la mémoire. Si vous souhaitez avoir un look, le code est disponible chez Github .