কয়েক মিলিয়ন ছোট ফাইল দক্ষতার সাথে সংরক্ষণ করুন। স্ব-হোস্টেড সমাধান

প্রিয় সম্প্রদায়, এই নিবন্ধটি লক্ষ লক্ষ ছোট ফাইল দক্ষতার সাথে সংরক্ষণ এবং পুনরুদ্ধার করার উপর ফোকাস করবে। এই পর্যায়ে, POSIX-সামঞ্জস্যপূর্ণ ফাইল সিস্টেমের জন্য চূড়ান্ত সমাধান প্রস্তাব করা হয়েছে লকগুলির জন্য সম্পূর্ণ সমর্থন সহ, ক্লাস্টার লক সহ, এবং আপাতদৃষ্টিতে এমনকি ক্রাচ ছাড়াই।

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

ধারণাটি হল:

সহজ কথায়, ছোট ফাইলগুলি সার্ভারের মাধ্যমে আপলোড করা হয়, সেগুলি সরাসরি সংরক্ষণাগারে সংরক্ষণ করা হয় এবং এটি থেকে পড়াও হয় এবং বড় ফাইলগুলি পাশাপাশি রাখা হয়। স্কিম: 1 ফোল্ডার = 1 আর্কাইভ, মোট আমাদের কাছে ছোট ফাইল সহ কয়েক মিলিয়ন আর্কাইভ রয়েছে, কয়েক মিলিয়ন ফাইল নয়। এবং এই সব সম্পূর্ণরূপে বাস্তবায়িত হয়, কোনো স্ক্রিপ্ট ছাড়াই বা টার/জিপ আর্কাইভে ফাইল না রেখে।

আমি এটি ছোট রাখার চেষ্টা করব, পোস্টটি দীর্ঘ হলে আগেই ক্ষমাপ্রার্থী।

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

যারা নিবন্ধ পড়তে পছন্দ করেন না, তাদের জন্য একটু ডকুমেন্টেশন সহজ:

এখানে и এখানে.

এবং একই সময়ে ডকার, এখন কেবলমাত্র এনজিনক্সের ভিতরে একটি বিকল্প রয়েছে:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

পরবর্তী:

যদি অনেকগুলি ফাইল থাকে, তবে উল্লেখযোগ্য সংস্থানগুলির প্রয়োজন হয় এবং সবচেয়ে খারাপ দিকটি হল তাদের মধ্যে কিছু নষ্ট হয়। উদাহরণস্বরূপ, একটি ক্লাস্টারড ফাইল সিস্টেম ব্যবহার করার সময় (এই ক্ষেত্রে, MooseFS), ফাইলটি, তার প্রকৃত আকার নির্বিশেষে, সর্বদা কমপক্ষে 64 KB নেয়। অর্থাৎ, 3, 10 বা 30 KB আকারের ফাইলগুলির জন্য, ডিস্কে 64 KB প্রয়োজন৷ যদি এক বিলিয়ন ফাইলের এক চতুর্থাংশ থাকে তবে আমরা 2 থেকে 10 টেরাবাইট হারাতে পারি। অনির্দিষ্টকালের জন্য নতুন ফাইল তৈরি করা সম্ভব হবে না, যেহেতু MooseFS এর একটি সীমাবদ্ধতা রয়েছে: প্রতিটি ফাইলের একটি প্রতিলিপি সহ 1 বিলিয়নের বেশি নয়।

ফাইলের সংখ্যা বাড়ার সাথে সাথে মেটাডেটার জন্য প্রচুর RAM প্রয়োজন। ঘন ঘন বড় মেটাডেটা ডাম্পগুলিও SSD ড্রাইভের পরিধানে অবদান রাখে।

wZD সার্ভার। আমরা ডিস্কে জিনিসগুলিকে সাজিয়ে রাখি।

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

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

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

wZD সার্ভারের আর্কিটেকচার এবং বৈশিষ্ট্য।

সার্ভারটি লিনাক্স, বিএসডি, সোলারিস এবং ওএসএক্স অপারেটিং সিস্টেমের অধীনে কাজ করে। আমি শুধুমাত্র লিনাক্সের অধীনে AMD64 আর্কিটেকচারের জন্য পরীক্ষা করেছি, তবে এটি ARM64, PPC64, MIPS64 এর জন্য কাজ করা উচিত।

প্রধান বৈশিষ্ট্য:

• মাল্টিথ্রেডিং;
• মাল্টিসার্ভার, ত্রুটি সহনশীলতা এবং লোড ভারসাম্য প্রদান;
• ব্যবহারকারী বা বিকাশকারীর জন্য সর্বাধিক স্বচ্ছতা;
• সমর্থিত HTTP পদ্ধতি: GET, HEAD, PUT এবং DELETE;
• ক্লায়েন্ট হেডারের মাধ্যমে পড়া এবং লেখার আচরণ নিয়ন্ত্রণ;
• নমনীয় ভার্চুয়াল হোস্টের জন্য সমর্থন;
• লেখার/পড়ার সময় সিআরসি ডেটা অখণ্ডতা সমর্থন করে;
• ন্যূনতম মেমরি খরচ এবং সর্বোত্তম নেটওয়ার্ক কর্মক্ষমতা টিউনিংয়ের জন্য আধা-গতিশীল বাফার;
• বিলম্বিত ডেটা কম্প্যাকশন;
• এছাড়াও, পরিষেবা বন্ধ না করে ফাইল স্থানান্তর করার জন্য একটি মাল্টি-থ্রেডেড আর্কাইভার wZA দেওয়া হয়।

বাস্তব অভিজ্ঞতা:

আমি দীর্ঘকাল ধরে লাইভ ডেটাতে সার্ভার এবং আর্কাইভারের বিকাশ এবং পরীক্ষা করছি, এখন এটি একটি ক্লাস্টারে সফলভাবে কাজ করছে যাতে 250,000,000টি ছোট ফাইল (ছবি) রয়েছে যা পৃথক SATA ড্রাইভে 15,000,000 ডিরেক্টরিতে অবস্থিত। 10 সার্ভারের একটি ক্লাস্টার হল একটি অরিজিন সার্ভার যা একটি CDN নেটওয়ার্কের পিছনে ইনস্টল করা হয়। এটি পরিষেবা দিতে, 2 Nginx সার্ভার + 2 wZD সার্ভার ব্যবহার করা হয়।

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

কর্মক্ষমতা পরীক্ষা:

জিপ করা ফাইলের আকার যত ছোট হবে, এতে দ্রুত GET এবং PUT অপারেশন করা হবে। আসুন নিয়মিত ফাইল এবং বোল্ট আর্কাইভের সাথে HTTP ক্লায়েন্ট লেখার জন্য মোট সময় তুলনা করি, সেইসাথে পড়ার সাথে। 32 KB, 256 KB, 1024 KB, 4096 KB এবং 32768 KB আকারের ফাইলগুলির সাথে কাজ তুলনা করা হয়৷

বোল্ট সংরক্ষণাগারগুলির সাথে কাজ করার সময়, প্রতিটি ফাইলের ডেটা অখণ্ডতা পরীক্ষা করা হয় (সিআরসি ব্যবহার করা হয়), রেকর্ডিংয়ের আগে এবং রেকর্ডিংয়ের পরেও, অন-দ্য-ফ্লাই রিডিং এবং পুনঃগণনা ঘটে, এটি স্বাভাবিকভাবেই বিলম্বের পরিচয় দেয়, তবে মূল জিনিসটি ডেটা সুরক্ষা।

আমি SSD ড্রাইভে পারফরম্যান্স পরীক্ষা পরিচালনা করেছি, যেহেতু SATA ড্রাইভে পরীক্ষাগুলি স্পষ্ট পার্থক্য দেখায় না।

পরীক্ষার ফলাফলের উপর ভিত্তি করে গ্রাফ:

আপনি দেখতে পাচ্ছেন, ছোট ফাইলগুলির জন্য সংরক্ষণাগারভুক্ত এবং নন-আর্কাইভ করা ফাইলগুলির মধ্যে পড়ার এবং লেখার সময়ের পার্থক্য কম।

32 এমবি আকারের ফাইলগুলি পড়া এবং লেখার পরীক্ষা করার সময় আমরা একটি সম্পূর্ণ ভিন্ন চিত্র পাই:

ফাইল পড়ার মধ্যে সময়ের পার্থক্য 5-25 ms এর মধ্যে। রেকর্ডিংয়ের সাথে, জিনিসগুলি আরও খারাপ, পার্থক্যটি প্রায় 150 এমএস। তবে এই ক্ষেত্রে বড় ফাইল আপলোড করার দরকার নেই; এটি করার কোন মানে নেই; তারা সংরক্ষণাগার থেকে আলাদাভাবে থাকতে পারে।

*প্রযুক্তিগতভাবে, আপনি এই সার্ভারটি NoSQL-এর প্রয়োজনের কাজে ব্যবহার করতে পারেন।

wZD সার্ভারের সাথে কাজ করার প্রাথমিক পদ্ধতি:

একটি নিয়মিত ফাইল লোড হচ্ছে:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

বোল্ট সংরক্ষণাগারে একটি ফাইল আপলোড করা হচ্ছে (যদি সার্ভার প্যারামিটার fmaxsize, যা সর্বোচ্চ ফাইলের আকার নির্ধারণ করে যা সংরক্ষণাগারে অন্তর্ভুক্ত করা যেতে পারে, তা অতিক্রম করা হয় না; যদি এটি অতিক্রম করা হয়, ফাইলটি যথারীতি সংরক্ষণাগারের পাশে আপলোড করা হবে):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

একটি ফাইল ডাউনলোড করা (যদি ডিস্কে এবং সংরক্ষণাগারে একই নামের ফাইল থাকে, তবে ডাউনলোড করার সময়, ডিফল্টরূপে আনআর্কাইভ করা ফাইলটিকে অগ্রাধিকার দেওয়া হয়):

curl -o test.jpg http://localhost/test/test.jpg

বোল্ট সংরক্ষণাগার থেকে একটি ফাইল ডাউনলোড করা হচ্ছে (জোর করে):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

অন্যান্য পদ্ধতির বর্ণনা ডকুমেন্টেশনে আছে।

wZD ডকুমেন্টেশন
wZA ডকুমেন্টেশন

সার্ভার বর্তমানে শুধুমাত্র HTTP প্রোটোকল সমর্থন করে; এটি এখনও HTTPS এর সাথে কাজ করে না। POST পদ্ধতিটিও সমর্থিত নয় (এটি প্রয়োজন কি না তা এখনও সিদ্ধান্ত নেওয়া হয়নি)।

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

করতে:

• ক্লাস্টার ফাইল সিস্টেম ছাড়াই বড় সিস্টেমে ব্যবহারের সম্ভাবনার জন্য আপনার নিজস্ব প্রতিলিপিকারী এবং পরিবেশক + জিওর বিকাশ (প্রাপ্তবয়স্কদের জন্য সবকিছু)
• মেটাডেটা সম্পূর্ণভাবে হারিয়ে গেলে সম্পূর্ণ বিপরীত পুনরুদ্ধারের সম্ভাবনা (যদি কোনো পরিবেশক ব্যবহার করে)
• বিভিন্ন প্রোগ্রামিং ভাষার জন্য স্থায়ী নেটওয়ার্ক সংযোগ এবং ড্রাইভার ব্যবহার করার ক্ষমতার জন্য নেটিভ প্রোটোকল
• NoSQL উপাদান ব্যবহার করার জন্য উন্নত সম্ভাবনা
• বোল্ট আর্কাইভের ভিতরে ফাইল বা মানের জন্য এবং নিয়মিত ফাইলের জন্য বিভিন্ন ধরনের কম্প্রেশন (gzip, zstd, snappy)
• বোল্ট আর্কাইভ এবং নিয়মিত ফাইলের জন্য ফাইল বা মানগুলির জন্য বিভিন্ন ধরণের এনক্রিপশন
• বিলম্বিত সার্ভার-সাইড ভিডিও রূপান্তর, GPU সহ

আমার কাছে সবকিছু আছে, আমি আশা করি এই সার্ভারটি কারও কাজে লাগবে, BSD-3 লাইসেন্স, ডাবল কপিরাইট, যেহেতু আমি যেখানে কাজ করি এমন কোনও সংস্থা না থাকলে সার্ভারটি লেখা হত না। আমি একমাত্র বিকাশকারী। আমি আপনার খুঁজে পাওয়া কোনো বাগ এবং বৈশিষ্ট্য অনুরোধের জন্য কৃতজ্ঞ হবে.

উত্স: www.habr.com