ये रहा सवाल ...
192 ट्रिलियन रिकॉर्ड को ध्यान में रखते हुए, मेरे विचार क्या होने चाहिए?
मेरी मुख्य चिंता गति है।
यहाँ तालिका है ...
CREATE TABLE `ref` (
`id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
`rel_id` INTEGER(13) NOT NULL,
`p1` INTEGER(13) NOT NULL,
`p2` INTEGER(13) DEFAULT NULL,
`p3` INTEGER(13) DEFAULT NULL,
`s` INTEGER(13) NOT NULL,
`p4` INTEGER(13) DEFAULT NULL,
`p5` INTEGER(13) DEFAULT NULL,
`p6` INTEGER(13) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY (`s`),
KEY (`rel_id`),
KEY (`p3`),
KEY (`p4`)
);
ये रहा सवाल ...
SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"
SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"
INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")
यहां देखें कुछ नोट ...
- चयन का INSERT की तुलना में अधिक बार किया जाएगा। हालांकि, कभी-कभी मैं एक बार में कुछ सौ रिकॉर्ड जोड़ना चाहता हूं।
- लोड-वार, कुछ घंटों के लिए कुछ भी नहीं होगा, तो शायद कुछ हजार प्रश्न एक ही बार में।
- मुझे नहीं लगता कि मैं किसी भी अधिक को सामान्य कर सकता हूं (संयोजन में p मान की आवश्यकता है)
- एक पूरे के रूप में डेटाबेस बहुत ही संबंधपरक है।
- यह अब तक की सबसे बड़ी तालिका होगी (अगली सबसे बड़ी लगभग 900k है)
अद्यतन (08/11/2010)
दिलचस्प है, मुझे एक दूसरा विकल्प दिया गया है ...
192 ट्रिलियन के बजाय मैं 2.6 * 10 ^ 16 (15 शून्य, 26 क्वाड्रिलियन) स्टोर कर सकता था ...
लेकिन इस दूसरे विकल्प में मुझे केवल एक बिंदी (18) को एक तालिका में सूचकांक के रूप में संग्रहीत करने की आवश्यकता होगी। वह यह है - सिर्फ एक कॉलम। तो मैं सिर्फ एक मूल्य के अस्तित्व के लिए जाँच कर रहा हूँ। कभी-कभी रिकॉर्ड जोड़ते हैं, कभी उन्हें हटा नहीं रहे हैं।
ताकि मुझे लगता है कि वहाँ एक बेहतर समाधान होना चाहिए तो mysql बस संख्या संचय के लिए ...
इस दूसरे विकल्प को देखते हुए, मुझे इसे लेना चाहिए या पहले के साथ रहना चाहिए ...
[संपादित करें] बस कुछ परीक्षण की खबर मिली है - इस सेटअप के साथ १०० मिलियन पंक्तियों में क्वेरी ०.०००४ सेकंड में वापस आती है [/ संपादित करें]