मैं क्लेनेपेट और ब्रायन से सहमत हूं - कुछ चेतावनियों के साथ।
यदि आपका डेटा स्वाभाविक रूप से संबंधपरक है, और उन प्रश्नों के अधीन है जो SQL के साथ अच्छी तरह से काम करते हैं, तो आपको विदेशी हार्डवेयर आवश्यकताओं के बिना सैकड़ों मिलियन रिकॉर्ड तक स्केल करने में सक्षम होना चाहिए।
आपको गति के हित में इंडेक्सिंग, क्वेरी ट्यूनिंग और रिलेशनल मॉडल के लिए सामयिक बलिदान करने में निवेश करने की आवश्यकता होगी। तालिकाओं को डिजाइन करते समय आपको कम से कम प्रदर्शन के लिए मंजूरी देनी चाहिए - उदाहरण के लिए, चाबियों के लिए पूर्णांकों को प्राथमिकता देना।
यदि, हालांकि, आपकी दस्तावेज़-केंद्रित आवश्यकताएं हैं, मुफ्त टेक्स्ट खोज की आवश्यकता है, या बहुत सारे पदानुक्रमित संबंध हैं, तो आपको फिर से देखने की आवश्यकता हो सकती है।
यदि आपको ACID लेन-देन की आवश्यकता है, तो आप लेन-देन की परवाह न करने की तुलना में पहले मापनीयता के मुद्दों में भाग सकते हैं (हालाँकि यह अभी भी व्यवहार में आपको प्रभावित करने की संभावना नहीं है); यदि आपके पास लंबे समय से चल रहे या जटिल लेनदेन हैं, तो आपकी मापनीयता काफी तेजी से घटती है।
मैं स्केलेबिलिटी आवश्यकताओं को ध्यान में रखते हुए प्रोजेक्ट को जमीन से ऊपर बनाने की सलाह दूंगा। मैंने अतीत में जो किया है वह लाखों रिकॉर्ड के साथ आबादी वाला एक परीक्षण वातावरण स्थापित किया गया है (मैंने डीबीमोनस्टर का उपयोग किया है, लेकिन यह सुनिश्चित नहीं है कि यह अभी भी आसपास है), और लोड परीक्षण उपकरण का उपयोग करके इस डेटाबेस के खिलाफ नियमित रूप से कार्य-प्रगति कोड का परीक्षण करें। जेमीटर।
