Boucle UPDATE, RAND

[niahoo]

ça fait quoi le moral au juste pour les citoyens ?

[Keltaïnen]

Hello !

@Ter Rowan : l'idée est intéressante si le champ random est actualisé par les actions utilisateurs (et après on applique ce % lors de la mise à jour globale) mais ça ne peut pas fonctionner dans le cas présent car tous les enregistrements auront la même valeur.

@Metallique : d'après ce que je comprends de ce que tu souhaites, je pense que la solution de Xénos est appropriée dans ton cas car tu as besoin d'un traitement dédié à chaque enregistrement. Du coup tu es obligé de faire plein de requêtes, les passer en procédures stockées te permettra d'économiser des temps de transfert et certains calculs intermédiaires entre la base et l'application.
N'étant pas très fan des procédures stockées je te propose une autre approche, pas forcément mieux mais différente.
Tu dois probablement pouvoir faire un gros SELECT qui te ressort toutes les ressources disponibles ensuite c'est un problème algorithmique. Si tu connais ta population totale, tu sais combien de ressources de chaque type tu attends, il est alors facile de savoir si tout le monde est satisfait.
Après je pense qu'il faut prioriser les populations à nourrir en premier.
Ex : avec 40 serfs, 40 artisans et 20 bourgeois. Si tu en nourris 80, la répartition peut être 30 / 35 / 15 (-20% pour tout le monde) ou 40 / 40 / 0 (-20% pour 1/5 et +20% pour 4/5), la répartition du moral ne sera pas la même.
C'est vrai que c'est assez général mais c'est une idée.
Tu peux ajouter un champ aux personnages indiquant l'heure de récupération des ressources au moment de l'attribution. Ensuite tu comptes le nombre d'entre eux (par population) qui n'ont pas été mis à jour. Mais, de toutes façons, tant que tu as un rand() individuel à appliquer, tu auras forcément un update par personnage.

[Xenos]

@TerRowan
Clairement pas sur de grands jeux de données ! Après, cela peut faire une première ébauche pour les débuts.

Tu dois probablement pouvoir faire un gros SELECT qui te ressort toutes les ressources disponibles

Attention aux concurrences: vu que le temps de traiement va être non négligeable (apparamment), que se passera-t-il si un joueur altère ses ressources pendant le traitement? l'altération sera perdue? Cf SELECT FOR UPDATE / LOCK IN SHARE MODE

tant que tu as un rand() individuel à appliquer, tu auras forcément un update par personnage.

Pas nécessairement. Là, si j'ai bien compris, l'idée est de donner de la nourriture au pif. Cela peut se faire en rajoutant une colonne (dans une temp table ou dans la table de population) indiquant la "priorité d'accès aux ressources". Cette colonne peut être alors remplie par un RAND, ou par l'utilisateur. Il suffit ensuite de faire son ORDER BY sur cette colonne pour attribuer les ressources à chaque tranche de population.

Si nécessaire, une autre colonne "total de ressources déjà mangée par les autres" peut également être rajoutée. Elle vaudra alors qqc du genre UPDATE population_infos pi SET ressources_consommes_par_les_precedents = (SELECT SUM(ressources_consommes) FROM population ... WHERE population.priorite > pi.priorite). Il suffit alors de n'UPDATE que les lignes pour lesquelles ressources_consommes_par_les_precedents <= ressources_dispos.

[Keltaïnen]

tant que tu as un rand() individuel à appliquer, tu auras forcément un update par personnage.

Pas nécessairement. Là, si j'ai bien compris, l'idée est de donner de la nourriture au pif. Cela peut se faire en rajoutant une colonne (dans une temp table ou dans la table de population) indiquant la "priorité d'accès aux ressources". Cette colonne peut être alors remplie par un RAND, ou par l'utilisateur. Il suffit ensuite de faire son ORDER BY sur cette colonne pour attribuer les ressources à chaque tranche de population.

Oui mais ça ne change pas le fait qu'à un moment il faut faire un "update personnage set nimporte_quel_champ = RAND() where id = <id>" et qu'on ne peut pas se passer du "where" car le RAND() est calculé une seule fois par requête.
Après on peut effectivement déporter le calcul du RAND() au niveau du joueur. Par exemple il est recalculé pour toute sa population à chaque fois qu'il se connecte. On aura alors 160 requête d'un coup (pour l'exemple donné) mais on soulagera le traitement global qui attribut les ressources.

[edit]
Je viens de tester sur un MySQL 5.7, le RAND() est maintenant appliqué individuellement sur chaque ligne lors d'un update donc on se casse les pieds pour rien, à ce niveau là du moins.

[Keltaïnen]

J'ai oublié de répondre pour la concurrence.

A ce niveau là c'est vrai qu'on peut être embêté si on a un temps de traitement trop long.
Si on le fait au niveau applicatif on pourra rapidement estimer pour chaque ressource s'il y en a suffisament (c'est pas long cette partie). On a ensuite 2 cas :
- la ressource est insuffisante => on met la quantité à 0
- la ressource est suffisante => on retranche le nombre de personnages concernés.

Et ensuite seulement on s'occupe de gérer les variations de moral qui prennent plus de temps. On peut aussi locker la table mais c'est pas super je trouve car si le traitement est lent ça va bloquer le reste. Il vaut mieux se casser la tête à le faire rapidement je pense.

[Xenos]

Nope:

CREATE TEMPORARY TABLE `rand` (

  id INT,

  val DOUBLE

)

ENGINE=HEAP;



INSERT INTO `rand` (id, val) (SELECT id, RAND() FROM population);



UPDATE personnage p

INNER JOIN `rand` AS r ON r.id = p.id

SET nimporte_quel_champ = r.val;

[Keltaïnen]

Ah là je dois dire que j'aime ton style ;-)
Ça reste dans ce que je disais juste avant puisque tu crées un rand() par personnage mais c'est malin de le passer dans le select pour limiter le nombre de requêtes.

Bon je doute que ça tienne sur une table d'un million (vu que MySQL décroche généralement vers 10000 pour les inserts groupés) et tu as pas mal de jointures mais j'aime bien l'idée quand même car on peut quand même s'en sortir en découpant le résultat du select en plus petites portions.

[Xenos]

Non, tout dépend de la taille du buffer du serveur (et donc, de sa RAM). MySQL gère très bien les gros UPDATE de l'ordre du million de lignes, si on ne rate pas les index et qu'on lui fourni la RAM nécessaire.

[Xenos]

Allez, pour la curiosité de la chose, voici une proposition. La partie la plus problématique reste le cumulatif des ressources consommées. Ca peut certainement s'améliorer encore. 10secondes environ pour 65k lignes de population, 1k joueurs (65 populations/joueur)

SET PROFILING := 1;

-- Ca, c'est pour mon initialisation

DROP TABLE IF EXISTS `integers`;

CREATE TABLE integers (

	n INT UNSIGNED NOT NULL,

	PRIMARY KEY (`n`)

) ENGINE=InnoDB;



INSERT INTO integers (n) VALUES (0),(1),(2),(3)/*,(4),(5)*/;

INSERT INTO integers (n) (SELECT i.n+(SELECT COUNT(*) FROM integers)*j.n FROM integers AS i INNER JOIN integers AS j WHERE j.n > 0);

INSERT INTO integers (n) (SELECT i.n+(SELECT COUNT(*) FROM integers)*j.n FROM integers AS i INNER JOIN integers AS j WHERE j.n > 0);

INSERT INTO integers (n) (SELECT i.n+(SELECT COUNT(*) FROM integers)*j.n FROM integers AS i INNER JOIN integers AS j WHERE j.n > 0);

SELECT MAX(n) FROM integers;



-- Ca, c'est la nouvelle table de population (colonnes en plus)

DROP TABLE IF EXISTS population;

CREATE TABLE population (

	id INT UNSIGNED NOT NULL,

	id_joueur INT UNSIGNED NOT NULL,

	moral DOUBLE DEFAULT 0,

	priorite DOUBLE DEFAULT 0,

	eat DOUBLE DEFAULT 0,

	sum_eat DOUBLE DEFAULT 0,

	PRIMARY KEY (`id`),

	INDEX `idx_id_joueur` (`id_joueur`)

) ENGINE=InnoDB;



DROP TABLE IF EXISTS `resources`;

CREATE TABLE resources (

	id_joueur INT UNSIGNED NOT NULL,

	quantite DOUBLE DEFAULT 0,

	PRIMARY KEY(`id_joueur`)

) ENGINE=InnoDB;



INSERT INTO population (id, id_joueur) (SELECT n, CEIL(1000*RAND()) FROM integers);

INSERT INTO resources (id_joueur, quantite) (SELECT n, RAND()*100000 FROM integers WHERE n BETWEEN 1 AND 1000);



-- Fin de l'initialisation

-- Début du vrai algo



-- Là, c'est à toi de fixer l'algo disant combien de ressources veut la population

UPDATE population SET eat = RAND()*1000;



-- La priorité, soit rand, soit définie par des règles du jeu

UPDATE population SET priorite = RAND();



-- Le cumulatif des ressources consommées

UPDATE population p 

INNER JOIN (

	SELECT p.id, IFNULL(SUM(p2.eat),0)+p.eat AS x

	FROM population p

	LEFT JOIN population p2 ON p2.id_joueur = p.id_joueur AND p2.priorite > p.priorite

	GROUP BY p.id) AS s

	ON s.id = p.id

SET sum_eat = s.x;



-- Un petit SELECT pour voir les données

SELECT * FROM population ORDER BY id_joueur DESC, priorite DESC;

 

UPDATE population p 

INNER JOIN resources r ON r.id_joueur = p.id_joueur

SET p.moral = IF(r.quantite >= p.sum_eat, p.moral + 20, p.moral - 20);



UPDATE resources r 

SET r.quantite = GREATEST(r.quantite - (SELECT MAX(sum_eat) FROM population AS p WHERE p.id_joueur = r.id_joueur), 0);



SHOW PROFILES;

SET PROFILING := 0;

[MeTaLLiQuE]

Je n'ai pas lu toutes vos réponses, j'y répondrai plusnen détail quand j'aurais plus de temps.

Mais 10 secondes pour 65k lignes ?! C'est énorme :/ alors que le jeu contiendra énormément plus de lignes (de population pa joueur).

Je n'ai jamais utilisé de procédures stockées, alors vive ma misère ^^