SQL सर्वर: तालिका में पंक्तियों की अधिकतम संख्या [बंद]

Question

मैं ऐसे सॉफ़्टवेयर का विकास करता हूं जो अपने डेटाबेस तालिकाओं (SQL सर्वर संस्करण 8, 9 या 10) में बहुत अधिक डेटा संग्रहीत करता है। मान लीजिए, प्रति दिन लगभग 100,000 रिकॉर्ड्स को उस तालिका में डाला जाता है। यह प्रति वर्ष लगभग 36 मिलियन रिकॉर्ड है। इस डर के लिए कि मैं प्रदर्शन पर हार जाऊंगा, मैंने प्रति तालिका रिकॉर्ड की संख्या कम करने के लिए हर रोज एक नई तालिका (वर्तमान नाम के साथ एक तालिका) बनाने का फैसला किया।

क्या आप मुझे बता सकते हैं, क्या यह एक अच्छा विचार था? SQL सर्वर तालिकाओं के लिए कोई रिकॉर्ड सीमा है? या क्या आप जानते हैं कि प्रदर्शन को काफी कम करने से पहले कितने रिकॉर्ड (कम या ज्यादा) संग्रहीत किए जा सकते हैं?

Comments

"प्रोग्रामर अपने कार्यक्रमों के गैर-राजनीतिक हिस्सों की गति के बारे में सोचने, या चिंता करने में बहुत समय बर्बाद करते हैं, और दक्षता पर इन प्रयासों का वास्तव में एक मजबूत नकारात्मक प्रभाव पड़ता है जब डिबगिंग और रखरखाव पर विचार किया जाता है। हमें छोटी क्षमताओं के बारे में भूलना चाहिए। समय का 97%: समय से पहले अनुकूलन सभी बुराई की जड़ है। फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसरों को पारित नहीं करना चाहिए। " नुथ 1974

— मैथ्यू लॉक

Answer 1

इस पर एक सामान्य उत्तर देना कठिन है। यह वास्तव में कारकों की संख्या पर निर्भर करता है:

• आपकी पंक्ति का आकार क्या है
• आप किस तरह का डेटा स्टोर करते हैं (स्ट्रिंग्स, ब्लब्स, नंबर)
• आप अपने डेटा के साथ क्या करते हैं (बस इसे संग्रह के रूप में रखें, इसे नियमित रूप से क्वेरी करें)
• क्या आप अपनी मेज पर अनुक्रमित हैं - कितने
• आपका सर्वर चश्मा क्या है

आदि।

जैसा कि यहाँ कहीं और उत्तर दिया गया है, प्रति दिन 100,000 और इस प्रकार प्रति तालिका ओवरकिल है - मैं मासिक या साप्ताहिक सुझाव दूंगा कि शायद तिमाही भी। आपके पास जितना बड़ा टेबल / रखरखाव दुःस्वप्न होगा, उतने अधिक टेबल होंगे।

Comments

मैं "बड़े रखरखाव / क्वेरी दुःस्वप्न" को फिर से लागू करना चाहता हूं - व्यक्तिगत अनुभव से मैं प्लेग की तरह तालिकाओं में विभाजित होने से बचूंगा।

— डैनियल जेम्स ब्रायर्स

Answer 2

ये SQL Server 2008 R2 के लिए अधिकतम क्षमता विनिर्देशों में से कुछ हैं

• डेटाबेस का आकार: 524,272 टेराबाइट्स
• SQL सर्वर के प्रति डेटाबेस डेटाबेस: 32,767
• डेटाबेस प्रति फ़ाइल समूह: 32,767
• प्रति डेटाबेस फ़ाइलें: 32,767
• फ़ाइल का आकार (डेटा): 16 टेराबाइट्स
• फ़ाइल का आकार (लॉग): 2 टेराबाइट्स
• प्रति तालिका पंक्तियाँ: उपलब्ध संग्रहण द्वारा सीमित
• प्रति डेटाबेस टेबल्स: एक डेटाबेस में वस्तुओं की संख्या द्वारा सीमित

Comments

मुझे संदेह होगा कि यदि आपके पास 9,223,372,036,854,775,807 पंक्तियाँ हैं, तो आप समस्याओं में चलेंगे (अधिकतम आकार की bigint)

— मार्टिन स्मिथ

क्या आपने कभी ओपी के उल्लेखित 100000 पंक्तियों / दिन में उस पंक्ति की गणना में लगने वाले वर्षों की संख्या की गणना की है?

— Erwin Smout

आलसी के लिए यह पोस्टिंग: 252,695,124 साल।

— NotMe

@NotMe पुनर्जीवित और नाइटपिक नहीं, लेकिन मुझे 252695124297 साल मिले। (कभी-कभी मेरी इच्छा है कि मैं आपके द्वारा संदर्भित आलसी आबादी का था)

— philthyfool

@philthyfool लीप ईयर के लिए एक दिन बहुत बड़ा अंतर है। मुझे 252,522,163,911 मिलते हैं। इसके अलावा, ये मेरे जीवन के पूरी तरह से अच्छे मिनट थे जिन्हें मैं अब वापस नहीं ले सकता।

— सुमेरे

Answer 3

मेरे पास SQL ​​Server 2008 R2 में सिर्फ 6 बिलियन पंक्तियों के साथ एक तीन स्तंभ तालिका है।

हम अपने ग्राहकों के लिए मिनट-दर-मिनट सिस्टम विश्लेषण चार्ट बनाने के लिए हर दिन इसकी क्वेरी करते हैं। मैंने किसी डेटाबेस प्रदर्शन हिट्स पर ध्यान नहीं दिया है (हालांकि यह तथ्य कि यह बढ़ता है ~ 1 जीबी हर दिन बैकअप को थोड़ा अधिक शामिल करता है जितना मैं चाहूंगा)।

जुलाई 2016 को अपडेट करें

हमने इसे ~ 24.5 बिलियन पंक्तियों में बना दिया था, इससे पहले कि बैकअप दो साल से अधिक पुराना हो जाए (महंगे टेपों सहित, कई बैकअपों में संग्रहीत ~ 700 जीबी) को रिकॉर्ड करने का फैसला करने से पहले हमने इसे 24.5 बिलियन पंक्तियों में बदल दिया। यह ध्यान देने योग्य है कि इस निर्णय में प्रदर्शन एक महत्वपूर्ण प्रेरक नहीं था (यानी, यह अभी भी बहुत अच्छा काम कर रहा था)।

जो कोई भी खुद को SQL सर्वर से 20 बिलियन पंक्तियों को हटाने का प्रयास करता है, मैं इस लेख की अत्यधिक अनुशंसा करता हूं । लिंक मर जाने की स्थिति में प्रासंगिक कोड (पूर्ण विवरण के लिए लेख पढ़ें):

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

अपडेट नवंबर 2016

यदि आप एक ही तालिका में इस डेटा को संग्रहीत करने की योजना बनाते हैं: नहीं। मैं अत्यधिक अनुशंसा करता हूं कि आप तालिका विभाजन पर विचार करें (यदि आप एंटरप्राइज़ संस्करण चला रहे हैं तो मैन्युअल रूप से या अंतर्निहित सुविधाओं के साथ)। यह पुराने डेटा को एक बार (सप्ताह / माह / इत्यादि) के रूप में तालिका को छोटा करने में आसान बनाता है। यदि आपके पास एंटरप्राइज नहीं है (जो हम नहीं देते हैं), तो आप बस एक स्क्रिप्ट लिख सकते हैं जो महीने में एक बार चलती है, 2 साल से अधिक पुरानी टेबल छोड़ती है, अगले महीने की तालिका बनाती है, और एक डायनेमिक दृश्य को पुन: बनाता है जो सभी विभाजन में शामिल होता है आसान क्वेरी के लिए एक साथ तालिकाओं। स्पष्ट रूप से "महीने में एक बार" और "2 वर्ष से अधिक पुराने" को आपके द्वारा उपयोग किए जाने वाले मामले के आधार पर परिभाषित किया जाना चाहिए।

Comments

10.5 बिलियन तक, फिर भी चौका। बस COUNT को निष्पादित करने का प्रयास न करें ()। ;)

— डैन बेहार्ड

एक साल हो गया है, हम 16.5 बिलियन पंक्तियों में हैं। हमने अभी एक अतिरिक्त डेटा स्रोत जोड़ा है, इसलिए यह अब थोड़ा तेज़ी से बढ़ रहा है। हमने सर्वर पर अन्य डेटाबेस को भूखे बिना मेमोरी समर्पित करने की अनुमति देने के लिए इस डेटाबेस को अपनी स्वयं की SQL आवृत्ति पर भी स्थानांतरित कर दिया है। मैं अभी भी पिछले 3 वर्षों में किसी भी 24 घंटे की अवधि में किसी भी डेटा बिंदु को एक सेकंड से कम समय में चार्ट करने में सक्षम हूं। हमारे विश्लेषक इसे पसंद करते हैं।

— दान बेखर

मुझे पता है कि यह एक समय हो गया है, लेकिन क्या आप मुझे बता सकते हैं कि आप इस डेटाबेस को किस तरह का हार्डवेयर चला रहे हैं? बहुत उत्सुक होने के बाद से हमारे पास 5 बिलियन पंक्तियों की एक तालिका है, जो प्रति वर्ष 1 बिलियन बढ़ती है, और ik यह पता लगाना चाहेगी कि क्या यह भविष्य में समस्याग्रस्त होने लगा है

— Jeroen1984

@ Jeroen1984 यह एक वर्चुअल मशीन है जो दो इंटेल (R) Xeon (R) CPU E5-2430 प्रोसेसर के साथ एक हाइपर- V होस्ट प्रोलेंट DL360e Gen8 पर चल रही है। VM के पास 38GB स्टेटिक रूप से आवंटित रैम है, और कुछ संख्या में वर्चुअल प्रोसेसर हैं जो मुझे याद नहीं हैं।

— डैन बीकार्ड

Answer 4

मुझे एक पंक्ति सीमा का पता नहीं है, लेकिन मैं 170 मिलियन से अधिक पंक्तियों वाली तालिका जानता हूं। आप इसे विभाजित तालिकाओं (2005+) या कई तालिकाओं को जोड़ने वाले विचारों का उपयोग करके गति कर सकते हैं।

Answer 5

मैं विशेष रूप से MSSQL नहीं जानता, लेकिन 36 मिलियन पंक्तियाँ एंटरप्राइज़ डेटाबेस के लिए बड़ी नहीं हैं - मेनफ़्रेम डेटाबेस के साथ काम करते हुए, 100,000 पंक्तियाँ मेरे लिए एक कॉन्फ़िगरेशन तालिका की तरह लगती हैं :-)।

जबकि मैं कुछ का बहुत बड़ा प्रशंसक नहीं हूं Microsoft के सॉफ़्टवेयर का , तो यह एक्सेस नहीं है जिसके बारे में हम यहां बात कर रहे हैं: मुझे लगता है कि वे अपने उद्यम DBMS के साथ बहुत अधिक डेटाबेस आकार संभाल सकते हैं।

मुझे संदेह है कि दिन इसे ठीक से विभाजित करने का एक संकल्प हो सकता है, अगर वास्तव में इसे विभाजित करने की आवश्यकता है।

Answer 6

हमारे पास SQL ​​Server 2005 और 2008 में 1 बिलियन से अधिक पंक्तियाँ हैं (30 मिलियन प्रतिदिन जोड़े गए)। मैं चूहों के घोंसले को विभाजित करने की कल्पना नहीं कर सकता जो हर दिन एक नई तालिका में निकलता है।

उपयुक्त डिस्क स्थान (जो आपको किसी भी तरह की आवश्यकता है) और रैम को जोड़ने के लिए बहुत सस्ता है।

Answer 7

यह निर्भर करता है, लेकिन मैं कहूंगा कि सादगी की खातिर सब कुछ एक मेज पर रखना बेहतर है।

एक दिन में 100,000 पंक्तियाँ वास्तव में बहुत अधिक मात्रा में नहीं होती हैं। (आपके सर्वर हार्डवेयर पर निर्भर करता है)। मैंने व्यक्तिगत रूप से MSSQL को एक ही टेबल में 100M पंक्तियों तक बिना किसी समस्या के हैंडल किया है। जब तक आपका अनुक्रम आपके अनुक्रम को बनाए रखता है तब तक यह सब अच्छा होना चाहिए। कुंजी को ढेर करना है मेमोरी के होने के लिए है ताकि इंडेक्स को डिस्क से स्वैप न करना पड़े।

दूसरी ओर, यह इस बात पर निर्भर करता है कि आप डेटा का उपयोग कैसे कर रहे हैं, अगर आपको बहुत सारे क्वेरी करने की आवश्यकता है, और इसके असंभावित डेटा की आवश्यकता होगी जो कई दिनों तक फैलता है (इसलिए आपको तालिकाओं में शामिल होने की आवश्यकता नहीं होगी) तेजी से इसे कई तालिकाओं में अलग करना। यह अक्सर औद्योगिक प्रक्रिया नियंत्रण जैसे अनुप्रयोगों में उपयोग किया जाता है जहां आप हर 10 सेकंड में 50,000 इंस्ट्रूमेंट पर मूल्य पढ़ सकते हैं। इस मामले में गति बेहद महत्वपूर्ण है, लेकिन सरलता नहीं है।

Answer 8

हमने एक बार एक पूर्णांक प्राथमिक कुंजी को ओवरफ्लो किया (जो कि ~ 2.4 बिलियन पंक्तियाँ हैं) एक मेज पर। यदि कोई पंक्ति सीमा है, तो आप इसे कभी भी प्रति वर्ष 36 मिलियन पंक्तियों पर हिट करने की संभावना नहीं रखते हैं।

Answer 9

जब तक आपके पास पर्याप्त डिस्क स्थान नहीं है तब तक आप तालिका को आबाद कर सकते हैं। बेहतर प्रदर्शन के लिए आप SQL Server 2005 में माइग्रेशन का प्रयास कर सकते हैं और फिर टेबल को विभाजित कर सकते हैं और अलग-अलग डिस्क पर पार्ट्स डाल सकते हैं (यदि आपके पास RAID कॉन्फ़िगरेशन है जो वास्तव में आपकी मदद कर सकता है)। विभाजन केवल SQL Server 2005 के एंटरप्राइज़ संस्करण में संभव है। आप इस लिंक पर विभाजन उदाहरण देख सकते हैं: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

इसके अलावा, आप अधिकांश उपयोग किए गए डेटा भाग के लिए विचार बनाने की कोशिश कर सकते हैं, वह भी समाधानों में से एक है।

उम्मीद है कि यह मदद की ...

Answer 10

Windows2003 पर SQL Server 8 पर सबसे बड़ी तालिका मैंने 5 कॉलम के साथ 799 मिलियन की थी। लेकिन यह अच्छा है या नहीं यह SLA और उपयोग के मामले के खिलाफ मापा जाना है - जैसे कि 50-100,000,000 रिकॉर्ड लोड करें और देखें कि क्या यह अभी भी काम करता है।

Comments

यकीन नहीं है कि यह वास्तव में एक जवाब है।

— एंड्रयू बार्बर

Answer 11

SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows, 
  CAST( 
    CASE max(sysindexes.[rows]) 
      WHEN 0 THEN -0 
      ELSE LOG10(max(sysindexes.[rows])) 
    END 
    AS NUMERIC(5,2)) 
  AS L10_TableRows 
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id] 
WHERE sysobjects.xtype = 'U' 
GROUP BY sysobjects.[name] 
ORDER BY max(rows) DESC

Comments

मैंने यह क्वेरी चलाई और यह परिणाम मिला। मेरे डेटाबेस में UrlCategories टेबल है। तो इस परिणाम का क्या मतलब है? नाम टेबलरोज़ L10_TableRows UrlCategories 7 0.85

— आदित्य बोकाडे

Answer 12

तालिका को मासिक रूप से विभाजित करें। बड़े दैनिक प्रवाह के साथ तालिकाओं को संभालने का सबसे अच्छा तरीका है, यह oracle या MSSQL हो।

Comments

निश्चित नहीं है कि यह पूछे गए विशिष्ट प्रश्न का उत्तर कैसे है।

— एंड्रयू बार्बर