স্পোর্টমাস্টারে আমরা কীভাবে একটি ক্যাশিং সিস্টেম বেছে নিয়েছি। অংশ 1

হ্যালো! আমার নাম আলেক্সি পিয়ানকভ, আমি স্পোর্টমাস্টার কোম্পানির একজন বিকাশকারী। তার মধ্যে পোস্ট আমি বলেছিলাম কিভাবে স্পোর্টমাস্টার ওয়েবসাইটের কাজ 2012 সালে শুরু হয়েছিল, আমরা কোন উদ্যোগগুলিকে "পুশ থ্রু" করতে পেরেছিলাম এবং এর বিপরীতে, আমরা কী রেক সংগ্রহ করেছি।

আজ আমি অন্য একটি বিষয় অনুসরণ করে এমন চিন্তা শেয়ার করতে চাই - সাইট অ্যাডমিন এলাকায় জাভা ব্যাকএন্ডের জন্য একটি ক্যাশিং সিস্টেম বেছে নেওয়া। এই প্লটটির আমার জন্য একটি বিশেষ অর্থ রয়েছে - যদিও গল্পটি মাত্র 2 মাস ধরে প্রকাশিত হয়েছিল, এই 60 দিনের মধ্যে আমরা 12-16 ঘন্টা কাজ করেছি এবং এক দিনের ছুটি ছাড়াই। এত পরিশ্রম করা যে সম্ভব তা কখনো ভাবিনি বা কল্পনাও করিনি।

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

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

প্রথমদিকে, উৎপাদনে যাওয়ার প্রথম সপ্তাহ থেকে এত বেশি উদ্বেগ ছিল যে বিষয়বস্তু পরিচালকদের জন্য এই ধরনের অসুবিধাগুলি একটি তুচ্ছ ছিল। কিন্তু, সবকিছু স্থির হওয়ার সাথে সাথে, প্রকল্পের বিকাশ অব্যাহত ছিল - কয়েক মাস পরে, 2015 এর শুরুতে, আমরা সক্রিয়ভাবে অ্যাডমিন প্যানেল বিকাশ করতে শুরু করি। 2015 এবং 2016 সালে, সবকিছু ঠিকঠাক চলছে, আমরা নিয়মিত প্রকাশ করি, অ্যাডমিন প্যানেল আরও বেশি করে ডেটা প্রস্তুতির কভার করে, এবং আমরা এই সত্যের জন্য প্রস্তুতি নিচ্ছি যে খুব শীঘ্রই আমাদের দলকে সবচেয়ে গুরুত্বপূর্ণ এবং জটিল জিনিসটির দায়িত্ব দেওয়া হবে - পণ্যটি সার্কিট (সমস্ত পণ্যের ডেটার সম্পূর্ণ প্রস্তুতি এবং রক্ষণাবেক্ষণ)। কিন্তু 2017 সালের গ্রীষ্মে, কমোডিটি সার্কিট চালু হওয়ার ঠিক আগে, প্রকল্পটি নিজেকে একটি খুব কঠিন পরিস্থিতিতে খুঁজে পাবে - অবিকল ক্যাশিংয়ের সমস্যার কারণে। আমি এই দুই পর্বের প্রকাশনার দ্বিতীয় পর্বে এই পর্ব সম্পর্কে কথা বলতে চাই।

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

যখন একটি ক্যাশিং কাজ ঘটে

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

প্রথম পর্যায়ে, আমরা অপ্টিমাইজেশান এবং কোড কর্মক্ষমতা সম্পর্কে চিন্তা করি না। প্রধান জিনিস কার্যকারিতা, দ্রুত একটি পাইলট রোল আউট এবং হাইপোথিসিস পরীক্ষা করা। এবং যদি লোড বৃদ্ধি পায়, আমরা লোহা পাম্প আপ. আমরা এটিকে দুই বা তিন গুণ, পাঁচ গুণ, সম্ভবত 10 গুণ বাড়াই। এখানে কোথাও - অর্থ এটি আর অনুমতি দেবে না। ব্যবহারকারীর সংখ্যা কত গুণ বাড়বে? এটি 2-5-10 এর মতো হবে না, তবে সফল হলে এটি 100-1000 থেকে 100 হাজার বার হবে। অর্থাৎ, তাড়াতাড়ি বা পরে, আপনাকে অপ্টিমাইজেশন করতে হবে।

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

অর্থাৎ, ফাংশনের বাস্তবায়ন আমাদের কাছে গুরুত্বপূর্ণ নয়। ফলাফল কি পরামিতি নির্ভর করে তা জানা যথেষ্ট। তারপরে, যদি প্যারামিটারের মানগুলি একটি বস্তুর আকারে উপস্থাপন করা হয় যা কিছু স্টোরেজে একটি কী হিসাবে ব্যবহার করা যেতে পারে, তাহলে গণনার ফলাফলটি সংরক্ষণ করা যেতে পারে এবং পরের বার এটি অ্যাক্সেস করার সময় পড়তে পারে। ফলাফলের এই লেখা এবং পড়া যদি ফাংশনটি কার্যকর করার চেয়ে দ্রুত হয় তবে গতির দিক থেকে আমাদের লাভ রয়েছে। লাভের পরিমাণ 100, 1000, এবং 100 হাজার বার পৌঁছতে পারে (10^5 বরং একটি ব্যতিক্রম, তবে মোটামুটি পিছিয়ে থাকা বেসের ক্ষেত্রে এটি বেশ সম্ভব)।

একটি ক্যাশিং সিস্টেমের জন্য প্রাথমিক প্রয়োজনীয়তা

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

চলুন এই মামলা খেলা যাক.

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

এবং যদি হার্ডওয়্যারের প্রাথমিক সরবরাহ 2-5 গুণ হতে পারে, তবে ক্যাশের সাহায্যে আমরা 10 এর একটি ফ্যাক্টর দ্বারা বা ভাল ক্ষেত্রে, 100 এর একটি ফ্যাক্টর দ্বারা, কিছু জায়গায় সম্ভবত একটি ফ্যাক্টর দ্বারা কর্মক্ষমতা উন্নত করতে পারি। 1000 এর। অর্থাৎ একই হার্ডওয়্যারে - আমরা 100 গুণ বেশি অনুরোধ প্রক্রিয়া করি। দুর্দান্ত, আপনি জিঞ্জারব্রেড প্রাপ্য!

কিন্তু এখন, এক সূক্ষ্ম মুহুর্তে, দৈবক্রমে, সিস্টেমটি ক্র্যাশ হয়ে যায় এবং ক্যাশে ভেঙে পড়ে। বিশেষ কিছু নেই - সর্বোপরি, ক্যাশে "উচ্চ পড়া এবং লেখার গতি, বাকি কিছু যায় আসে না" এর প্রয়োজনীয়তার ভিত্তিতে বেছে নেওয়া হয়েছিল।

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

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

উপসংহার: উচ্চ লোডেড প্রোডাকশন প্রজেক্টের জন্য ক্যাশিং সিস্টেমের প্রয়োজন শুধুমাত্র উচ্চ পড়ার এবং লেখার গতির জন্য নয়, ডেটা নিরাপত্তা এবং ব্যর্থতার প্রতিরোধ নিশ্চিত করার জন্যও।

পছন্দের ময়দা

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

স্পয়লার: পরিস্থিতি ঠিক কীভাবে তৈরি হয়েছিল যে আমরা এত বড় চুক্তি মিস করেছি এবং একটি তীব্র এবং উত্তেজনাপূর্ণ পরিস্থিতির সাথে শেষ হয়েছি - আমি আপনাকে দ্বিতীয় অংশে বলব - এবং কীভাবে আমরা শেষ হয়েছিলাম এবং কীভাবে আমরা বেরিয়ে এসেছি। কিন্তু এখন - আমি শুধু বলব যে এটি অনেক চাপের ছিল, এবং "ভাবতে - একরকম আমি ভাবতে পারি না, আমরা বোতলটি নাড়াচ্ছি।" "বোতল ঝাঁকান" এছাড়াও একটি স্পয়লার, যে পরে আরো.

আমরা যা করেছি:

1. আমরা Google এবং StackOverflow প্রস্তাবিত সমস্ত সিস্টেমের একটি তালিকা তৈরি করি। 30 এর একটু বেশি
2. আমরা উত্পাদনের জন্য সাধারণ লোড সহ পরীক্ষা লিখি। এটি করার জন্য, আমরা এমন ডেটা রেকর্ড করেছি যা একটি উত্পাদন পরিবেশে সিস্টেমের মধ্য দিয়ে যায় - নেটওয়ার্কে নয়, সিস্টেমের ভিতরে ডেটার জন্য এক ধরণের স্নিফার। সঠিকভাবে এই ডেটা পরীক্ষায় ব্যবহার করা হয়েছিল।
3. পুরো দলের সাথে, প্রত্যেকে তালিকা থেকে পরবর্তী সিস্টেম নির্বাচন করে, এটি কনফিগার করে এবং পরীক্ষা চালায়। এটি পরীক্ষায় উত্তীর্ণ হয় না, এটি বোঝা বহন করে না - আমরা এটিকে ফেলে দিই এবং লাইনে পরেরটিতে চলে যাই।
4. 17 তম সিস্টেমে এটি স্পষ্ট হয়ে ওঠে যে সবকিছুই আশাহীন। বোতল নাড়ানো বন্ধ করুন, এটি গুরুত্ব সহকারে চিন্তা করার সময়।

কিন্তু এটি এমন একটি বিকল্প যখন আপনাকে এমন একটি সিস্টেম বেছে নিতে হবে যা পূর্ব-প্রস্তুত পরীক্ষায় "গতি অর্জন করবে"। যদি এখনও এই ধরনের কোন পরীক্ষা না থাকে এবং আপনি দ্রুত নির্বাচন করতে চান?

আসুন এই বিকল্পটিকে মডেল করি (এটা কল্পনা করা কঠিন যে একজন মধ্যম+ বিকাশকারী একটি শূন্যতার মধ্যে থাকেন, এবং নির্বাচনের সময় কোন পণ্যটি প্রথমে চেষ্টা করতে হবে তা এখনও তার পছন্দকে আনুষ্ঠানিকভাবে প্রকাশ করেনি - তাই, আরও যুক্তি একটি তাত্ত্বিক/দর্শন/ একটি জুনিয়র সম্পর্কে)।

প্রয়োজনীয়তা সম্পর্কে সিদ্ধান্ত নেওয়ার পরে, আমরা বাক্সের বাইরে একটি সমাধান নির্বাচন করতে শুরু করব। কেন চাকা পুনরায় উদ্ভাবন: আমরা যাব এবং একটি তৈরি ক্যাশিং সিস্টেম নেব।

আপনি যদি সবে শুরু করেন এবং এটি গুগল করেন, তাহলে অর্ডার দিন বা নিন, তবে সাধারণভাবে, নির্দেশিকাগুলি এরকম হবে৷ প্রথমত, আপনি রেডিস জুড়ে আসবেন, এটি সর্বত্র শোনা যায়। তাহলে আপনি জানতে পারবেন যে EhCache হল সবচেয়ে পুরানো এবং সবচেয়ে প্রমাণিত সিস্টেম। পরবর্তীতে আমরা ট্যারান্টুল সম্পর্কে লিখব, একটি ঘরোয়া উন্নয়ন যার সমাধানের একটি অনন্য দিক রয়েছে। এবং ইগ্নাইটও, কারণ এটি এখন জনপ্রিয়তা বৃদ্ধি পাচ্ছে এবং SberTech-এর সমর্থন উপভোগ করছে৷ শেষে হ্যাজেলকাস্টও রয়েছে, কারণ এন্টারপ্রাইজ বিশ্বে এটি প্রায়শই বড় সংস্থাগুলির মধ্যে উপস্থিত হয়।

তালিকাটি সম্পূর্ণ নয়; কয়েক ডজন সিস্টেম রয়েছে। এবং আমরা শুধুমাত্র একটি জিনিস স্ক্রু করব. আসুন "সৌন্দর্য প্রতিযোগিতার" জন্য নির্বাচিত 5টি সিস্টেম গ্রহণ করি এবং একটি নির্বাচন করি। কে বিজয়ী হবে?

Redis

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

মনে হচ্ছে সবকিছু ঠিক আছে, আপনি এটি নিতে পারেন এবং এটি স্ক্রু করতে পারেন - আপনার যা প্রয়োজন, এটি করে। তবে শুধু মজা করার জন্য, আসুন অন্য প্রার্থীদের দিকে তাকাই।

EhCache

EhCache - "জাভার জন্য সর্বাধিক ব্যবহৃত ক্যাশে" (অফিসিয়াল ওয়েবসাইট থেকে স্লোগানের অনুবাদ)। এছাড়াও ওপেনসোর্স। এবং তারপরে আমরা বুঝতে পারি যে রেডিস জাভার জন্য নয়, সাধারণ, এবং এটির সাথে ইন্টারঅ্যাক্ট করার জন্য আপনার একটি মোড়ক দরকার। এবং EhCache আরও সুবিধাজনক হবে। সিস্টেম আর কি প্রতিশ্রুতি দেয়? নির্ভরযোগ্যতা, প্রমাণিত, সম্পূর্ণ কার্যকারিতা। ওয়েল, এটা সবচেয়ে সাধারণ. এবং টেরাবাইট ডেটা ক্যাশ করে।

রেডিস ভুলে গেছে, আমি EhCache বেছে নিতে প্রস্তুত।

কিন্তু দেশপ্রেমের অনুভূতি আমাকে টারান্টুল সম্পর্কে ভাল কী তা দেখতে ধাক্কা দেয়।

ট্যারান্টুল

ট্যারান্টুল - "রিয়েল-টাইম ডেটা ইন্টিগ্রেশন প্ল্যাটফর্ম" উপাধি পূরণ করে। এটি খুব জটিল শোনাচ্ছে, তাই আমরা পৃষ্ঠাটি বিশদভাবে পড়ি এবং একটি উচ্চ বিবৃতি খুঁজে পাই: "RAM এ 100% ডেটা ক্যাশ করে।" এটি প্রশ্ন উত্থাপন করা উচিত - সর্বোপরি, মেমরির চেয়ে অনেক বেশি ডেটা থাকতে পারে। ব্যাখ্যাটি হল এর মানে হল যে Tarantool মেমরি থেকে ডিস্কে ডেটা লেখার জন্য সিরিয়ালাইজেশন চালায় না। পরিবর্তে, এটি সিস্টেমের নিম্ন-স্তরের বৈশিষ্ট্যগুলি ব্যবহার করে, যখন মেমরিটি খুব ভাল I/O কার্যকারিতা সহ একটি ফাইল সিস্টেমে ম্যাপ করা হয়। সাধারণভাবে, তারা দুর্দান্ত এবং দুর্দান্ত কিছু করেছে।

আসুন বাস্তবায়নগুলি দেখি: Mail.ru কর্পোরেট হাইওয়ে, আভিটো, বেলাইন, মেগাফোন, আলফা-ব্যাঙ্ক, গ্যাজপ্রম...

ট্যারান্টুল সম্পর্কে এখনও যদি কোনও সন্দেহ থাকে, তবে মাস্টারকার্ডে বাস্তবায়ন কেস আমাকে শেষ করে দেয়। আমি ট্যারান্টুল নিই।

কিন্তু যাই হোক…

জ্বলে উঠা

… আরো কিছু আছে জ্বলে উঠা, একটি "ইন-মেমরি কম্পিউটিং প্ল্যাটফর্ম...পেটাবাইট ডেটাতে মেমরির গতি" হিসাবে বিল করা হয়। এছাড়াও এখানে অনেক সুবিধা রয়েছে: বিতরণ করা ইন-মেমরি ক্যাশে, দ্রুততম কী-মানের স্টোরেজ এবং ক্যাশে, অনুভূমিক স্কেলিং, উচ্চ প্রাপ্যতা, কঠোর অখণ্ডতা। সাধারণভাবে, দেখা যাচ্ছে যে দ্রুততম হল ইগ্নাইট।

বাস্তবায়ন: Sberbank, American Airlines, Yahoo! জাপান। এবং তারপরে আমি জানতে পারি যে Ignite শুধুমাত্র Sberbank-এ প্রয়োগ করা হয় না, কিন্তু SberTech টিম তার লোকদের Ignite টিমের কাছে পাঠায় যাতে পণ্যটি পরিমার্জিত হয়। এটি সম্পূর্ণ চিত্তাকর্ষক এবং আমি ইগ্নাইট নিতে প্রস্তুত।

এটা সম্পূর্ণরূপে অস্পষ্ট কেন, আমি পঞ্চম পয়েন্ট দেখছি।

হ্যাজেলকাস্ট

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

এটা, আমি Hazelcast নিতে প্রস্তুত.

তুলনা

কিন্তু আপনি যদি লক্ষ্য করেন, পাঁচজন প্রার্থীরই এমনভাবে বর্ণনা করা হয়েছে যে তাদের প্রত্যেকেই সেরা। কিভাবে নির্বাচন করবেন? আমরা দেখতে পাচ্ছি কোনটি সবচেয়ে জনপ্রিয়, তুলনা করে দেখুন এবং মাথাব্যথা চলে যাবে।

আমরা এই মত একটি খুঁজে ওভারভিউ, আমাদের 5 সিস্টেম চয়ন করুন.

এখানে সেগুলি সাজানো হয়েছে: রেডিস শীর্ষে রয়েছে, হ্যাজেলকাস্ট দ্বিতীয় স্থানে রয়েছে, Tarantool এবং Ignite জনপ্রিয়তা অর্জন করছে, EhCache হয়েছে এবং একই রয়ে গেছে।

কিন্তু এর তাকান হিসাব পদ্ধতি: ওয়েবসাইটের লিঙ্ক, সিস্টেমে সাধারণ আগ্রহ, কাজের অফার - দুর্দান্ত! অর্থাৎ, যখন আমার সিস্টেম ব্যর্থ হয়, আমি বলব: "না, এটা নির্ভরযোগ্য! অনেক কাজের অফার আছে..." এত সহজ তুলনা হবে না।

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

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

Hz বনাম রেডিস

আমরা এই খুঁজে তুলনা:


নীল হল রেডিস, লাল হল হ্যাজেলকাস্ট। হ্যাজেলকাস্ট সর্বত্র জয়ী হয়, এবং এর জন্য একটি যুক্তি রয়েছে: এটি মাল্টি-থ্রেডেড, অত্যন্ত অপ্টিমাইজ করা, প্রতিটি থ্রেড তার নিজস্ব পার্টিশনের সাথে কাজ করে, তাই কোনও ব্লকিং নেই। এবং রেডিস একক-থ্রেডেড; এটি আধুনিক মাল্টি-কোর সিপিইউ থেকে উপকৃত হয় না। Hazelcast এর অ্যাসিঙ্ক্রোনাস I/O আছে, Redis-Jedis-এর ব্লকিং সকেট আছে। সর্বোপরি, হ্যাজেলকাস্ট একটি বাইনারি প্রোটোকল ব্যবহার করে এবং রেডিস পাঠকেন্দ্রিক, যার অর্থ এটি অদক্ষ।

শুধু ক্ষেত্রে, আসুন তুলনা অন্য উত্স চালু করা যাক. তিনি আমাদের কি দেখাবেন?

রেডিস বনাম হার্জ

এক আরো তুলনা:


এখানে, বিপরীতভাবে, লাল হল Redis। অর্থাৎ রেডিস পারফরম্যান্সের দিক থেকে হ্যাজেলকাস্টকে ছাড়িয়ে গেছে। হ্যাজেলকাস্ট প্রথম তুলনা জিতেছে, রেডিস দ্বিতীয়টি জিতেছে। এখানে হ্যাজেলকাস্ট কেন আগের তুলনা জিতেছে তা খুব সুনির্দিষ্টভাবে ব্যাখ্যা করেছেন।

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

বোতল নাড়াচ্ছে

এবং আমি পুরো প্রক্রিয়াটি ব্যাখ্যা করতে পারি যা আমরা এখন নিম্নলিখিত রূপক দিয়ে করেছি: "বোতল কাঁপানো।" অর্থাৎ, এখন আপনাকে প্রোগ্রাম করতে হবে না, এখন মূল জিনিসটি স্ট্যাকওভারফ্লো পড়তে সক্ষম হওয়া। এবং আমার দলে একজন ব্যক্তি আছেন, একজন পেশাদার, যিনি জটিল মুহূর্তে ঠিক এইভাবে কাজ করেন।

সে কি করছে? তিনি একটি ভাঙা জিনিস দেখেন, একটি স্ট্যাক ট্রেস দেখেন, এটি থেকে কিছু শব্দ নেন (যা প্রোগ্রামে তার দক্ষতা), গুগলে অনুসন্ধান করেন, উত্তরগুলির মধ্যে স্ট্যাকওভারফ্লো খুঁজে পান। না পড়ে, চিন্তা না করে, প্রশ্নের উত্তরগুলির মধ্যে, তিনি "এটি করুন এবং এটি" বাক্যটির সাথে সবচেয়ে বেশি অনুরূপ কিছু বেছে নেন (এমন একটি উত্তর বেছে নেওয়া তার প্রতিভা, কারণ এটি সর্বদা সবচেয়ে বেশি লাইক পেয়েছে এমন উত্তর নয়), প্রযোজ্য, দেখায়: যদি কিছু পরিবর্তিত হয়, তাহলে দুর্দান্ত। যদি এটি পরিবর্তিত না হয় তবে এটিকে ফিরিয়ে আনুন। এবং লঞ্চ-চেক-সার্চ পুনরাবৃত্তি করুন। এবং এই স্বজ্ঞাত উপায়ে, তিনি নিশ্চিত করেন যে কোডটি কিছু সময় পরে কাজ করে। সে জানে না কেন, সে জানে না সে কি করেছে, সে ব্যাখ্যা করতে পারে না। কিন্তু! এই সংক্রমণ কাজ করে। এবং "আগুন নিভে গেছে।" এখন আমরা কি করেছি তা বের করা যাক। যখন প্রোগ্রামটি কাজ করে, তখন এটি সহজে মাত্রার একটি ক্রম। এবং এটি অনেক সময় বাঁচায়।

এই পদ্ধতিটি এই উদাহরণ দিয়ে খুব ভালভাবে ব্যাখ্যা করা হয়েছে।

বোতলে পাল তোলা নৌকা সংগ্রহ করা একসময় খুবই জনপ্রিয় ছিল। একই সময়ে, পালতোলা নৌকাটি বড় এবং ভঙ্গুর, এবং বোতলটির ঘাড় খুব সরু, এটি ভিতরে ঠেলে দেওয়া অসম্ভব। কিভাবে এটি একত্রিত করতে?

এই ধরনের একটি পদ্ধতি আছে, খুব দ্রুত এবং খুব কার্যকর।

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

আমরা এটি কাউকে দেখাই: "সেরযোগ, তুমি কি দেখছ!?" এবং সত্যিই, দূর থেকে এটি একটি জাহাজের মত দেখায়। কিন্তু এভাবে চলতে দেওয়া যাবে না।

অন্য উপায় আছে. এগুলি হ্যাকারদের মতো আরও উন্নত ছেলেরা ব্যবহার করে।

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

সমস্যা সেট করার দৃষ্টিকোণ থেকে, সবকিছু সঠিক বলে মনে হচ্ছে। কিন্তু একটি উদাহরণ হিসাবে জাহাজ ব্যবহার করে: কেন এই জাহাজ আদৌ করা, যাহোক কার এটি প্রয়োজন? এটি কোন কার্যকারিতা প্রদান করে না। সাধারণত এই ধরনের জাহাজগুলি খুব উচ্চ-পদস্থ ব্যক্তিদের জন্য উপহার, যারা এটিকে তাদের উপরে একটি তাকের উপর রাখে, কোন ধরণের প্রতীক হিসাবে, একটি চিহ্ন হিসাবে। আর এমন একজন ব্যক্তি, কোনো বড় ব্যবসার প্রধান বা কোনো উচ্চপদস্থ কর্মকর্তা হলে কী করে পতাকা দাঁড় করাবে এমন হ্যাক, যার গলা কেটে ফেলা হয়েছে? ভালো হতো যদি সে কখনোই না জানতো। তাহলে, তারা কীভাবে এই জাহাজগুলি তৈরি করবে যা একজন গুরুত্বপূর্ণ ব্যক্তিকে দেওয়া যেতে পারে?

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

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

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

কোথায় বোতল-নেক খুঁজতে হবে

আসুন বোতলটি না ঝাঁকাতে চেষ্টা করি, একের পর এক যা কিছু আছে তার মধ্য দিয়ে না যাওয়ার চেষ্টা করি, তবে আসুন দেখি কী সমস্যা দেখা দেবে যদি আমরা হঠাৎ করে, আমাদের কাজের জন্য, নিজেরাই এমন একটি সিস্টেম ডিজাইন করি। অবশ্যই, আমরা বাইকটি একত্রিত করব না, তবে পণ্যের বিবরণে কোন বিষয়গুলিতে মনোযোগ দিতে হবে তা নির্ধারণ করতে আমরা এই চিত্রটি ব্যবহার করব। আসুন এই ধরনের একটি ডায়াগ্রাম স্কেচ আউট.

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

আমাদের কোড লজিকও দরকার (2), যা আসলে ক্যাশিং সম্পর্কে। ক্লায়েন্ট কিছু API এর মাধ্যমে এই কোডের সাথে যোগাযোগ করে। ক্লায়েন্ট কোড (1) একই JVM-এর মধ্যে হতে পারে বা নেটওয়ার্কের মাধ্যমে এটি অ্যাক্সেস করতে পারে। অভ্যন্তরে বাস্তবায়িত যুক্তি হল কোন বস্তুগুলিকে ক্যাশে ছেড়ে দিতে হবে এবং কোনটি বাইরে ফেলতে হবে তার সিদ্ধান্ত। আমরা ক্যাশে সংরক্ষণ করতে মেমরি (3) ব্যবহার করি, তবে প্রয়োজনে আমরা ডিস্কে কিছু ডেটা সংরক্ষণ করতে পারি (4)।

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

পরবর্তী ক্লাস্টার সঙ্গে মিথস্ক্রিয়া হয়. সম্ভবত, এটি একই সিস্টেমে থাকবে, তবে এটি আলাদাভাবে হতে পারে। এখানে আপনাকে এটিতে ডেটা স্থানান্তর, ডেটা সিরিয়ালাইজেশনের গতি এবং ক্লাস্টারের মধ্যে মিথস্ক্রিয়াও বিবেচনা করতে হবে।

এখন, একদিকে, আমরা আমাদের কোড থেকে অনুরোধগুলি প্রক্রিয়া করার সময় ক্যাশে সিস্টেমে "কি গিয়ারগুলি ঘুরবে" কল্পনা করতে পারি, এবং অন্যদিকে, আমরা অনুমান করতে পারি আমাদের কোড এই সিস্টেমের জন্য কী এবং কতগুলি অনুরোধ তৈরি করবে৷ আমাদের ব্যবহারের ক্ষেত্রে একটি সিস্টেম চয়ন করার জন্য - এটি একটি কম বা কম স্বচ্ছ পছন্দ করার জন্য যথেষ্ট।

হ্যাজেলকাস্ট

আসুন দেখি কিভাবে আমাদের তালিকায় এই পচন প্রয়োগ করতে হয়। যেমন হ্যাজেলকাস্ট।

হ্যাজেলকাস্ট থেকে ডেটা রাখার/নেওয়ার জন্য, ক্লায়েন্ট কোডটি (1) এপিআই অ্যাক্সেস করে। Hz আপনাকে এম্বেডেড হিসাবে সার্ভার চালানোর অনুমতি দেয় এবং এই ক্ষেত্রে, এপিআই অ্যাক্সেস করা JVM-এর ভিতরে একটি পদ্ধতি কল, যা বিনামূল্যে বিবেচনা করা যেতে পারে।

লজিক ইন (2) কাজ করার জন্য, Hz সিরিয়ালাইজড কী-এর বাইট অ্যারের হ্যাশের উপর নির্ভর করে - অর্থাৎ, যে কোনও ক্ষেত্রে কীটি সিরিয়াল করা হবে। এটি Hz এর জন্য অনিবার্য ওভারহেড।
উচ্ছেদ কৌশলগুলি ভালভাবে প্রয়োগ করা হয়, তবে বিশেষ ক্ষেত্রে আপনি নিজের যোগ করতে পারেন। আপনি এই অংশ সম্পর্কে চিন্তা করতে হবে না.

স্টোরেজ (4) সংযুক্ত করা যেতে পারে। দারুণ। এম্বেডেডের জন্য মিথস্ক্রিয়া (5) তাত্ক্ষণিক বিবেচনা করা যেতে পারে। ক্লাস্টারে নোডের মধ্যে ডেটা বিনিময় (6) - হ্যাঁ, এটি বিদ্যমান। এটি গতির ব্যয়ে দোষ সহনশীলতার একটি বিনিয়োগ। Hz বৈশিষ্ট্য Near-cache আপনাকে মূল্য কমাতে দেয় - ক্লাস্টারের অন্যান্য নোড থেকে প্রাপ্ত ডেটা ক্যাশে করা হবে।

গতি বাড়ানোর জন্য এই ধরনের পরিস্থিতিতে কি করা যেতে পারে?

উদাহরণস্বরূপ, (2) তে কীটির ক্রমিককরণ এড়ানোর জন্য - হটেস্ট ডেটার জন্য হ্যাজেলকাস্টের উপরে আরেকটি ক্যাশে সংযুক্ত করুন। স্পোর্টমাস্টার এই উদ্দেশ্যে ক্যাফেইন বেছে নেন।

লেভেলে (6) মোচড়ের জন্য, Hz দুই ধরনের স্টোরেজ অফার করে: IMap এবং ReplicatedMap।


হেজেলকাস্ট কীভাবে স্পোর্টমাস্টার প্রযুক্তি স্ট্যাকে প্রবেশ করেছে তা উল্লেখ করার মতো।

2012 সালে, যখন আমরা ভবিষ্যতের সাইটের প্রথম পাইলটে কাজ করছিলাম, তখন এটি হ্যাজেলকাস্ট ছিল যা সার্চ ইঞ্জিনের প্রথম লিঙ্ক হিসাবে পরিণত হয়েছিল। পরিচিতি "প্রথমবার" শুরু করেছিল - আমরা এই সত্যটি দ্বারা মুগ্ধ হয়েছিলাম যে মাত্র দুই ঘন্টা পরে, যখন আমরা সিস্টেমে Hz স্ক্রু করেছিলাম, এটি কাজ করেছিল। এবং এটা ভাল কাজ. দিনের শেষে আমরা বেশ কয়েকটি পরীক্ষা সম্পন্ন করেছি এবং খুশি ছিলাম। এবং শক্তির এই রিজার্ভটি সময়ের সাথে সাথে Hz ছুঁড়ে দেওয়া বিস্ময়গুলি কাটিয়ে উঠতে যথেষ্ট ছিল। এখন স্পোর্টমাস্টার দলের হ্যাজেলকাস্টকে পরিত্যাগ করার কোনো কারণ নেই।

তবে "সার্চ ইঞ্জিনের প্রথম লিঙ্ক" এবং "হ্যালোওয়ার্ল্ড দ্রুত একত্রিত হয়েছিল" এর মতো যুক্তিগুলি অবশ্যই একটি ব্যতিক্রম এবং সেই মুহূর্তের বৈশিষ্ট্য যা পছন্দটি হয়েছিল। নির্বাচিত সিস্টেমের জন্য আসল পরীক্ষাগুলি উত্পাদনে প্রকাশের সাথে শুরু হয় এবং এই পর্যায়ে আপনার ক্যাশে সহ যে কোনও সিস্টেম বেছে নেওয়ার সময় মনোযোগ দেওয়া উচিত। প্রকৃতপক্ষে, আমাদের ক্ষেত্রে আমরা বলতে পারি যে আমরা দুর্ঘটনাক্রমে হ্যাজেলকাস্টকে বেছে নিয়েছি, কিন্তু তারপরে দেখা গেল যে আমরা সঠিকভাবে বেছে নিয়েছি।

উত্পাদনের জন্য, আরও অনেক গুরুত্বপূর্ণ: পর্যবেক্ষণ, পৃথক নোডগুলিতে ব্যর্থতাগুলি পরিচালনা করা, ডেটা প্রতিলিপিকরণ, স্কেলিং ব্যয়। অর্থাৎ, সিস্টেমের রক্ষণাবেক্ষণের সময় যে কাজগুলি উত্থাপিত হবে সেগুলিতে মনোযোগ দেওয়া মূল্যবান - যখন লোড পরিকল্পনার চেয়ে কয়েকগুণ বেশি হয়, যখন আমরা দুর্ঘটনাক্রমে ভুল জায়গায় কিছু আপলোড করি, যখন আমাদের একটি নতুন সংস্করণ রোল আউট করতে হয় কোডের, ডেটা প্রতিস্থাপন করুন এবং ক্লায়েন্টদের জন্য অলক্ষিত করুন।

এই সমস্ত প্রয়োজনীয়তার জন্য, হ্যাজেলকাস্ট অবশ্যই বিলের সাথে খাপ খায়।

অব্যাহত রাখতে হবে

তবে হ্যাজেলকাস্ট কোনও নিরাময় নয়। 2017 সালে, আমরা প্রশাসক ক্যাশের জন্য Hazelcast বেছে নিয়েছি, শুধুমাত্র অতীতের অভিজ্ঞতা থেকে ভাল ইম্প্রেশনের ভিত্তিতে। এটি একটি অত্যন্ত নিষ্ঠুর রসিকতায় মূল ভূমিকা পালন করেছিল, যার কারণে আমরা নিজেদেরকে একটি কঠিন পরিস্থিতিতে খুঁজে পেয়েছি এবং "বীরত্বের সাথে" 60 দিনের জন্য এটি থেকে বেরিয়ে এসেছি। কিন্তু পরবর্তী অংশে যে আরো.

ইতিমধ্যে... শুভ নতুন কোড!

উত্স: www.habr.com