Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1418 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Table obèse

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[MySQL] Table obèse

n°2358532
matheo265
Posté le 23-07-2020 à 14:09:28  profilanswer
 

Bonjour tout le monde :hello:  
 
Pour commencer, je tiens à préciser que je suis développeur "touche à tout", et donc spécialisé dans rien :D Je pense pas être unique, c'est comme ça dans certaines boîtes...
 
A ce titre j'ai travaillé il y a 1 an sur un projet de traitement de données remontées par des machines. Ces remontées se font toutes les secondes multiplié par le nombre de machines (une trentaine à ce jour). Tout ça est stocké dans une table ayant la structure suivante :
 

Code :
  1. CREATE TABLE `machinedata` (
  2.   `dat_id` int(11) NOT NULL AUTO_INCREMENT,
  3.   `dat_macid` int(11) NOT NULL,
  4.   `dat_datetime` datetime DEFAULT NULL,
  5.   `dat_field1` varchar(40) COLLATE latin1_general_cs DEFAULT NULL,
  6.   `dat_field2` varchar(40) COLLATE latin1_general_cs DEFAULT NULL,
  7.   `dat_field3` date DEFAULT NULL,
  8.   `dat_field4` datetime DEFAULT NULL,
  9.   `dat_field5` datetime DEFAULT NULL,
  10.   `dat_field6` varchar(15) COLLATE latin1_general_cs DEFAULT NULL,
  11.   `dat_field7` decimal(12,2) DEFAULT NULL,
  12.   `dat_field8` int(11) DEFAULT NULL,
  13.   `dat_field9` int(11) DEFAULT NULL,
  14.   `dat_field10` int(11) DEFAULT NULL,
  15.   `dat_field11` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  16.   `dat_field12` varchar(17) COLLATE latin1_general_cs DEFAULT NULL,
  17.   `dat_field13` int(11) DEFAULT NULL,
  18.   `dat_field14` varchar(20) COLLATE latin1_general_cs DEFAULT NULL,
  19.   `dat_field15` datetime DEFAULT NULL,
  20.   `dat_field16` datetime DEFAULT NULL,
  21.   `dat_field17` int(11) DEFAULT NULL,
  22.   `dat_field18` int(11) DEFAULT NULL,
  23.   `dat_field19` datetime DEFAULT NULL,
  24.   `dat_field20` int(11) DEFAULT NULL,
  25.   `dat_field21` int(11) DEFAULT NULL,
  26.   `dat_field22` int(11) DEFAULT NULL,
  27.   `dat_field23` int(11) DEFAULT NULL,
  28.   `dat_field24` varchar(15) COLLATE latin1_general_cs DEFAULT NULL,
  29.   `dat_field25` varchar(15) COLLATE latin1_general_cs DEFAULT NULL,
  30.   `dat_field26` int(11) DEFAULT NULL,
  31.   `dat_field27` varchar(35) COLLATE latin1_general_cs DEFAULT NULL,
  32.   `dat_field28` int(11) DEFAULT NULL,
  33.   `dat_field29` int(11) DEFAULT NULL,
  34.   `dat_field30` int(11) DEFAULT NULL,
  35.   `dat_field31` int(11) DEFAULT NULL,
  36.   `dat_field32` varchar(15) COLLATE latin1_general_cs DEFAULT NULL,
  37.   `dat_field33` varchar(35) COLLATE latin1_general_cs DEFAULT NULL,
  38.   `dat_field34` int(11) DEFAULT NULL,
  39.   `dat_field35` int(11) DEFAULT NULL,
  40.   `dat_field36` int(11) DEFAULT NULL,
  41.   `dat_field37` int(11) DEFAULT NULL,
  42.   `dat_field38` int(11) DEFAULT NULL,
  43.   `dat_field39` varchar(15) COLLATE latin1_general_cs DEFAULT NULL,
  44.   `dat_field40` int(11) DEFAULT NULL,
  45.   `dat_field41` int(11) DEFAULT NULL,
  46.   `dat_field42` int(11) DEFAULT NULL,
  47.   `dat_field43` int(11) DEFAULT NULL,
  48.   `dat_field44` int(11) DEFAULT NULL,
  49.   `dat_field45` int(11) DEFAULT NULL,
  50.   `dat_field46` int(11) DEFAULT NULL,
  51.   `dat_field47` int(11) DEFAULT NULL,
  52.   `dat_field48` int(11) DEFAULT NULL,
  53.   `dat_field49` decimal(12,2) DEFAULT NULL,
  54.   `dat_field50` int(11) DEFAULT NULL,
  55.   `dat_field51` int(11) DEFAULT NULL,
  56.   `dat_field52` int(11) DEFAULT NULL,
  57.   `dat_field53` int(11) DEFAULT NULL,
  58.   `dat_field54` int(11) DEFAULT NULL,
  59.   `dat_field55` int(11) DEFAULT NULL,
  60.   `dat_field56` int(11) DEFAULT NULL,
  61.   `dat_field57` int(11) DEFAULT NULL,
  62.   `dat_field58` int(11) DEFAULT NULL,
  63.   `dat_field59` int(11) DEFAULT NULL,
  64.   `dat_field60` int(11) DEFAULT NULL,
  65.   `dat_field61` int(11) DEFAULT NULL,
  66.   `dat_field62` int(11) DEFAULT NULL,
  67.   `dat_field63` int(11) DEFAULT NULL,
  68.   `dat_field64` int(11) DEFAULT NULL,
  69.   `dat_field65` int(11) DEFAULT NULL,
  70.   `dat_field66` int(11) DEFAULT NULL,
  71.   `dat_field67` int(11) DEFAULT NULL,
  72.   `dat_field68` int(11) DEFAULT NULL,
  73.   `dat_field69` int(11) DEFAULT NULL,
  74.   `dat_field70` int(11) DEFAULT NULL,
  75.   `dat_field71` int(11) DEFAULT NULL,
  76.   `dat_field72` int(11) DEFAULT NULL,
  77.   `dat_field73` int(11) DEFAULT NULL,
  78.   `dat_field74` int(11) DEFAULT NULL,
  79.   `dat_field75` int(11) DEFAULT NULL,
  80.   `dat_field76` int(11) DEFAULT NULL,
  81.   `dat_field77` int(11) DEFAULT NULL,
  82.   `dat_field78` int(11) DEFAULT NULL,
  83.   `dat_field79` int(11) DEFAULT NULL,
  84.   `dat_field80` int(11) DEFAULT NULL,
  85.   `dat_field81` int(11) DEFAULT NULL,
  86.   `dat_field82` int(11) DEFAULT NULL,
  87.   `dat_field83` int(11) DEFAULT NULL,
  88.   `dat_field84` int(11) DEFAULT NULL,
  89.   `dat_field85` int(11) DEFAULT NULL,
  90.   `dat_field86` int(11) DEFAULT NULL,
  91.   `dat_field87` int(11) DEFAULT NULL,
  92.   `dat_field88` int(11) DEFAULT NULL,
  93.   `dat_field89` int(11) DEFAULT NULL,
  94.   `dat_field90` int(11) DEFAULT NULL,
  95.   `dat_field91` int(11) DEFAULT NULL,
  96.   `dat_field92` int(11) DEFAULT NULL,
  97.   `dat_field93` int(11) DEFAULT NULL,
  98.   `dat_field94` int(11) DEFAULT NULL,
  99.   `dat_field95` int(11) DEFAULT NULL,
  100.   `dat_field96` int(11) DEFAULT NULL,
  101.   `dat_field97` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  102.   `dat_field98` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  103.   `dat_field99` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  104.   `dat_field100` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  105.   `dat_field101` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  106.   `dat_field102` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  107.   `dat_field103` varchar(10) COLLATE latin1_general_cs DEFAULT NULL,
  108.   `dat_field104` int(11) DEFAULT NULL,
  109.   `dat_field105` int(11) DEFAULT NULL,
  110.   `dat_field106` int(11) DEFAULT NULL,
  111.   `dat_field107` int(11) DEFAULT NULL,
  112.   `dat_field108` int(11) DEFAULT NULL,
  113.   `dat_field109` int(11) DEFAULT NULL,
  114.   `dat_field110` varchar(155) COLLATE latin1_general_cs DEFAULT NULL,
  115.   `dat_field111` datetime DEFAULT NULL,
  116.   `dat_field112` int(11) DEFAULT NULL,
  117.   `dat_field113` text COLLATE latin1_general_cs,
  118.   `dat_field114` int(11) DEFAULT '0',
  119.   PRIMARY KEY (`dat_id`),
  120.   KEY `fk_machinesv_idx` (`dat_macid`),
  121.   KEY `date_datetime` (`dat_datetime`),
  122.   CONSTRAINT `fk_machinesv` FOREIGN KEY (`dat_macid`) REFERENCES `machines` (`mac_id`) ON DELETE CASCADE ON UPDATE CASCADE
  123. ) ENGINE=InnoDB AUTO_INCREMENT=251882 DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs;


 
A part les 3 premières, j'ai modifié le nom des colonnes pour plus de confidentialité.  
 
Les spécialistes vont sûrement sauter au plafond tellement ma table doit être horrible...  :sweat: Elle contient aujourd'hui plus de 66 millions d'enregistrement... Et bien sûr devinez quoi : les temps de lecture sont affreusement lents voir impossibles malgré les 10 Go de mémoire sur le serveur...
 
J'imagine que MySQL (dans le cas d'une bdd bien concue) est capable de gérer des tables de plusieurs milions d'enregistrements, non ?
 
Est-ce que quelq'un aurait des conseils pour optimiser tout ça ? J'ai déjà partitionné ma table pour tenter d'aémliorer les perf, ce qui a marché quelques semaines seulement...
 
Merci pour vos retours bienveillants  :ange:  

mood
Publicité
Posté le 23-07-2020 à 14:09:28  profilanswer
 

n°2358533
Erlum
Posté le 23-07-2020 à 14:57:51  profilanswer
 

J'y connais pas grand chose en ressources nécessaires pour faire fonctionner ce genre de bases, mais imo 10go sur un serveur c'est pas grand chose, du tout.

 

Sinon, je connais pas du tout l'application de ta table, mais remonter des choses chaque seconde, est-ce vraiment essentiel pour ton usage ?


Message édité par Erlum le 23-07-2020 à 14:58:14
n°2358534
matheo265
Posté le 23-07-2020 à 15:00:31  profilanswer
 

C'est des machines susceptibles de remonter des défauts, donc des alertes doivent être générées à chaque nouveau défaut.
 
Ensuite je suis d'accord avec toi : toutes les secondes c'est beaucoup ! J'aurai préféré toutes les 15 secondes si possible mais le client final ne veut pas faire de compromis sur ça...

n°2358535
flo850
moi je
Posté le 23-07-2020 à 15:28:46  profilanswer
 

déjà la table avec 120 colonnes, ça pique
 
je ferai 2 tables  
une machinedata (id, date, macid) et une machinedatavalue (id, machinedataid, txtValue, intValue)  
 
mais sinon quelques possiilités :  

  • agglomère les data : si il y a peu de changement d'état tu stocke value/startedAt, endedAt et tu ne cré une ligne que si ça change. Attention, les requetes d'exploitation peuvent être plus complexes
  • utilise les bons index par rapport à ton exploitation
  • partitionne ta table par date / machine


---------------

n°2358536
matheo265
Posté le 23-07-2020 à 15:36:05  profilanswer
 

J'imagine bien que ça pique  :whistle:  
 
Pour le partitionnement j'ai déjà partitionné selon l'expression suivante :  
 

Code :
  1. year(mav_statedate)+month(mav_statedate). Cela m'a semblé le plus simple ?


 
Pour l'agglomération c'est le code qu'il va falloir retoucher au niveau de l'applicatif qui me fait peur, car effectivement (et j'en m'en veux de pas l'avoir vu au départ) il y a des colonnes dont la valeur ne change pas souvent...

n°2358540
Erlum
Posté le 23-07-2020 à 16:50:05  profilanswer
 

Sinon t'as essayé de surveiller les ressources matérielles du serveur au moins ?

n°2358541
rufo
Pas me confondre avec Lycos!
Posté le 23-07-2020 à 17:35:20  profilanswer
 

66 millions de lignes pour une table, c'est pas énorme pour une table MySQL :/
J'ai moitié moins sur un serveur avec que 2 Go de ram et ça passe tranquille. Par contre, ma table n'a pas 120 colonnes :o
 
Comme on n'a pas le nom des colonnes, ça va être difficile d'être plus précis que ce que flo a proposé. Un SDBG, ça se tune : as-tu modifié le fichier de conf de mysql, notamment pour augmenter la taille des buffers des tables temporaires, le nb de tables ouvertes et le buffer de lecture ? Ca, ça devrait déjà aider.
Ensuite, il faudrait probablement restructurer la table en plusieurs tables pour minimiser les données identiques et mieux indexer certains champs. Là, ça va dépendre des requêtes SELECT qui sont faites. Il faut que tu utilises le EXPLAIN pour voir le goulet d'étranglement. Peut-être qu'au lieu d'indexer plusieurs colonnes, pour certains index, tu pourrais faire un seul index qui regroupe 2 ou 3 colonnes.
 
Après, une autre solution pourrait être de passer sur une BD NoSQL. Mais franchement, sans le nom des colonnes, on voit pas ce que ça fait, donc perso, je suis incapable de te proposer une autre structure.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358542
mechkurt
Posté le 23-07-2020 à 17:40:53  profilanswer
 

Une autre piste serait de savoir ce que tu SELECT ?
Est ce que tu compares des machines entre elles, des variations sur un champ pour une même machine, etc...
Dans tous les cas sortir l'id machine et la date dans un table annexe et avoir une table avec l'identifiant unique précédent etun id champ et la valeur sera sans doute plus efficace (je crois que c'est ce que te conseillait flo850)...
Tu peux même optimiser encore plus avec un data_val_int, un data_val_float et un data_val_string.
Magento le fait pour les données des produits, c'est que ça ne doit pas être si mal ! ^^


---------------
D3
n°2358543
rufo
Pas me confondre avec Lycos!
Posté le 23-07-2020 à 18:07:45  profilanswer
 

Oui, enfin Magento ne brille pas par ses perfs :/ Même s'ils ont fait des améliorations, le modèle de BD et ses perfs bof-bof restent l'un des principaux reproches qui lui ont été faits.
Mais c'est vrai qu'une table sur le modèle attribut/valeur pourrait être pertinent.
Dans mon soft de gestion de conf Icare (cf ma signature), c'est ce que j'avais fait : une table "composant" avec juste un libellé et l'ensemble de ses valeurs était dans une table "attribut" qui avait un ID, un libellé d'attribut et une valeur type string. Entre les 2, une table composant-attribut qui liait les ID d'une composant avec les ID des attributs qui le composaient.
C'était très efficace car 70 à 80% des attributs étaient commun entre mes configurations de composants. Du coup, au lieu de dupliquer des valeurs identiques, je faisais juste une entrée dans la table composant-attribut en y mettant 2 entiers.
Pour 250 conf ayant chacune entre 100 à 150 attributs, le logiciel Advitium avait une BD d'environ 100 Mo. Avec ma technique, mon logiciel faisait 5 Mo :D


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358546
TotalRecal​l
Posté le 23-07-2020 à 19:53:49  profilanswer
 

On va commencer par les basiques :
quand tu parles de "temps de lecture" c'est en envoyant quoi comme SELECT ?
Et est ce que les colonnes du WHERE sont indexées ? J'imagine que t'as pas besoin des 60 millions de lignes d'un coup.
Tu fais un SELECT * ou un SELECT sur des colonnes spécifiques ? J'imagine que t'as pas besoin des 150 colonnes d'un coup.
Y a pas moyen de reporter dans une table d'historique les trucs qui ne servent plus (vieilles données, machines disparues du parc...) ?
Éventuellement le SELECT lui même peut être optimisé en rajoutant des critères qui vont aider le SGBDR à cibler les lignes à sortir plus facilement.

Message cité 1 fois
Message édité par TotalRecall le 23-07-2020 à 19:54:49

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
mood
Publicité
Posté le 23-07-2020 à 19:53:49  profilanswer
 

n°2358547
rufo
Pas me confondre avec Lycos!
Posté le 23-07-2020 à 20:10:12  profilanswer
 

Faire une table historique ou partitionner sa table sur la date, ça va revenir à peu près au même, je pense, non ? Or, il a dit qu'il avait déjà partitionné...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358557
matheo265
Posté le 24-07-2020 à 08:33:23  profilanswer
 

rufo a écrit :

Comme on n'a pas le nom des colonnes, ça va être difficile d'être plus précis que ce que flo a proposé. Un SDBG, ça se tune : as-tu modifié le fichier de conf de mysql, notamment pour augmenter la taille des buffers des tables temporaires, le nb de tables ouvertes et le buffer de lecture ? Ca, ça devrait déjà aider.
Ensuite, il faudrait probablement restructurer la table en plusieurs tables pour minimiser les données identiques et mieux indexer certains champs. Là, ça va dépendre des requêtes SELECT qui sont faites. Il faut que tu utilises le EXPLAIN pour voir le goulet d'étranglement. Peut-être qu'au lieu d'indexer plusieurs colonnes, pour certains index, tu pourrais faire un seul index qui regroupe 2 ou 3 colonnes.
 
Après, une autre solution pourrait être de passer sur une BD NoSQL. Mais franchement, sans le nom des colonnes, on voit pas ce que ça fait, donc perso, je suis incapable de te proposer une autre structure.


 
J'ai effectivement fait différentes optimisation en fonction de tuto trouvés sur divers sites. Mais rien n'y a fait...  
 
Je me doute bien que ma structure est foireuse... Mais avec plus de 66 millions de lignes, ça va être compliqué d'éclater ma table et de retravailler les enregistrements... Dans les colonnes il y a de tout... ça peut être un niveau de carburant, une pression de pneus, mais aussi des codes défaut, des messages, etc. Il y a beaucoup de numérique mais pas que.  
 

mechkurt a écrit :

Une autre piste serait de savoir ce que tu SELECT ?
Est ce que tu compares des machines entre elles, des variations sur un champ pour une même machine, etc...


 
il n'y a pas de comparaison de machines entre elle, le logiciel renvoie uniquement les dernières valeurs à un moment T, et permet également au client de générer des rapports et des graphiques. C'est cette dernière partie qui est laborieuse car il suffit que le client mette 20 colonnes sur 2 mois dans son état et les temps de traitement son monstrueusement longs...
 

mechkurt a écrit :

Tu peux même optimiser encore plus avec un data_val_int, un data_val_float et un data_val_string.
Magento le fait pour les données des produits, c'est que ça ne doit pas être si mal ! ^^


 
Je ne connais pas du tout ces types, je vais me renseigner, merci ^^
 

TotalRecall a écrit :

On va commencer par les basiques :  
quand tu parles de "temps de lecture" c'est en envoyant quoi comme SELECT ?  
Et est ce que les colonnes du WHERE sont indexées ? J'imagine que t'as pas besoin des 60 millions de lignes d'un coup.
Tu fais un SELECT * ou un SELECT sur des colonnes spécifiques ? J'imagine que t'as pas besoin des 150 colonnes d'un coup.
Y a pas moyen de reporter dans une table d'historique les trucs qui ne servent plus (vieilles données, machines disparues du parc...) ?
Éventuellement le SELECT lui même peut être optimisé en rajoutant des critères qui vont aider le SGBDR à cibler les lignes à sortir plus facilement.


 
Je ne fais jamais de SELECT *, ça c'est sûr ^^ Par contre comme dit plus haut, il suffit que je fasse un SELECT avec 20 colonnes sur une plage de date de 2 mois et là j'ai droit à un temps d'attente dépassé... Côté indexation j'ai indexé la date/heure car c'est surtout là-dessus que le client va appliquer des filtres. L'ID de la machine également.
 
 

n°2358559
rufo
Pas me confondre avec Lycos!
Posté le 24-07-2020 à 08:49:51  profilanswer
 

Ok, donc, c'est un système de log.
Pour le tuning, t'as utilisé mysqltuner pour avoir des conseils ? https://www.geeek.org/mysqltuner-ou [...] mysql-155/
 
Un changement de structure peut se faire malgré les 66 millions de lignes. T'auras juste à faire un script qui se chargera de prendre les données du schéma initial pour les transformer et les mettre dans la nouvelle BD. Rien de bien compliqué.
 
Vu que c'est un système de Log, pour la scalabilité, passer sur une BD NoSQL, ça serait pas déconnant.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358562
matheo265
Posté le 24-07-2020 à 09:19:46  profilanswer
 

Sur les divers sites que j'ai consulté, j'ai vu que ça parlait de mysqltuner effectivement. Je vais y jeter un oeil, peut-être 2 ^^
 
Mon problème pour répartir les 66 millions d'enregistrement, c'est que je vois pas comment c'est possible sachant que déjà, si je fais un select qui retourne 5000 enregistrements, j'ai une requête qui échoue...

n°2358570
rufo
Pas me confondre avec Lycos!
Posté le 24-07-2020 à 12:38:10  profilanswer
 

Heu, comment tu peux avoir un échec en retournant juste 5000 records :??:
Soit t'as vraiment très mal indexé ta table, soit t'as un pb de conf de Mysql ou un pb hardware (barrette de ram défectueuse ou HDD qui a des pbs de secteurs) :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358582
gilou
Modérateur
Modzilla
Posté le 24-07-2020 à 15:20:33  profilanswer
 

rufo a écrit :

Vu que c'est un système de Log, pour la scalabilité, passer sur une BD NoSQL, ça serait pas déconnant.

Graylog/ElasticSearch/MongoDB comme tout le monde, quoi...
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --    In umbra igitur pugnabimus. --
n°2358645
matheo265
Posté le 27-07-2020 à 10:34:42  profilanswer
 

Merci pour vos retours, je ne suis pas encore initié aux bdd NoSQL. Il faut que je prenne le temps de regarder car j'en entend de plus en plus parler.
 
Après réunion avec le client, il a enfin entendu raison sur la nécessité de ne pas remonter toutes les colonnes chaque seconde. Nous allons donc travailler sur un fractionnement de cette table avec une table comprenant les propriétés qui changent toutes les 15 secondes, et un autre les propriétés toutes les secondes.
 
J'en profiterai pour optimiser les lignes pour ne pas les réinsérer si elles ont les mêmes valeurs qu'à la remontée précédente.
 
Concernant ton message rufo, j'ai optimisé autant que les infos que j'ai pu trouver sur le net. Il y a 10 Go de mémoire sur la machine, selon les tutos que j'ai vu il en faudrait 15 mais là je ne pourrai pas augmenter la capacité.

n°2358646
Erlum
Posté le 27-07-2020 à 11:08:59  profilanswer
 

Votre client est capable de financer le développement d'une solution mais a les poches vides pour quelques barrettes de RAM ? :D

n°2358676
rufo
Pas me confondre avec Lycos!
Posté le 27-07-2020 à 14:11:46  profilanswer
 

C'est vrai que passer de 10 à 15 Go, c'est quand même pas ruineux :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358782
matheo265
Posté le 28-07-2020 à 11:57:20  profilanswer
 

:D  :D  :D  
 

n°2358803
gilou
Modérateur
Modzilla
Posté le 28-07-2020 à 16:36:55  profilanswer
 

rufo a écrit :

C'est vrai que passer de 10 à 15 Go, c'est quand même pas ruineux :/

Si c'est sur une config AWS, ça te monte la facture mensuelle...
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --    In umbra igitur pugnabimus. --
n°2358832
Erlum
Posté le 29-07-2020 à 10:26:01  profilanswer
 

gilou a écrit :

Si c'est sur une config AWS, ça te monte la facture mensuelle...
A+,


 
Oui enfin bon, une solution qui fonctionne mal ça coûte aussi.  :o  
 
10go on est plus proche du laptop lambda que du serveur, même le pauvre T320 sur lequel je bricole chez moi était livré avec 32go.  
Au taf nos serveurs neufs ont 384 à 768go de ram, sans aller jusque là, quelle machine pro (si c'est pas dans le cloud ofc) est autant limitée ?

n°2358863
rat de com​bat
attention rongeur méchant!
Posté le 29-07-2020 à 13:23:45  profilanswer
 

Erlum a écrit :

Au taf nos serveurs neufs ont 384 à 768go de ram,

Oh purée! :ouch:  
Par curiosité, tu as une idée du prix d'une telle machine?

n°2358864
Erlum
Posté le 29-07-2020 à 13:32:29  profilanswer
 

rat de combat a écrit :

Oh purée! :ouch:
Par curiosité, tu as une idée du prix d'une telle machine?


C'est des nœuds Dell VxRail qui supportent un cluster vSphere étendu. Les montants sont complètement débiles, plusieurs dizaines de milliers d'euros par serveur, pas loin des 100000 avec les licences qui vont avec si je dis pas de bêtises.

 

Mais à ce niveau ça devient complètement insensé, les prix d'origine sont sur-gonflés pour te proposer de grosses remises et faire croire au client qu'ils font une affaire. Ah, et les prix plus haut sont après*** remise.


Message édité par Erlum le 29-07-2020 à 17:44:34
n°2358868
rufo
Pas me confondre avec Lycos!
Posté le 29-07-2020 à 14:22:55  profilanswer
 

Et si t'es une administration, c'est encore plus cher :D
Moi, j'ai vu un PC portable vendu 350 € TTC sur CDiscount vendu 1900 € HT !


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358870
gilou
Modérateur
Modzilla
Posté le 29-07-2020 à 14:38:05  profilanswer
 

Erlum a écrit :


 
Oui enfin bon, une solution qui fonctionne mal ça coûte aussi.  :o  
 
10go on est plus proche du laptop lambda que du serveur, même le pauvre T320 sur lequel je bricole chez moi était livré avec 32go.  
Au taf nos serveurs neufs ont 384 à 768go de ram, sans aller jusque là, quelle machine pro (si c'est pas dans le cloud ofc) est autant limitée ?

Les derniers Raspberry Pi 4 peuvent avoir jusqu'à 8Go je crois...
10Go, ça fait vraiment cheap pour une solution pro de BDD.
 
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --    In umbra igitur pugnabimus. --
n°2358882
Erlum
Posté le 29-07-2020 à 15:19:33  profilanswer
 

rufo a écrit :

Et si t'es une administration, c'est encore plus cher :D
Moi, j'ai vu un PC portable vendu 350 € TTC sur CDiscount vendu 1900 € HT !


Je suis dans la territoriale.  :hello:

n°2358894
rufo
Pas me confondre avec Lycos!
Posté le 29-07-2020 à 17:23:51  profilanswer
 

Je compatis :/ Moi, ça me fait toujours bondir quand je vois des prix pareil. Même si dans le prix, t'as la maintenance et la gestion de l'obsolescence (encore que c'est pas toujours le cas) + 2-3 autres trucs, ça faut quand même une marge assez indécente :( Mais l'administration ne peut généralement pas acheter sur CDiscount ou Amazon...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2358895
Erlum
Posté le 29-07-2020 à 17:46:00  profilanswer
 

rufo a écrit :

Je compatis :/ Moi, ça me fait toujours bondir quand je vois des prix pareil. Même si dans le prix, t'as la maintenance et la gestion de l'obsolescence (encore que c'est pas toujours le cas) + 2-3 autres trucs, ça faut quand même une marge assez indécente :( Mais l'administration ne peut généralement pas acheter sur CDiscount ou Amazon...


UGAP et SIPPEREC.  :o  
 
J'ai acheté un produit à 15000€ chez un fournisseur étranger en Europe, hors catalogues.
 
Ça a pris plus d'un an.  :lol:

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Table obèse

 

Sujets relatifs
Installation MySQLphp - MySql - Variable
Sql Server Jointure entre table sur 2 BDDMYSQL : update et select en une seule requête
MySQL[MySQL] - Ajouter un champ calculé à une table
[MySQL] Ajouter un nombre à une colonne nullactualiser une table à partir d'une autre
[MySQL] Extraction de champs Json 
Plus de sujets relatifs à : [MySQL] Table obèse


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR