इस प्रश्न का उत्तर देने के लिए, हमें पहले वास्तविक . का विश्लेषण करना होगा आप जिस समस्या का सामना कर रहे हैं।
वास्तविक मुद्दा डेटा लिखने और पुनर्प्राप्त करने का सबसे कुशल संयोजन होगा।
आइए आपके निष्कर्षों की समीक्षा करें:
-
हजारों टेबल - ठीक है, यह डेटाबेस के उद्देश्य का उल्लंघन करता है और इसके साथ काम करना कठिन बनाता है। आपको भी कुछ नहीं मिलता। डिस्क की मांग अभी भी शामिल है, इस बार उपयोग में कई फाइल डिस्क्रिप्टर के साथ। आपको तालिका के नाम भी जानने होंगे, और उनमें से हजारों हैं। डेटा को निकालना भी मुश्किल है, जो कि डेटाबेस के लिए है - डेटा को इस तरह से संरचित करने के लिए कि आप रिकॉर्ड को आसानी से क्रॉस-रेफरेंस कर सकें। हजारों टेबल - पूर्ण से कुशल नहीं। दृष्टिकोण। उपयोग की दृष्टि से कुशल नहीं है। खराब विकल्प।
-
एक csv फ़ाइल - यदि आपको एक ही बार में संपूर्ण सामग्री की आवश्यकता है, तो डेटा लाने के लिए यह संभवतः उत्कृष्ट है। लेकिन यह डेटा में हेरफेर या बदलने के लिए दूर से अच्छा नहीं है। इस तथ्य को देखते हुए कि आप एक विशिष्ट लेआउट पर भरोसा करते हैं - सीएसवी को लिखते समय आपको अतिरिक्त सावधानी बरतनी होगी। यदि यह हजारों CSV फ़ाइलों तक बढ़ता है, तो आपने स्वयं पर कोई एहसान नहीं किया। आपने SQL के सभी ओवरहेड को हटा दिया (जो इतना बड़ा नहीं है) लेकिन आपने डेटा सेट के कुछ हिस्सों को पुनः प्राप्त करने के लिए कुछ नहीं किया। आपको ऐतिहासिक डेटा लाने या किसी भी चीज़ को क्रॉस रेफ़रेंस करने में भी समस्याएँ आती हैं। खराब विकल्प।
आदर्श परिदृश्य डेटा सेट के किसी भी हिस्से को किसी भी प्रकार की संरचना परिवर्तन के बिना एक कुशल और त्वरित तरीके से एक्सेस करने में सक्षम होगा।
और ठीक यही कारण है कि हम रिलेशनल डेटाबेस का उपयोग क्यों करते हैं और क्यों हम उन डेटाबेस के लिए बहुत सारे RAM वाले पूरे सर्वर को समर्पित करते हैं।
आपके मामले में, आप MyISAM टेबल (.MYD फ़ाइल एक्सटेंशन) का उपयोग कर रहे हैं। यह एक पुराना स्टोरेज फॉर्मेट है जो लो एंड हार्डवेयर के लिए बहुत अच्छा काम करता है जिसका इस्तेमाल दिन में किया जाता था। लेकिन इन दिनों हमारे पास बेहतरीन और तेज कंप्यूटर हैं। इसलिए हम InnoDB का उपयोग करते हैं और इसे बहुत अधिक RAM का उपयोग करने की अनुमति देते हैं ताकि I/O लागत कम हो। विचाराधीन चर जो इसे नियंत्रित करता है उसे innodb_buffer_pool_size . कहा जाता है - गूगलिंग जो सार्थक परिणाम देगा।
प्रश्न का उत्तर देने के लिए - एक कुशल, संतोषजनक समाधान एक तालिका का उपयोग करना होगा जहां आप सेंसर जानकारी (आईडी, शीर्षक, विवरण) और दूसरी तालिका संग्रहीत करते हैं जहां आप सेंसर रीडिंग संग्रहीत करते हैं। आप पर्याप्त RAM या पर्याप्त तेज़ संग्रहण (एक SSD) आवंटित करते हैं। टेबल इस तरह दिखेगी:
CREATE TABLE sensors (
id int unsigned not null auto_increment,
sensor_title varchar(255) not null,
description varchar(255) not null,
date_created datetime,
PRIMARY KEY(id)
) ENGINE = InnoDB DEFAULT CHARSET = UTF8;
CREATE TABLE sensor_readings (
id int unsigned not null auto_increment,
sensor_id int unsigned not null,
date_created datetime,
reading_value varchar(255), -- note: this column's value might vary, I do not know what data type you need to hold value(s)
PRIMARY KEY(id),
FOREIGN KEY (sensor_id) REFERENCES sensors (id) ON DELETE CASCADE
) ENGINE = InnoDB DEFAULT CHARSET = UTF8;
InnoDB, डिफ़ॉल्ट रूप से, संपूर्ण डेटाबेस/इंस्टॉलेशन के लिए एक फ़्लैट-फ़ाइल का उपयोग करता है। यह ओएस/फाइल सिस्टम की फाइल डिस्क्रिप्टर सीमा को पार करने की समस्या को कम करता है। यदि आप मेमोरी में सेट किए गए डेटा को होल्ड करने के लिए 5-6 गीगा रैम आवंटित करते हैं तो कई, या यहां तक कि लाखों रिकॉर्ड कोई समस्या नहीं होनी चाहिए - जो आपको डेटा तक त्वरित पहुंच की अनुमति देगा।
अगर मैं इस तरह की प्रणाली को डिजाइन करता, तो यह पहला तरीका होता जो मैं (व्यक्तिगत रूप से) करता। वहां से आपको उस जानकारी के साथ क्या करना है, इसके आधार पर इसे समायोजित करना आसान है।
