Hata Kodu 1117 Çok fazla sütun; Masada MySQL sütun limiti

1699 sütunlu bir masam var ve daha fazla sütun eklemeye çalıştığımda

Hata kodu: 1117. Çok fazla sütun

Bu tabloda sadece 1000 satır var. Benim için en önemli şey sütun sayısıdır. Masanın üzerinde herhangi bir sınırlama var mı? 2000 sütun oluşturmak istiyorum. Mümkün mü?

Neden 2000'i bıraksa bile, 20 sütunlu bir tablo oluşturmanız gerekiyor?

Verilmiş, denormalize edilmiş veriler, birçok veri sütununu almak için JOIN'lerin yapılmasını önleyebilir. Ancak, 10'dan fazla sütununuz varsa, veri alımı sırasında başlığın altında ne olacağını düşünmeli ve durmalısınız.

Bir 2000 sütun tablosu SELECT * FROM ... NEREDE geçiyorsa, işlem sırasında gereksiz sütunların alınması ve iletişim paketlerinin ( max_allowed_packet ) her sorguda eşleşecekleri birçok senaryo oluşturacak şekilde büyük geçici tablolar oluşturacaksınız .

Geliştirici olarak önceki günlerimde, 1995 yılında DB2'nin ana RDBMS olduğu bir şirkette çalıştım. Şirketin 270 sütunu, düzinelerce endeksi olan ve veri toplamada performans sorunları olan tek bir masa vardı. IBM ile temasa geçtiler ve danışmanlar, bu tek yekpare masa da dahil olmak üzere, sistemlerinin mimarisini incelediler. Şirkete “Bu tabloyu gelecek 2 yıl içinde normalleştirmezseniz, DB2, Stage2 İşleme yapan sorgularda başarısız olacaktır (dizine eklenmemiş sütunlarda sıralama gerektiren herhangi bir sorgu)”. Bu 270 trilyon tabloyu normalleştirmek için çok trilyon dolarlık bir şirkete söylendi. 2000 sütun tablosu ne kadar.

MySQL açısından, böyle kötü bir tasarımı, DB2 Stage2 İşleme ile karşılaştırılabilir seçenekler ayarlayarak telafi etmeniz gerekir. Bu durumda, bu seçenekler

• 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

Eğer TB RAM'leriniz varsa, bu ayarların onlarca, yüzlerce sütunun varlığını telafi etmek için tweet atması iyi sonuç verir.

InnoDB kullanıyorsanız, bu işlem her SELECT, UPDATE ve DELETE ile işlem yalıtımı yoluyla tonlarca sütunu korumaya çalışırken MVCC (Multiversion Concurrency Control) ile uğraşmanız gerektiği için geometrik olarak çoğalır .

SONUÇ

Kötü tasarım için telafi edilebilecek hiçbir yedek veya yara bandı yoktur. Lütfen, gelecekteki akıl sağlığınız için, bu masayı bugün normalleştirin !!!

Veri modelinin yasal olarak normalize edilmiş bir tabloda 2000 sütun içerebileceği herhangi bir şeyi hayal etmekte zorlanıyorum.

Tahminime göre, muhtemelen bir çeşit "boşlukları doldurun" denormalize şemasını yapıyorsunuz, burada aslında bir çok farklı türde verileri tek bir tabloda saklıyorsunuz ve verileri ayrı tablolara ayırmak ve ilişkiler kurmak yerine belirli bir satırda ne tür "veri depolandığını kaydeden çeşitli alanlarınız var ve alanlarınızın% 90’ı NULL. O zaman bile olsa, 2000 sütuna ulaşmak istiyorum ... yikes.

Sorununun çözümü, veri modelinizi yeniden düşünmektir. Belirli bir kayıtla ilişkili büyük bir anahtar / değer verisi yığını saklıyorsanız, neden bu şekilde modellemiyorsunuz? Gibi bir şey:

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>
);

Sonra belirli bir "ana" kayıtla ilgili tüm sensör girişlerini almak için, sadece yapabilirsiniz SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. masterTablodaki bir kaydın verilerini, o kaydın tüm sensör verileriyle birlikte almanız gerekirse, bir birleştirme kullanabilirsiniz:

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>

Ve sonra her bir sensörün ne olduğuna dair detaylara ihtiyacınız olursa daha da katılırsınız.

2000 sensörlü bir ölçüm sistemi.

Normalleştirme hakkında bağıran tüm yorumları görmezden gelin - istedikleriniz mantıklı bir veritabanı tasarımı olabilir (ideal bir dünyada) ve mükemmel şekilde normalize olmuş, sadece çok sıradışı ve başka yerlerde de belirtildiği gibi RDBMS'ler genellikle bu kadar çok sütun için tasarlanmamıştır .

MySQL zor sınırına ulaşmasanız da, linkte belirtilen diğer etkenlerden biri muhtemelen yükselmenizi engelliyor

Diğerlerinin önerdiği gibi, bu sınırlama ile bir alt tablonuza sahip olarak çalışabilirsiniz id, sensor_id, sensor_valueya da daha basit bir ifadeyle, sadece birinciye sığmayacak sütunları içerecek ikinci bir tablo oluşturabilirsiniz (ve aynı PK’yı kullanın).

MySQL 5.0 Sütun-Sayı Sınırları (vurgu eklenmiştir):

Tablo başına sabit 4096 sütun sınırı vardır , ancak belirli bir tablo için etkin maksimum değer daha düşük olabilir. Kesin sınır birkaç etkileşimli faktöre bağlıdır.

• Her tablonun (depolama motorundan bağımsız olarak) maksimum satır 65.535 bayttır. Depolama motorları bu limit üzerine ek sınırlamalar getirerek etkili maksimum sıra boyutunu azaltabilir.

  Maksimum satır boyutu, sütunların sayısını (ve muhtemelen boyutunu) sınırlar çünkü tüm sütunların toplam uzunluğu bu boyutu aşamaz.

...

Bireysel depolama motorları, tablo sütun sayısını sınırlayan ek kısıtlamalar getirebilir. Örnekler:

• InnoDB 1000 sütuna izin verir.

Önce biraz daha yanan, sonra gerçek bir çözüm ...

Çoğunlukla sana atılmış olan alevleri kabul ediyorum.

Anahtar-değer normalleşmesine katılmıyorum. Sorguların sonucu korkunçtur; performans daha da kötü.

Acil sorunu önlemenin (sütun sayısının sınırlandırılması) bir 'basit' yolu, verileri 'dikey olarak bölmektir'. Örneğin, her biri 400 sütunlu 5 tablo var. Biri AUTO_INCREMENT olması dışında hepsinde aynı birincil anahtar vardır.

Belki de daha iyisi, en önemli düzine alanlara karar vermek, onları “ana” masaya koymak olacaktır. Ardından sensörleri mantıklı bir şekilde gruplandırın ve birkaç paralel tabloya yerleştirin. Doğru gruplama ile, her zaman bütün tablolara KATILMAK gerekmeyebilir.

Değerlerden herhangi birini indeksliyor musunuz? Onları aramaya ihtiyacınız var mı? Muhtemelen tarihini araştırıyorsun?

Çok fazla sütun indekslemeniz gerekiyorsa - punt.

Eğer birkaç tane indekslemeniz gerekirse - 'ana tabloya koyun.

İşte gerçek çözüm (eğer geçerliyse) ...

Dizine eklenmiş geniş bir sensör dizisine ihtiyacınız yoksa, sütun yapmayın! Evet beni duydun. Bunun yerine, onları JSON'da toplayın, JSON'u sıkıştırın, bir BLOB alanına kaydedin. Bir ton alan kazandıracak; sütun sınırı sorunu olmayan tek bir tablonuz olacak; Uygulamanız sıkıştırılmayacak ve daha sonra JSON'u yapı olarak kullanacaktır. Bil bakalım ne oldu? Yapıya sahip olabilirsiniz - sensörleri diziler, çok düzeyli malzemeler vb. Halinde gruplayabilirsiniz, tıpkı uygulamanızın istediği gibi. Başka bir 'özellik' - açık uçlu. Daha fazla sensör eklerseniz, tabloyu DEĞİŞTİRMenize gerek yoktur. JSON bu şekilde esnekse.

(Sıkıştırma isteğe bağlıdır; veri kümeniz çok büyükse, disk alanıyla ve dolayısıyla genel performansla ilgili yardımcı olacaktır.)

Bunu, geleneksel seçme * türündeki sorguları yapamayabileceğiniz büyük veri dünyasında olası bir senaryo olarak görüyorum. Bunu, öngörücü modelleme dünyasında, bir müşteriyi binlerce boyut üzerinden modellediğimiz müşteri düzeyinde ele alıyoruz (hepsi 0 veya 1 değerine sahip). Bu depolama şekli, aynı sıradaki risk faktörlerine sahip olduğunuzda ve aynı sıradaki sonuç bayrağındaki alt model yapı aktivitelerini vb. Kolaylaştırır. Akış yönündeki öngörülü modelin tekrar düz şemaya dönüştürülmesi gerekecek. Sütunlu depolama yapan redshift kullanıyoruz, bu yüzden verileri yüklediğinizde 1000+ sütunlarınız aslında sütun biçiminde saklanır ...

Bu tasarım için zaman ve yer var. Kesinlikle. Normalleşme her sorunun çözümü değildir.