paint-brush
কেন আপনি একটি অবজেক্ট স্টোরের উপরে একটি ফাইল সিস্টেম রাখা উচিত নয়দ্বারা@minio
6,908 পড়া
6,908 পড়া

কেন আপনি একটি অবজেক্ট স্টোরের উপরে একটি ফাইল সিস্টেম রাখা উচিত নয়

দ্বারা MinIO7m2023/11/14
Read on Terminal Reader

অতিদীর্ঘ; পড়তে

যখন বড় সংস্থাগুলিকে গভীর শিক্ষা, AI এবং অন্যান্য ডেটা নিবিড় ব্যবহারের ক্ষেত্রে ডেটার সমুদ্র সঞ্চয় এবং অ্যাক্সেস করতে হয়, তখন POSIX-এর এই চাহিদাগুলি পূরণ করার ক্ষমতা বা মাপযোগ্যতা নেই।
featured image - কেন আপনি একটি অবজেক্ট স্টোরের উপরে একটি ফাইল সিস্টেম রাখা উচিত নয়
MinIO HackerNoon profile picture
0-item
1-item

স্টোরেজ কেনার সময়, সাধারণত মিডিয়ার উপর জোর দেওয়া হয়, তবে অ্যাক্সেসের পদ্ধতিগুলিও বিবেচনা করা আরও গুরুত্বপূর্ণ হতে পারে। পরিকাঠামো ডিজাইন এবং সংগ্রহ করার সময় আপনাকে স্টোরেজ প্রোটোকলগুলিকে বিবেচনায় নিতে হবে, বিশেষত যখন আপনি ক্লাউড-নেটিভ অবজেক্ট স্টোরেজে স্থানান্তরিত করার জন্য উত্তরাধিকার সঞ্চয়স্থান ছেড়ে যান। যাইহোক, অবজেক্ট স্টোরেজ যোগাযোগের জন্য S3 API-এর উপর নির্ভর করে, যখন লিগ্যাসি ওয়ার্কলোডগুলি POSIX-এর উপর নির্ভর করে, পোর্টেবল অপারেটিং সিস্টেম ইন্টারফেস যা 1980-এর দশকে ইউনিক্স ওএস-এর মধ্যে অ্যাপ্লিকেশনগুলিকে পোর্টেবল করার অনুমতি দেওয়ার জন্য উন্নত মানগুলির একটি সেট প্রদান করে। সম্ভাবনা হল যে বেশিরভাগ এন্টারপ্রাইজের কয়েক দশক ধরে পরিষেবাতে অ্যাপ্লিকেশন রয়েছে যা POSIX-এ চালানোর জন্য তৈরি করা হয়েছিল। সম্ভাবনা রয়েছে যে প্রকৌশলীরা ইতিমধ্যেই POSIX এর দুর্বল কর্মক্ষমতা সম্পর্কে সচেতন।


এটি বলা হচ্ছে, যখন আপনার কাছে এমন লিগ্যাসি সিস্টেম থাকে যা শুধুমাত্র একটি নির্দিষ্ট বিন্যাসে বা একটি নির্দিষ্ট উত্স থেকে ডেটা গ্রহণ করতে পারে, তখন আপনার বিকল্পগুলি সীমিত হতে পারে এবং আপনার কাছে একটি পুরানো প্রোটোকল প্রয়োগ করা বা আপনার কোড পুনরায় লেখা ছাড়া আর কোন বিকল্প থাকতে পারে না। উদাহরণস্বরূপ, যদি আপনি শুধুমাত্র একটি ফাইল সিস্টেমের সাথে স্থানীয় ডিস্ক থেকে ইনজেস্ট করতে পারেন এবং নেটওয়ার্কের মাধ্যমে অ্যাক্সেস করা RESTful API এর সাথে না, তাহলে আপনার অ্যাপ্লিকেশনটি ব্যবহার করার আগে আপনাকে প্রথমে সেই ডেটা ডিস্কে উপলব্ধ করতে হবে। যাইহোক, একটি ফাইল সিস্টেম হিসাবে একটি অবজেক্ট স্টোর ব্যবহার করার অনেকগুলি গুরুতর নেতিবাচক প্রভাব রয়েছে যখন এটি কর্মক্ষমতা, সামঞ্জস্য, ডেটা অখণ্ডতা এবং নিরাপত্তার ক্ষেত্রে আসে।


আসুন s3fs-fuse নামে একটি ছোট ইউটিলিটি ব্যবহার করে কিছু বাস্তব বিশ্বের পরীক্ষার মাধ্যমে এটি প্রদর্শন করা যাক। এই ইউটিলিটি আপনাকে স্থানীয় ফাইল সিস্টেম হিসাবে একটি S3 বালতি মাউন্ট করতে দেয়। এর অর্থ হল S3 (সাধারণ স্টোরেজ সার্ভিস) ফাইল সিস্টেম - FUSE (ব্যবহারকারী স্থানে ফাইল সিস্টেম)। এটি একটি ওপেন-সোর্স প্রজেক্ট যা S3-তে একটি ফাইল-সিস্টেম-এর মতো ইন্টারফেস উপস্থাপন করতে FUSE (ইউজারস্পেসে ফাইল সিস্টেম) ইন্টারফেস ব্যবহার করে।


একবার s3fs-fuse ব্যবহার করে একটি S3 বালতি মাউন্ট করা হলে, আপনি বাকেটের সাথে যোগাযোগ করতে পারেন যেন এটি একটি স্থানীয় ফাইল সিস্টেম। এর মানে আপনি আপনার বালতিতে থাকা ফাইলগুলিতে নিয়মিত ফাইল অপারেশন (যেমন পড়া, লিখতে, সরানো ইত্যাদি) ব্যবহার করতে পারেন। এটি আশ্চর্যজনকভাবে সুবিধাজনক শোনাচ্ছে এবং আমরা যুক্তি দিতে পারি এটি অ্যাপ্লিকেশন বিকাশকে সহজ করে তোলে। কিন্তু অন্তর্নিহিতভাবে অবজেক্ট স্টোরেজ এবং ফাইল সিস্টেমের মৌলিক পার্থক্য রয়েছে যা একটি ফাইল সিস্টেম হিসাবে মাউন্ট করা s3 বাকেটকে প্রভাবিত করবে।


অবজেক্ট স্টোরেজকে একটি ফাইল সিস্টেম হিসাবে বিবেচনা করা কেন সর্বোত্তম নয় তার আসল কারণগুলি নিয়ে আলোচনা করার জন্য আসুন s3fs-fuse ইউটিলিটি থেকে ফিরে আসার জন্য কিছুক্ষণ সময় নেওয়া যাক। সমস্যাটি s3fs-fuse এর চেয়ে অনেক বড় এবং এতে অন্যান্য ইউটিলিটিগুলি অন্তর্ভুক্ত রয়েছে যেমন Amazon S3 এর জন্য Rust ভিত্তিক মাউন্টপয়েন্ট , একটি ফাইল ক্লায়েন্ট যা স্থানীয় ফাইল সিস্টেম API কলগুলিকে S3 অবজেক্ট API কলে অনুবাদ করে। প্রথম কারণ হল এই সমস্ত ইউটিলিটি ফাইল সিস্টেম অপারেশনের জন্য POSIX-এর উপর নির্ভর করে। POSIX অদক্ষ এবং এটি কখনই খুব বড় ফাইলের সাথে ওভার-দ্য-নেটওয়ার্কের সাথে কাজ করার উদ্দেশ্যে ছিল না।


POSIX ভিত্তিক সিস্টেমগুলির গতি হ্রাস পায় কারণ তাদের উপর চাহিদা, বিশেষ করে সমসাময়িক চাহিদা বৃদ্ধি পায়। যখন বড় সংস্থাগুলিকে গভীর শিক্ষা, AI এবং অন্যান্য ডেটা নিবিড় ব্যবহারের ক্ষেত্রে ডেটার সমুদ্র সঞ্চয় এবং অ্যাক্সেস করতে হয়, তখন POSIX-এর এই চাহিদাগুলি পূরণ করার ক্ষমতা বা মাপযোগ্যতা নেই। যদিও অল-ফ্ল্যাশ অ্যারেগুলি গেমে POSIX রেখেছে, স্কেলেবিলিটি এবং RESTful API (ক্লাউডের হলমার্ক) ক্রিপ্টোনাইটের মতো।


এই কারণে, একটি অবজেক্ট স্টোরের উপরে POSIX চালানো সাবঅপ্টিমাল। চলুন দেখে নেওয়া যাক এর কিছু কারণ:


  1. কর্মক্ষমতা: POSIX FS ইন্টারফেস সহজাতভাবে IOPS কেন্দ্রিক। তারা চটি, ব্যয়বহুল এবং মাপকাঠি কঠিন. RESTful S3 API IOPS কে একটি থ্রুপুট সমস্যায় রূপান্তর করে এটিকে সমাধান করে। থ্রুপুট স্কেল করা সহজ এবং সস্তা। এই কারণেই অবজেক্ট স্টোরেজ একটি বিশাল স্কেলে উচ্চ-কর্মক্ষমতা। S3-এর উপরে POSIX লেয়ারিং স্কেল করা হবে না কারণ POSIX একটি HTTP RESTful ইন্টারফেসে সঞ্চালনের জন্য খুব চটি।


  2. শব্দার্থবিদ্যা: যেহেতু বস্তুর ক্রিয়াকলাপগুলি পারমাণবিক এবং অপরিবর্তনীয়, তাই ধারাবাহিকতার সঠিকতার গ্যারান্টি দেওয়ার কোন উপায় নেই। এর মানে আপনি ক্র্যাশের ক্ষেত্রে অপ্রত্যাশিত ডেটা হারাতে পারেন বা ভাগ করা মাউন্টের ক্ষেত্রে দুর্নীতির সমস্যায় পড়তে পারেন।


  3. ডেটা ইন্টিগ্রিটি : ফাইলে লেখা বা কোনো মিউটেশন প্রতিশ্রুতিবদ্ধ না হওয়া পর্যন্ত নামস্থানে প্রদর্শিত হবে না। এর মানে শেয়ার্ড মাউন্ট জুড়ে সমসাময়িক অ্যাক্সেস পরিবর্তনগুলি দেখতে পাবে না। শেয়ার্ড অ্যাক্সেসের জন্য এটি কার্যকর নয়।


  4. অ্যাক্সেস কন্ট্রোল: POSIX অনুমতি এবং ACLগুলি আদিম এবং S3 API-এর পরিচয় এবং অ্যাক্সেস ম্যানেজমেন্ট নীতিগুলি পরিচালনার পদ্ধতির সাথে বেমানান৷ শীর্ষস্থানীয় S3 APIগুলিতে POSIX অ্যাক্সেস ব্যবস্থাপনা নিরাপদে বাস্তবায়ন করা সম্ভব নয়।


POSIX-এরও বেশিরভাগ কার্যকারিতার অভাব রয়েছে যা ডেভেলপাররা S3 সম্পর্কে পছন্দ করে, যেমন অবজেক্ট লেভেল এনক্রিপশন, সংস্করণ, অপরিবর্তনীয়তা – এগুলোর POSIX বিশ্বে কোন সমতুল্য নেই এবং কিছুই তাদের অনুবাদ করতে সক্ষম নয়।

POSIX ব্যথা পয়েন্ট

এই উদাহরণগুলি সমস্যা এবং এর প্রভাবকে ব্যাখ্যা করে। শুরু করার জন্য, আমরা এই CSV ফাইলটি ব্যবহার করব যা প্রায় 10GB এবং এতে 112টি সারি রয়েছে।


দ্রষ্টব্য: আমরা অনুমান করব s3fs-fuse ইতিমধ্যেই ইনস্টল করা আছে এবং আপনি অবজেক্ট স্টোরেজ থেকে আপনার ফাইল সিস্টেমে একটি বালতি মাউন্ট করেছেন। যদি না হয়, এখানে নির্দেশাবলী অনুসরণ করুন.


এই উদাহরণগুলিতে, আমরা ধরে নেব বাকেটের নাম test-bucket এবং ফাইলের নাম taxi-data.csv হল /home/user/ ডিরেক্টরিতে এবং s3fs-fuse bucket /home/user/test-bucket/ এ মাউন্ট করা হয়েছে।

কপি অপারেশন

আমরা প্রথমে সাধারণ কিছু চেষ্টা করব এবং mc কমান্ড ব্যবহার করে CSV ফাইলটি আমাদের টেস্ট-বাকেটে অনুলিপি করার চেষ্টা করব এবং সময় নেওয়া সময় রেকর্ড করব।

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


আপনি দেখতে পাচ্ছেন, ইউটিলিটিকে যে পরিমাণ API কল করতে হবে এবং অপারেশনগুলির সাধারণ ওভারহেডের কারণে, ইউটিলিটি অস্থির হয়ে ওঠে এবং বেশিরভাগ অপারেশন এমনকি শেষ হয় না।

পান্ডা উদাহরণ

আমরা আপনাকে একটি সাধারণ 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 অনুবাদ ব্যবহার করা এবং বস্তুর সাথে কাজ করার জন্য সরাসরি API ব্যবহার করার মধ্যে পার্থক্য হল রাত এবং দিন। নিরাপত্তা, কর্মক্ষমতা, ডেটা অখণ্ডতা এবং সামঞ্জস্যের ক্ষেত্রে কোন তুলনা নেই। MinIO-এর প্রায় যেকোনো জনপ্রিয় প্রোগ্রামিং ভাষার সাথে একীভূত করার জন্য SDK আছে এবং এটি প্রায় যেকোনো প্ল্যাটফর্মে যেমন কুবারনেটস, বেয়ার মেটাল লিনাক্স, ডকার কন্টেইনার - এবং আরও অনেক কিছুতে চলতে পারে।


MinIO বিশ্রামে এবং ইন-ট্রানজিটে এনক্রিপশন সহ বস্তুগুলিকে সুরক্ষিত করে , ডেটা অখণ্ডতা রক্ষা করার জন্য অ্যাক্সেস নিয়ন্ত্রণ এবং মুছে ফেলার কোডিংকে PBAC এর সাথে মিলিত করে। আপনি যেখানেই MinIO চালান তা নির্বিশেষে আপনি সম্ভাব্য সর্বোত্তম কর্মক্ষমতা অর্জন করবেন, কারণ এটি অন্তর্নিহিত হার্ডওয়্যারের সুবিধা নেয় (দেখুন আপনার MinIO স্থাপনার জন্য সেরা হার্ডওয়্যার নির্বাচন করা ) সম্ভাব্য সর্বোত্তম কর্মক্ষমতা প্রদান করতে। আমরা MinIO-কে GETs-এ 325 GiB/s (349 GB/s) এবং PUTs-এ 165 GiB/s (177 GB/s) অফ-দ্য-শেল্ফ NVMe SSD-এর মাত্র 32টি নোড সহ বেঞ্চমার্ক করেছি


MinIO এবং আপনার অ্যাপ্লিকেশনের মাঝখানে একটি ফাইল সিস্টেম ইউটিলিটির প্রয়োজন নেই! উত্তরাধিকারী অ্যাপগুলি পেতে পারে এমন যেকোন সুবিধা POSIX-এর ব্যথা দ্বারা অফসেট করা হবে৷


আপনার অ্যাপ্লিকেশনের জন্য POSIX অনুবাদ ব্যবহার করার বিষয়ে আপনার কোনো প্রশ্ন থাকলে, Slack- এ আমাদের সাথে যোগাযোগ করতে ভুলবেন না!


এছাড়াও এখানে প্রকাশিত.