Code d'erreur 1117 Trop de colonnes; MySQL colonne-limite sur la table

J'ai une table avec 1699 colonnes et quand j'essaye d'insérer plus de colonnes, je reçois,

Code d'erreur: 1117. Trop de colonnes

Dans ce tableau je n'ai que 1000 lignes. Pour moi, le plus important est le nombre de colonnes. Y a-t-il des limites sur la table? Je veux créer 2000 colonnes. Est-ce possible?

Pourquoi auriez-vous besoin de créer une table avec même 20 colonnes, sans parler de 2000 ???

Les données dénormalisées accordées peuvent éviter d'avoir à faire des jointures pour extraire plusieurs colonnes de données. Toutefois, si vous avez plus de 10 colonnes, vous devriez vous arrêter et penser à ce qui se passerait sous le capot lors de la récupération des données.

Si une table de 2 000 colonnes subit SELECT * FROM ... WHERE, vous devez générer de grandes tables temporaires pendant le traitement, extraire des colonnes inutiles et créer de nombreux scénarios dans lesquels les paquets de communication ( max_allowed_packet ) sont poussés à la limite de chaque requête.

Lorsque j'étais développeur, je travaillais dans une entreprise en 1995, où DB2 était le principal SGBDR. La société ne disposait que d’une seule table comportant 270 colonnes, ainsi que de dizaines d’index, et rencontrait des problèmes de performances lors de la récupération des données. Ils ont contacté IBM et des consultants ont examiné l'architecture de leur système, y compris cette table monolithique. "Si vous ne normalisez pas cette table au cours des deux prochaines années, DB2 échouera pour les requêtes exécutant Stage2 Processing (toutes les requêtes nécessitant un tri sur des colonnes non indexées)". Cela a été dit à une entreprise de plusieurs milliards de dollars, pour normaliser un tableau de 270 colonnes. Combien plus une table de colonne 2000.

En termes de mysql, vous devrez compenser cette mauvaise conception en définissant des options comparables à celles de DB2 Stage2 Processing. Dans ce cas, ces options seraient

• max_allowed_packet
• tmp_table_size
• max_tmp_tables
• max_heap_table_size
• max_length_for_sort_data
• max_sort_length
• sort_buffer_size
• myisam_max_sort_file_size
• myisam_sort_buffer_size

Modifier ces paramètres pour compenser la présence de dizaines, et encore moins de centaines de colonnes, fonctionne bien si vous avez des To de RAM.

Ce problème se multiplie géométriquement si vous utilisez InnoDB car vous devrez traiter avec MVCC (Multiversion Concurrency Control) en essayant de protéger des tonnes de colonnes avec chaque SELECT, UPDATE et DELETE par l’isolement de transaction.

CONCLUSION

Il n'y a pas de substitut ou de pansement qui puisse compenser une mauvaise conception. S'il vous plaît, pour votre santé mentale à l'avenir, normalisez cette table aujourd'hui !!!

J'ai du mal à imaginer quoi que ce soit dont le modèle de données pourrait légitimement contenir 2 000 colonnes dans un tableau correctement normalisé.

Mon hypothèse est que vous êtes probablement en train de créer une sorte de schéma dénormalisé «remplissez les espaces», dans lequel vous stockez en fait toutes sortes de données dans une seule table, au lieu de les décomposer en plusieurs tables et de créer des relations. , vous avez différents champs qui enregistrent quel "type" de données est stocké dans une ligne donnée, et 90% de vos champs sont NULL. Même dans ce cas, vouloir atteindre 2000 colonnes ... beurk.

La solution à votre problème consiste à repenser votre modèle de données. Si vous stockez une grande quantité de données clés / valeurs associées à un enregistrement donné, pourquoi ne pas les modéliser de cette manière? Quelque chose comme:

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

Ensuite, vous pouvez simplement obtenir toutes les entrées de capteur associées à un enregistrement "principal" donné SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. Si vous devez obtenir les données d'un enregistrement dans la mastertable avec toutes les données de capteur pour cet enregistrement, vous pouvez utiliser une jointure:

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

Et ensuite, rejoint si vous avez besoin de détails sur ce que chaque capteur est.

C'est un système de mesure avec 2000 capteurs

Ignorez tous les commentaires sur la normalisation - ce que vous demandez pourrait être une conception de base de données raisonnable (dans un monde idéal) et parfaitement normalisée. C'est tout à fait inhabituel et, comme indiqué ailleurs, les SGBDR ne sont généralement pas conçus pour autant de colonnes. .

Bien que vous n'ayez pas atteint la limite stricte de MySQL , l'un des autres facteurs mentionnés dans le lien vous empêche probablement d'aller plus haut.

Comme le suggèrent d'autres personnes, vous pouvez contourner cette limitation en disposant une table enfant avec id, sensor_id, sensor_value, ou plus simplement, vous pouvez créer une seconde table pour ne contenir que les colonnes qui ne rentreront pas dans la première (et utiliser le même PK).

Nombre de colonnes dans MySQL 5.0 (emphase ajoutée):

Il existe une limite fixe de 4096 colonnes par table , mais le maximum effectif peut être inférieur pour une table donnée. La limite exacte dépend de plusieurs facteurs en interaction.

• Chaque table (quel que soit le moteur de stockage) a une taille de ligne maximale de 65 535 octets. Les moteurs de stockage peuvent imposer des contraintes supplémentaires à cette limite, réduisant ainsi la taille maximale effective de la ligne.

  La taille maximale de la ligne limite le nombre (et éventuellement la taille) des colonnes car la longueur totale de toutes les colonnes ne peut pas dépasser cette taille.

...

Les moteurs de stockage individuels peuvent imposer des restrictions supplémentaires limitant le nombre de colonnes de la table. Exemples:

• InnoDB autorise jusqu'à 1000 colonnes.

D'abord un peu plus flamboyant, ensuite une vraie solution ...

Je suis surtout d'accord avec les flammes déjà lancées sur vous.

Je ne suis pas d'accord avec la normalisation des valeurs-clés. Les requêtes finissent par être horribles; performance encore pire.

Un moyen "simple" d'éviter le problème immédiat (limitation du nombre de colonnes) consiste à "partitionner verticalement" les données. Disons, par exemple, 5 tables de 400 colonnes chacune. Ils auraient tous la même clé primaire, sauf que l'un d'entre eux pourrait être AUTO_INCREMENT.

Il serait peut-être préférable de choisir la douzaine de champs les plus importants et de les placer dans le tableau principal. Regroupez ensuite les capteurs de manière logique et mettez-les dans plusieurs tables parallèles. Avec le regroupement approprié, vous ne serez peut-être pas obligé de JOIN toutes les tables tout le temps.

Êtes-vous en train d'indexer certaines des valeurs? Avez-vous besoin de chercher sur eux? Vous recherchez probablement sur datetime?

Si vous avez besoin d'indexer beaucoup de colonnes - punt.

Si vous devez en indexer quelques-uns, mettez-les dans la table principale.

Voici la vraie solution (si elle s'applique) ...

Si vous n'avez pas besoin de la vaste gamme de capteurs indexés, ne créez pas de colonnes! Oui, tu m'as entendu Au lieu de cela, collectez-les dans JSON, compressez-le, stockez-le dans un champ BLOB. Vous allez économiser une tonne d'espace; vous aurez une seule table, avec pas de problèmes de limite de colonne; etc. Votre application se décompressera, puis utilisera le JSON comme structure. Devine quoi? Vous pouvez avoir une structure - vous pouvez regrouper les capteurs dans des tableaux, des éléments multiniveaux, etc., tout comme votre application le souhaiterait. Une autre "fonctionnalité" - il est ouvert. Si vous ajoutez d'autres capteurs, vous n'avez pas besoin de modifier le tableau. JSON si flexible de cette façon.

(La compression est facultative. Si votre jeu de données est énorme, cela vous aidera avec de l'espace disque, donc des performances globales.)

Je vois cela comme un scénario possible dans le monde des données volumineuses, où vous n’effectuerez peut-être pas le type classique de requêtes select *. Nous traitons cela dans le monde de la modélisation prédictive au niveau client, où nous modélisons un client à travers des milliers de dimensions (toutes ayant une valeur de 0 ou 1). Ce mode de stockage facilite les activités de construction de modèles en aval, etc., lorsque les facteurs de risque se trouvent dans la même ligne et le résultat dans la même ligne. Ceci peut être normalisé à partir d'un point de vue de stockage avec une structure parent le modèle prédictif en aval devra le reconvertir en schéma plat. Nous utilisons redshift pour le stockage en colonnes. Ainsi, vos 1000 colonnes et plus lorsque vous chargez les données sont réellement stockées dans un format en colonnes ...

Il y a un moment et un endroit pour cette conception. Absolument. La normalisation n'est pas la solution à tous les problèmes.