त्रुटि कोड 1117 बहुत अधिक कॉलम; मेज पर MySQL स्तंभ-सीमा

37

मेरे पास 1699 स्तंभों वाली एक तालिका है और जब मैं अधिक कॉलम सम्मिलित करने की कोशिश कर रहा हूँ,

त्रुटि कोड: 1117. बहुत अधिक कॉलम

इस तालिका में मेरे पास केवल 1000 पंक्तियाँ हैं। मेरे लिए सबसे महत्वपूर्ण बात स्तंभों की संख्या है। क्या टेबल पर कोई सीमाएं हैं? मैं 2000 कॉलम बनाना चाहता हूं। क्या यह संभव है?

mysql table

— मज़ेदार
स्रोत

21

अच्छा भगवान, क्या बिल्ली है। यह एक बिल्कुल खराब डेटाबेस डिजाइन की तरह बदबू आ रही है। या शायद आप नौकरी के लिए गलत टूल का इस्तेमाल कर रहे हैं। शायद आपको डेटाबेस के सामान्यीकरण को

— ज़ॉडेचे जूल 20'11

12

अपने मॉनिटर को 90 डिग्री घुमाएँ। अधिक गंभीरता से, MySQL (या लगभग किसी अन्य RDBMS) को कई कॉलमों के लिए डिज़ाइन नहीं किया गया है।

11

और 2000 सेंसर को 2000 कॉलम क्यों ले जाना चाहिए? अपने डेटाबेस को फिर से डिज़ाइन करें। एक अलग सेंसर टेबल या कुछ और बनाएं, लेकिन प्रत्येक सेंसर को एक नए कॉलम के रूप में न जोड़ें। यह सिर्फ अविश्वसनीय रूप से गलत काम है।

6

अधिकतम तालिका संख्या ... वहाँ! आपको संभवतः केवल कुछ तालिकाओं की आवश्यकता होगी। 2000 कॉलम के बजाय 2000 टेबल बनाने पर भी विचार न करें!

2

कृपया, कृपया, कृपया डेटाबेस सामान्यीकरण के बारे में पढ़ें !

35

आपको केवल 20 कॉलमों के साथ तालिका बनाने की आवश्यकता क्यों होगी, अकेले 2000 दें ???

दी गई, विकृत डेटा डेटा के कई स्तंभों को पुनः प्राप्त करने के लिए JOIN करने से रोक सकती है। हालांकि, यदि आपके पास 10 से अधिक कॉलम हैं, तो आपको रोकना चाहिए और सोचना चाहिए कि डेटा पुनर्प्राप्ति के दौरान हुड के नीचे क्या होगा।

यदि 2000 कॉलम की तालिका सेलेक्ट * FROM ... से गुजरती है, तो आप प्रसंस्करण के दौरान बड़े टेम्प टेबल उत्पन्न करेंगे, जो अनावश्यक हैं, और कई परिदृश्य बना रहे हैं जहां संचार पैकेट ( max_allowed_packet ) को हर क्वेरी पर कगार पर धकेल दिया जाएगा।

एक डेवलपर के रूप में अपने पहले के दिनों में, मैंने 1995 में एक कंपनी में काम किया था जहाँ DB2 मुख्य RDBMS था। कंपनी की एक एकल तालिका थी जिसमें 270 कॉलम, दर्जनों सूचकांक थे, और डेटा प्राप्त करने के लिए प्रदर्शन के मुद्दे थे। उन्होंने आईबीएम से संपर्क किया और सलाहकारों को अपने सिस्टम की वास्तुकला पर ध्यान दिया, जिसमें यह एक अखंड तालिका भी शामिल थी। कंपनी को बताया गया था, "यदि आप अगले 2 वर्षों में इस तालिका को सामान्य नहीं करते हैं, तो DB2 स्टेज 2 प्रोसेसिंग (किसी भी गैर-अनुक्रमित स्तंभों पर छंटनी की आवश्यकता वाले प्रश्न) करने वाले प्रश्नों पर विफल हो जाएगा।" यह एक 270 मिलियन तालिका तालिका को सामान्य करने के लिए एक बहु-ट्रिलियन डॉलर कंपनी को बताया गया था। 2000 कॉलम तालिका कितनी अधिक है।

Mysql के संदर्भ में, आपको DB2 Stage2 प्रसंस्करण के लिए विकल्प की स्थापना करके इस तरह के खराब डिजाइन के लिए क्षतिपूर्ति करनी होगी। इस मामले में, वे विकल्प होंगे

दर्जनों की उपस्थिति के लिए इन सेटिंग्स को ट्विकिंग करते हुए, अकेले सैकड़ों कॉलम दें, यदि आपके पास टीबी रैम है।

यह समस्या ज्यामितीय रूप से गुणा करती है यदि आप InnoDB का उपयोग करते हैं जैसा कि आपको MVCC (मल्टीवोर्स कंसीलर कंट्रोल) के साथ सौदा करना होगा ताकि लेनदेन के अलगाव के माध्यम से प्रत्येक SELECT, UPDATE और DELETE के साथ स्तंभों की रक्षा करने की कोशिश की जा सके।

निष्कर्ष

कोई विकल्प या बैंड-सहायता नहीं है जो खराब डिजाइन के लिए बना सकता है। कृपया, भविष्य में अपने विवेक की खातिर, आज उस तालिका को सामान्य करें !!!

— RolandoMySQLDBA
स्रोत

1

मैं कल्पना कर सकता था कि कंपनी यह बताने पर कैसे करेगी। वे svn हुक जोड़ते हैं या "DB सर्वोत्तम अभ्यास दिशानिर्देश" बनाते हैं जो डेवलपर्स को SQL में गैर-अनुक्रमित कॉलम को सॉर्ट नहीं करने के लिए कहते हैं। इसके बजाय, वे अपने स्वयं के बड़े डेटा सॉर्टिंग एल्गोरिदम को लागू करके आवेदन के भीतर छंटाई करते हैं।

— गक्क्बिग

25

मुझे ऐसी किसी भी चीज़ की कल्पना करने में परेशानी हो रही है जहाँ डेटा मॉडल में वैध रूप से सामान्यीकृत तालिका में 2000 कॉलम हो सकते हैं।

मेरा अनुमान है कि आप संभवतः किसी प्रकार के "रिक्त स्थान को भरना" नामांकित स्कीमा कर रहे हैं, जहां आप वास्तव में एक ही तालिका में सभी विभिन्न प्रकार के डेटा को संग्रहीत कर रहे हैं, और इसके बजाय डेटा को अलग-अलग तालिकाओं में तोड़कर संबंध बना रहे हैं। , आपको विभिन्न फ़ील्ड मिले हैं जो रिकॉर्ड करते हैं कि डेटा का "प्रकार" एक दी गई पंक्ति में संग्रहीत है, और आपके 90% फ़ील्ड NULL हैं। फिर भी, हालांकि, 2000 कॉलम ... yikes को प्राप्त करना चाहते हैं।

आपकी समस्या का समाधान आपके डेटा मॉडल पर पुनर्विचार करना है। यदि आप कुंजी / मान डेटा का एक बड़ा ढेर संग्रहीत कर रहे हैं जो किसी दिए गए रिकॉर्ड के साथ जुड़ा हुआ है, तो इसे इस तरह से क्यों नहीं मॉडल करें? कुछ इस तरह:

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

फिर दिए गए "मास्टर" रिकॉर्ड से जुड़े सभी सेंसर प्रविष्टियों को प्राप्त करने के लिए, आप बस कर सकते हैं SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>। यदि आपको masterउस रिकॉर्ड के लिए सभी सेंसर डेटा के साथ तालिका में रिकॉर्ड के लिए डेटा प्राप्त करने की आवश्यकता है , तो आप एक जॉइन का उपयोग कर सकते हैं:

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>

और फिर आगे जुड़ता है यदि आपको प्रत्येक संवेदक के विवरण की आवश्यकता है।

— Womble
स्रोत

18

यह 2000 सेंसर के साथ एक माप प्रणाली है

सामान्यीकरण के बारे में चिल्लाते हुए सभी टिप्पणियों को अनदेखा करें - आप जो पूछ रहे हैं वह समझदार डेटाबेस डिज़ाइन (एक आदर्श दुनिया में) हो सकता है और पूरी तरह से सामान्यीकृत हो सकता है, यह सिर्फ बहुत ही असामान्य है, और जैसा कि कहीं और बताया गया है कि आरडीबीएमएस आमतौर पर कई कॉलमों के लिए डिज़ाइन नहीं किए जाते हैं ।

हालाँकि आप MySQL की हार्ड लिमिट नहीं मार रहे हैं , लेकिन लिंक में बताए गए अन्य कारकों में से एक संभवतः आपको अधिक जाने से रोक रहा है

जैसा कि अन्य लोग सुझाव देते हैं, आप इस सीमा के आसपास काम कर सकते हैं जिसके साथ एक बच्चा टेबल है id, sensor_id, sensor_value, या अधिक बस, आप एक दूसरी तालिका बना सकते हैं जिसमें केवल कॉलम हैं जो पहले फिट नहीं होंगे (और उसी पीके का उपयोग करें)

— जैक डगलस
स्रोत

1

यह सच है। जब डेटा और इसी SQL को बड़ी सावधानी से हैंडल किया जाता है, तो आपका उत्तर और भी अधिक होता है !!!

— RolandoMySQLDBA

3

चाइल्ड टेबल का उपयोग करना "वर्कअराउंड" नहीं है। प्रत्येक सेंसर के लिए एक कॉलम होने से बस खराब (गलत) डिज़ाइन होता है। यह एचआर सिस्टम में प्रत्येक कर्मचारी के लिए एक कॉलम होने या डीबी के लिए प्रत्येक कार निर्माता के लिए एक कॉलम की तरह है जो कार मॉडल का प्रबंधन करता है।

— a_horse_with_no_name

11

@a_horse - आप यह धारणा बना रहे हैं कि मुझे संदेह है कि यह वैध है। यह काफी संभव है कि सेंसर की संख्या मूल रूप से तय हो, कि सभी एक साथ पढ़े जाते हैं और सभी हर बार डेटा वापस करते हैं। जिस स्थिति में प्रति सेंसर एक कॉलम "गलत" नहीं है, केवल डेटाबेस की सीमाओं को देखते हुए अव्यावहारिक है। मुझे यह पसंद है कि प्रश्नकर्ता तब तक बेवकूफ नहीं हैं जब तक कि साबित न हो और iUngi ने एसएफ की भीड़ से बहुत ही बेकार प्रतिक्रियाओं के चेहरे पर गरिमा के साथ जवाब दिया हो।

— जैक डगलस

2

@ जेक डगलस: भले ही आपकी सभी धारणाएं सच थीं (जो मुझे अत्यधिक संदेह है) प्रत्येक संवेदक को अपने कॉलम में संग्रहीत करने से लंबे समय में परेशानी होगी। "कल और आज के बीच सेंसर 10 से 50 और 25 से 100 के लिए औसत मूल्य क्या है" जैसे प्रश्नों के बारे में? या "किस संवेदक के पास पिछले सोमवार को उच्चतम पठन मूल्य था?"। इसके लिए 2000 कॉलम के साथ क्वेरी लिखने का प्रयास करें। सामान्यीकृत तालिका का उपयोग करने से लंबे समय में 2000 से अधिक समस्याएँ हल हो जाएंगी जिनका समाधान अब होगा।

— a_horse_with_no_name

2

ज़रूर, अगर सेंसर संबंधित मूल्यों को संग्रहीत कर रहे हैं - मैं मान रहा हूं कि वे असंबंधित हैं (उदाहरण के लिए, वे मूल रूप से अलग-अलग स्थानों पर एक ही चीज के बजाय विभिन्न प्रकार की चीजों को माप रहे हैं)। आपको संदेह हो सकता है कि लेकिन केवल ओपी को ही पता है - और यह चिकित्सा या वैज्ञानिक क्षेत्रों में असंभव नहीं है।

— जैक डगलस

15

MySQL 5.0 कॉलम-गणना सीमाएँ (जोर दिया गया):

प्रति तालिका 4096 स्तंभों की एक कठिन सीमा है , लेकिन किसी तालिका के लिए प्रभावी अधिकतम कम हो सकता है। सटीक सीमा कई अंतःक्रियात्मक कारकों पर निर्भर करती है।

प्रत्येक तालिका (भंडारण इंजन की परवाह किए बिना) में अधिकतम पंक्ति का आकार 65,535 बाइट्स होता है। संग्रहण इंजन इस सीमा पर अतिरिक्त अवरोध लगा सकते हैं, जिससे प्रभावी अधिकतम पंक्ति आकार कम हो जाता है।

अधिकतम पंक्ति आकार स्तंभों की संख्या (और संभवतः आकार) को संकुचित करता है क्योंकि सभी स्तंभों की कुल लंबाई इस आकार से अधिक नहीं हो सकती।

...

व्यक्तिगत भंडारण इंजन अतिरिक्त प्रतिबंध लगा सकते हैं जो टेबल कॉलम की गिनती को सीमित करते हैं। उदाहरण:

InnoDB 1000 कॉलम तक की अनुमति देता है।

— lg_
स्रोत

7

पहले कुछ और ज्वलंत, फिर एक वास्तविक समाधान ...

मैं ज्यादातर आप पर पहले से ही लपटों से सहमत हूँ।

मैं कुंजी-मूल्य सामान्यीकरण से असहमत हूं। प्रश्न भयानक होते हुए समाप्त होते हैं; प्रदर्शन और भी खराब।

तात्कालिक समस्या (स्तंभों की संख्या की सीमा) से बचने का एक 'सरल' तरीका डेटा को 'लंबवत विभाजन' करना है। कहते हैं, प्रत्येक 400 स्तंभों के साथ 5 तालिकाओं। वे सभी एक ही प्राथमिक कुंजी है, एक को छोड़कर यह AUTO_INCREMENT हो सकता है।

शायद बेहतर होगा कि उन दर्जनों क्षेत्रों पर फैसला किया जाए जो सबसे महत्वपूर्ण हैं, उन्हें 'मुख्य' तालिका में डालें। फिर सेंसर को कुछ तार्किक तरीके से समूहित करें और उन्हें कई समानांतर तालिकाओं में डालें। समुचित समूहीकरण के साथ, आपको हर समय सभी तालिकाओं को शामिल नहीं करना पड़ सकता है।

क्या आप किसी भी मूल्य को अनुक्रमित कर रहे हैं? क्या आपको उन पर खोज करने की आवश्यकता है? शायद आप डेटाइम पर खोजते हैं?

यदि आपको बहुत सारे स्तंभों को अनुक्रमित करने की आवश्यकता है - पंट।

यदि आपको कुछ अनुक्रमित करने की आवश्यकता है - उन्हें 'मुख्य तालिका में डालें।

यहां जानिए असली उपाय (अगर यह लागू होता है) ...

यदि आपको अनुक्रमित सेंसर के विशाल सरणी की आवश्यकता नहीं है, तो कॉलम न बनाएं! हां, आपने मुझे सुना। इसके बजाय, उन्हें JSON में इकट्ठा करें, JSON को संपीड़ित करें, इसे BLOB फ़ील्ड में संग्रहीत करें। आप एक टन स्थान बचाएंगे; आपके पास केवल एक तालिका होगी, जिसमें स्तंभ सीमा समस्याएं नहीं होंगी; आदि। आपका आवेदन अनसुना कर देगा, और फिर एक संरचना के रूप में JSON का उपयोग करेगा। अंदाज़ा लगाओ? आपके पास संरचना हो सकती है - आप सेंसर को सरणियों, बहुस्तरीय सामान, आदि में समूह कर सकते हैं, जैसे आपका ऐप पसंद करेगा। एक और 'फीचर' - यह ओपन-एंडेड है। यदि आप अधिक सेंसर जोड़ते हैं, तो आपको तालिका को बदलने की आवश्यकता नहीं है। JSON अगर इस तरह से लचीला है।

(संपीड़न वैकल्पिक है, यदि आपका डेटासेट विशाल है, तो यह डिस्क स्थान के साथ मदद करेगा, इसलिए समग्र प्रदर्शन।)

— रिक जेम्स
स्रोत

यह वास्तविक सबसे अच्छा जवाब है। यह टिप्पणी करना ठीक है कि हो सकता है कि वह कई स्तंभों पर शोध न करे, लेकिन स्वीकृत उत्तर के लिए 'ऐसा न करें' प्रश्न का उत्तर नहीं देता है। यहां तक कि अगर इस आदमी को वास्तव में कई स्तंभों की आवश्यकता नहीं है, तो शायद किसी और को यह क्यू ढूंढने के लिए उस कई की आवश्यकता है, और एक वास्तविक उत्तर की आवश्यकता है।

— BoB3K

@ BoB3K - मेरा बड़ा पैराग्राफ कहता है कि क्या करना है , समस्या के बारे में उपलब्ध जानकारी बताई गई है। JSON"बहुत अधिक कॉलम" से बचा जाता है; चयनित कॉलमों को अनुक्रमित करने से प्रदर्शन में मदद मिलती है।

— रिक जेम्स

3

मैं इसे बड़े डेटा की दुनिया में एक संभावित परिदृश्य के रूप में देखता हूं, जहां आप पारंपरिक चयन * प्रकार के प्रश्नों का प्रदर्शन नहीं कर रहे हैं। हम ग्राहक के स्तर पर भविष्य कहे जाने वाले मॉडलिंग की दुनिया में इससे निपटते हैं, जहाँ हम हजारों आयामों में एक ग्राहक का निर्माण करते हैं (उन सभी में 0 या 1 का मान होता है)। स्टोरेज का यह तरीका डाउनस्ट्रीम मॉडल बिल्डिंग गतिविधियों आदि को आसान बनाता है जब आपके पास एक ही पंक्ति में जोखिम कारक हों और एक ही पंक्ति में परिणाम ध्वज हो। यह एक पेरेंट चाइल्ड संरचना के साथ स्टोरेज स्टैंड पॉइंट से सामान्य किया जा सकता है, लेकिन भविष्य कहनेवाला मॉडल डाउनस्ट्रीम को वापस फ्लैट स्कीमा में परिवर्तित करने की आवश्यकता होगी। हम रेडशिफ्ट का उपयोग करते हैं जो स्तंभ भंडारण करता है, इसलिए जब आप डेटा लोड करते हैं तो आपके 1000+ कॉलम, वास्तव में स्तंभ स्तंभ में संग्रहीत किए जाते हैं ...

इस डिजाइन के लिए एक समय और स्थान है। पूर्ण रूप से। सामान्यीकरण हर समस्या का हल नहीं है।

— BigDataGuy
स्रोत

टिप्पणी के लिए धन्यवाद। यदि कोई छवियों के साथ एनालिटिक्स करना चाहता है, तो भी 16x16 पिक्सल की थोड़ी रंग छवि के लिए 0 और 255 के बीच 16 * 16 * 3 पूर्णांकों की आवश्यकता होती है (आरजीबी रंगों का उपयोग करके 16x16 पिक्सल में से एक में रंग का वर्णन करने के लिए 3 नंबर)। यह सिर्फ डेटा के लिए 768 कॉलम है, जिसमें एक कुंजी जोड़ने की आवश्यकता होगी।

— विक्टरज़ुरकोव्स्की