भंडारण खरीदते समय, आमतौर पर मीडिया पर जोर दिया जाता है, लेकिन पहुंच के तरीकों पर भी विचार करना और भी महत्वपूर्ण हो सकता है। बुनियादी ढांचे को डिजाइन और खरीदते समय आपको स्टोरेज प्रोटोकॉल को ध्यान में रखना होगा, खासकर जब आप क्लाउड-नेटिव ऑब्जेक्ट स्टोरेज में माइग्रेट करने के लिए विरासत स्टोरेज को पीछे छोड़ देते हैं। हालाँकि, ऑब्जेक्ट स्टोरेज संचार के लिए S3 API पर निर्भर करता है, जबकि लीगेसी वर्कलोड POSIX पर निर्भर करता है, पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस जो 1980 के दशक में विकसित मानकों का एक सेट प्रदान करता है ताकि अनुप्रयोगों को यूनिक्स ओएस के बीच पोर्टेबल बनाया जा सके। संभावना है कि अधिकांश उद्यमों के पास दशकों से सेवा में ऐसे एप्लिकेशन हैं जिन्हें POSIX पर चलाने के लिए विकसित किया गया था। संभावना यह भी है कि इंजीनियरों को POSIX के खराब प्रदर्शन के बारे में पहले से ही पता है।
ऐसा कहा जा रहा है, जब आपके पास विरासत प्रणाली होती है जो केवल एक निश्चित प्रारूप में या एक निश्चित स्रोत से डेटा ग्रहण कर सकती है, तो आपके विकल्प सीमित हो सकते हैं और आपके पास पुराने प्रोटोकॉल को लागू करने या अपने कोड को फिर से लिखने के अलावा कोई विकल्प नहीं हो सकता है। उदाहरण के लिए, यदि आप केवल फ़ाइल सिस्टम के साथ स्थानीय डिस्क से अंतर्ग्रहण कर सकते हैं और नेटवर्क पर एक्सेस किए गए RESTful API के साथ नहीं, तो आपको पहले उस डेटा को डिस्क पर उपलब्ध कराना होगा, इससे पहले कि आपका एप्लिकेशन इसका उपयोग कर सके। हालाँकि, जब प्रदर्शन, अनुकूलता, डेटा अखंडता और सुरक्षा की बात आती है, तो फ़ाइल सिस्टम के रूप में ऑब्जेक्ट स्टोर का उपयोग करने से कई गंभीर नकारात्मक प्रभाव पड़ते हैं।
आइए इसे s3fs-fuse नामक एक छोटी उपयोगिता का उपयोग करके कुछ वास्तविक विश्व परीक्षण के साथ प्रदर्शित करें। यह उपयोगिता आपको S3 बकेट को स्थानीय फ़ाइल सिस्टम के रूप में माउंट करने की अनुमति देती है। इसका मतलब S3 (सिंपल स्टोरेज सर्विस) फाइल सिस्टम - FUSE (यूजरस्पेस में फाइलसिस्टम) है। यह एक ओपन-सोर्स प्रोजेक्ट है जो S3 में फ़ाइल सिस्टम जैसा इंटरफ़ेस प्रस्तुत करने के लिए FUSE (यूज़रस्पेस में फ़ाइल सिस्टम) इंटरफ़ेस का लाभ उठाता है।
एक बार जब S3 बकेट को s3fs-fuse
का उपयोग करके माउंट किया जाता है, तो आप बकेट के साथ ऐसे इंटरैक्ट कर सकते हैं जैसे कि यह एक स्थानीय फ़ाइल सिस्टम हो। इसका मतलब है कि आप अपनी बकेट में फ़ाइलों पर नियमित फ़ाइल संचालन (जैसे पढ़ना, लिखना, स्थानांतरित करना आदि) का उपयोग कर सकते हैं। यह आश्चर्यजनक रूप से सुविधाजनक लगता है और हम तर्क दे सकते हैं कि यह एप्लिकेशन विकास को सरल बनाता है। लेकिन स्वाभाविक रूप से ऑब्जेक्ट स्टोरेज और फ़ाइल सिस्टम में मूलभूत अंतर होते हैं जो फ़ाइल सिस्टम के रूप में माउंट किए गए s3 बकेट को प्रभावित करेंगे।
आइए s3fs-fuse
उपयोगिता से पीछे हटकर वास्तविक कारणों पर चर्चा करें कि ऑब्जेक्ट स्टोरेज को फ़ाइल सिस्टम के रूप में मानना इष्टतम से बहुत दूर क्यों है। समस्या s3fs-fuse
से कहीं अधिक बड़ी है और इसमें अन्य उपयोगिताएँ भी शामिल हैं जैसे Amazon S3 के लिए रस्ट आधारित माउंटपॉइंट , एक फ़ाइल क्लाइंट जो स्थानीय फ़ाइल सिस्टम API कॉल को S3 ऑब्जेक्ट API कॉल में अनुवादित करता है। पहला कारण यह है कि ये सभी उपयोगिताएँ फ़ाइल सिस्टम संचालन के लिए POSIX पर निर्भर हैं। POSIX अक्षम है और इसका उद्देश्य कभी भी नेटवर्क पर बहुत बड़ी फ़ाइलों के साथ काम करना नहीं था।
POSIX आधारित प्रणालियों की गति कम हो जाती है क्योंकि मांग, विशेष रूप से समवर्ती मांग, बढ़ जाती है। जब बड़े संगठनों को गहन शिक्षण, एआई और अन्य डेटा गहन उपयोग के मामलों के लिए डेटा के महासागरों को संग्रहीत करने और उन तक पहुंचने की आवश्यकता होती है, तो POSIX के पास इन मांगों को पूरा करने की क्षमता या स्केलेबिलिटी नहीं है। जबकि ऑल-फ़्लैश ऐरे ने POSIX को गेम में रखा है, स्केलेबिलिटी और रेस्टफुल एपीआई (क्लाउड के हॉलमार्क) क्रिप्टोनाइट की तरह हैं।
इस वजह से, किसी ऑब्जेक्ट स्टोर के शीर्ष पर POSIX चलाना इष्टतम नहीं है। आइए कुछ कारणों पर नजर डालें:
प्रदर्शन: POSIX FS इंटरफ़ेस स्वाभाविक रूप से IOPS केंद्रित है। वे बातूनी, महंगे और मापने में कठिन हैं। RESTful S3 API IOPS को थ्रूपुट समस्या में परिवर्तित करके इसका समाधान करता है। स्केल करने के लिए थ्रूपुट आसान और सस्ता है। यही कारण है कि वस्तु भंडारण बड़े पैमाने पर उच्च प्रदर्शन वाला होता है। S3 के ऊपर POSIX की परत चढ़ाने से स्केल नहीं होगा क्योंकि POSIX HTTP RESTful इंटरफ़ेस पर प्रदर्शन करने के लिए बहुत अधिक बातचीत योग्य है।
शब्दार्थ: क्योंकि वस्तु संचालन परमाणु और अपरिवर्तनीय हैं, इसलिए निरंतरता की शुद्धता की गारंटी देने का कोई तरीका नहीं है। इसका मतलब यह है कि क्रैश की स्थिति में आप अप्रतिबद्ध डेटा खो सकते हैं या साझा माउंट के मामले में भ्रष्टाचार की समस्या का सामना कर सकते हैं।
डेटा इंटीग्रिटी : किसी फ़ाइल में लिखावट या कोई भी परिवर्तन तब तक नेमस्पेस में दिखाई नहीं देगा जब तक कि वह प्रतिबद्ध न हो जाए। इसका मतलब है कि साझा माउंट पर समवर्ती पहुंच में संशोधन नहीं दिखेंगे। यह साझा पहुंच के लिए उपयोगी नहीं है.
अभिगम नियंत्रण: POSIX अनुमतियाँ और ACL पहचान और पहुँच प्रबंधन नीतियों को संभालने के S3 API के तरीके के साथ आदिम और असंगत हैं। शीर्ष S3 API पर POSIX एक्सेस प्रबंधन को सुरक्षित रूप से लागू करना संभव नहीं है।
POSIX में अधिकांश कार्यक्षमता का अभाव है जो डेवलपर्स को S3 के बारे में पसंद है, जैसे ऑब्जेक्ट लेवल एन्क्रिप्शन, वर्जनिंग, अपरिवर्तनीयता - इनका POSIX दुनिया में कोई समकक्ष नहीं है और कुछ भी उनका अनुवाद करने में सक्षम नहीं है।
ये उदाहरण मुद्दे और उसके निहितार्थों को स्पष्ट करते हैं। आरंभ करने के लिए, हम इस CSV फ़ाइल का उपयोग करेंगे जो लगभग 10GB है और इसमें 112 पंक्तियाँ हैं।
नोट: हम मान लेंगे कि s3fs-fuse
पहले से ही स्थापित है और आपने ऑब्जेक्ट स्टोरेज से एक बकेट को अपने फाइल सिस्टम में माउंट कर लिया है। यदि नहीं, तो यहां दिए गए निर्देशों का पालन करें।
इन उदाहरणों में, हम मान लेंगे कि बकेट का नाम टेस्ट-बकेट है और फ़ाइल का नाम टैक्सी-डेटा है। csv /home/user/ डायरेक्टरी में है और s3fs-fuse bucket
/home/user/test-bucket/ पर माउंट किया गया है।
हम पहले कुछ सरल प्रयास करेंगे और एमसी कमांड का उपयोग करके सीएसवी फ़ाइल को हमारे टेस्ट-बकेट में कॉपी करने का प्रयास करेंगे और लगने वाले समय को रिकॉर्ड करेंगे।
time mc cp /home/user/taxi-data.csv minio/test-bucket/taxi-data.csv
इसमें बहुत अधिक समय नहीं लगना चाहिए और फ़ाइल को हमारी बकेट में कॉपी कर लिया जाना चाहिए। आइए अब s3fs-fuse
के साथ भी ऐसा ही करने का प्रयास करें
time cp /home/user/taxi-data.csv /home/user/test-bucket/taxi-data.csv
परीक्षण के दौरान समय लगा
real 1m36.056s user 0m14.507s sys 0m31.891s
मेरे मामले में मैं फ़ाइल को केवल आंशिक रूप से बकेट में कॉपी करने में सक्षम था और ऑपरेशन निम्न त्रुटि के साथ विफल हो गया
cp: error writing '/home/user/test-bucket/taxi-data.csv': Input/output error cp: failed to close '/home/user/test-bucket/taxi-data.csv': Input/output error
कई कोशिशों के बाद यह सफल हुआ
real 5m3.661s user 0m0.053s sys 2m35.234s
जैसा कि आप देख सकते हैं, उपयोगिता द्वारा की जाने वाली एपीआई कॉल की मात्रा और परिचालन के सामान्य ओवरहेड के कारण, उपयोगिता अस्थिर हो जाती है और अधिकांश परिचालन समाप्त भी नहीं होते हैं।
हमने आपको एक सरल cp
उदाहरण दिखाया है, जो विश्वसनीय हो भी सकता है और नहीं भी, क्योंकि आइए इसका सामना करते हैं, आप सोच सकते हैं कि time cp
काफी अल्पविकसित है।
तो जिन लोगों को अधिक अनुभवजन्य साक्ष्य की आवश्यकता है, आइए इसका परीक्षण करने के लिए एक पायथन स्निपेट लिखें। हम s3fs-fuse
और python s3fs
पैकेज दोनों के साथ एक सरल पांडा उदाहरण देंगे, और प्रदर्शन प्रभाव देखेंगे
import timeit import os import fsspec import s3fs import pandas as pd # Write a dummy CSV file to test-bucket df = pd.DataFrame({"column1": ["new_value1"], "column2": ["new_value2"]}) df.to_csv("s3://test-bucket/data/test-data.csv", index=False) def process_s3(): # add fsspec for pandas to use `s3://` path style and access S3 buckets directly fsspec.config.conf = { "s3": { "key": os.getenv("AWS_ACCESS_KEY_ID", "minioadmin"), "secret": os.getenv("AWS_SECRET_ACCESS_KEY", "minioadmin"), "client_kwargs": { "endpoint_url": os.getenv("S3_ENDPOINT", "https://play.min.io") } } } s3 = s3fs.S3FileSystem() for i in range(100): # Read the existing data print(i) df = pd.read_csv('s3://test-bucket/data/test-data.csv') # Append a new row new_df = pd.concat([df, pd.DataFrame([{"column1": f"value{i}", "column2": f"value{i}"}])], ignore_index=True) # Write the data back to the file new_df.to_csv('s3://test-bucket/data/test-data.csv', index=False) execution_time = timeit.timeit(process_s3, number=1) print(f"Execution time: {execution_time:.2f} seconds")
परीक्षण के दौरान लगा समय
Execution time: 8.54 seconds
आइए अब s3fs-fuse
के लिए भी यही प्रयास करें
import timeit import pandas as pd # Write a dummy CSV file to test-bucket df = pd.DataFrame({"column1": ["new_value1"], "column2": ["new_value2"]}) df.to_csv("s3://test-bucket/data/test-data.csv", index=False) def process_s3fs(): for i in range(100): # Read the existing data print(i) df = pd.read_csv('/home/user/test-bucket/data/test-data.csv') # Append a new row new_df = pd.concat([df, pd.DataFrame([{"column1": f"value{i}", "column2": f"value{i}"}])], ignore_index=True) # Write the data back to the file new_df.to_csv('/home/user/test-bucket/data/test-data.csv', index=False) execution_time = timeit.timeit(process_s3fs, number=1) print(f"Execution time: {execution_time:.2f} seconds")
परीक्षण के दौरान लगा समय
Execution time: 9.59 seconds
ये उदाहरण S3 फ़ाइलों को लगातार पढ़ने और लिखने को प्रदर्शित करते हैं। कल्पना कीजिए कि यह कई ग्राहकों द्वारा एक साथ निष्पादित किया जाता है - विलंबता नाटकीय रूप से बढ़ती है।
जैसा कि आप देख सकते हैं, ऑब्जेक्ट को फ़ाइलों के रूप में मानने के लिए POSIX अनुवाद का उपयोग करने और ऑब्जेक्ट के साथ काम करने के लिए डायरेक्ट एपीआई का उपयोग करने के बीच का अंतर रात और दिन का है। जब सुरक्षा, प्रदर्शन, डेटा अखंडता और अनुकूलता की बात आती है तो इसकी कोई तुलना ही नहीं है। मिनिओ के पास लगभग किसी भी लोकप्रिय प्रोग्रामिंग भाषा के साथ एकीकृत करने के लिए एसडीके हैं, और यह लगभग किसी भी प्लेटफॉर्म जैसे कि कुबेरनेट्स, बेयर मेटल लिनक्स, डॉकर कंटेनर - और भी बहुत कुछ पर चल सकता है।
मिनिओ आराम और पारगमन में एन्क्रिप्शन के साथ वस्तुओं को सुरक्षित करता है , डेटा अखंडता की रक्षा के लिए पहुंच को विनियमित करने और कोडिंग को मिटाने के लिए पीबीएसी के साथ संयुक्त होता है। चाहे आप मिनिओ को कहीं भी चलाएं, आप सर्वोत्तम संभव प्रदर्शन प्राप्त करेंगे, क्योंकि यह सर्वोत्तम संभव प्रदर्शन प्रदान करने के लिए अंतर्निहित हार्डवेयर ( आपके मिनियो परिनियोजन के लिए सर्वश्रेष्ठ हार्डवेयर का चयन करना देखें) का लाभ उठाता है। हमने मिनियो को GETs पर 325 GiB/s (349 GB/s) और PUTs पर 165 GiB/s (177 GB/s) पर केवल 32 नोड्स ऑफ-द-शेल्फ NVMe SSDs के साथ बेंचमार्क किया है ।
मिनिओ और आपके एप्लिकेशन के बीच में फ़ाइल सिस्टम उपयोगिता की कोई आवश्यकता नहीं है! विरासती ऐप्स को मिलने वाला कोई भी लाभ POSIX के दर्द से ऑफसेट हो जाएगा।
यदि आपके पास अपने एप्लिकेशन के लिए POSIX अनुवाद का उपयोग करने के बारे में कोई प्रश्न है, तो स्लैक पर हमसे संपर्क करना सुनिश्चित करें!
यहाँ भी प्रकाशित किया गया है.