DBA বট জো. আনাতোলি স্ট্যান্সলার (Postgres.ai)

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

ভিডিও:

হাই সব! আমার নাম আনাতোলি স্ট্যান্সলার। আমি একটা কোম্পানিতে কাজ করি postgres.ai. আমরা ডেভেলপার, DBAs এবং QAs থেকে Postgres-এর কাজের সাথে যুক্ত বিলম্ব দূর করে উন্নয়ন প্রক্রিয়াকে ত্বরান্বিত করতে প্রতিশ্রুতিবদ্ধ।

আমাদের দুর্দান্ত ক্লায়েন্ট রয়েছে এবং আজকের প্রতিবেদনের অংশটি তাদের সাথে কাজ করার সময় আমরা যে ক্ষেত্রে দেখা করেছি তার জন্য উত্সর্গ করা হবে। আমরা কিভাবে তাদের বেশ গুরুতর সমস্যা সমাধান করতে সাহায্য করেছি সে সম্পর্কে আমি কথা বলব।

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

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

কে কখনও সরাসরি পণ্যের উপর সূচী তৈরি করেছে বা কোন পরিবর্তন করেছে? বেশ কিছুটা। এবং কার জন্য এই তথ্যটি হারিয়ে গেছে বা ডাউনটাইম ছিল? তাহলে এই যন্ত্রণা জানো। ঈশ্বরকে ধন্যবাদ ব্যাকআপ আছে.

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

এটা ব্যাথা, এটা ব্যয়বহুল. সম্ভবত না করাই ভালো।

এবং এটি করার সেরা উপায় কি?

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

এটি আমাদের কিছু ত্রুটিগুলিকে সরিয়ে দেওয়ার অনুমতি দেবে, যেমন সেগুলিকে প্রোডে থাকা থেকে আটকাতে পারে৷

সমস্যাগুলো কি কি?

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

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

এটি পূর্ববর্তী পদ্ধতির চেয়ে ভাল, তবে এখনও একটি উচ্চ সম্ভাবনা রয়েছে যে কোনও ধরণের ত্রুটি উত্পাদনে যাবে।

প্রতিটি বিকাশকারীকে একটি টেস্ট বেঞ্চ, একটি পূর্ণ আকারের অনুলিপি দিতে আমাদের কী বাধা দেয়? আমি মনে করি এটা পরিষ্কার যে পথ কি পায়.

কার একটি টেরাবাইটের চেয়ে বড় একটি ডাটাবেস আছে? অর্ধেকেরও বেশি রুম।

এবং এটি স্পষ্ট যে প্রতিটি বিকাশকারীর জন্য মেশিন রাখা, যখন এত বড় উত্পাদন হয়, এটি খুব ব্যয়বহুল এবং পাশাপাশি, এটি দীর্ঘ সময় নেয়।

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

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

কিন্তু তারা এই পদ্ধতিটি ব্যবহার করে কারণ এটি তাদের পণ্যটিকে নির্ভরযোগ্য রাখতে দেয়।

আমরা এখানে কি করতে পারি? আসুন টেস্ট বেঞ্চগুলি সস্তা করি এবং প্রত্যেক ডেভেলপারকে তাদের নিজস্ব টেস্ট বেঞ্চ দিই।

এবং এটা সম্ভব।

এবং এই পদ্ধতিতে, যখন আমরা প্রতিটি বিকাশকারীর জন্য পাতলা ক্লোন তৈরি করি, তখন আমরা এটি একটি মেশিনে ভাগ করতে পারি। উদাহরণস্বরূপ, যদি আপনার একটি 10TB ডাটাবেস থাকে এবং আপনি এটি 10 ​​জন বিকাশকারীকে দিতে চান তবে আপনার XNUMX x XNUMXTB ডেটাবেস থাকতে হবে না। একটি মেশিন ব্যবহার করে প্রতিটি বিকাশকারীর জন্য পাতলা বিচ্ছিন্ন কপি তৈরি করতে আপনার শুধুমাত্র একটি মেশিনের প্রয়োজন। এটা কিভাবে কাজ করে তা একটু পরেই বলব।

বাস্তব উদাহরণ:

• DB - 4,5 টেরাবাইট।

• আমরা 30 সেকেন্ডের মধ্যে স্বাধীন কপি পেতে পারি।

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

এটা অসাধারণ. এখানে আমরা যাদু এবং একটি সমান্তরাল মহাবিশ্বের কথা বলছি।

আমাদের ক্ষেত্রে, এটি OpenZFS সিস্টেম ব্যবহার করে কাজ করে।

OpenZFS হল একটি কপি-অন-রাইট ফাইল সিস্টেম যা বাক্সের বাইরে স্ন্যাপশট এবং ক্লোন সমর্থন করে। এটা নির্ভরযোগ্য এবং মাপযোগ্য. তিনি পরিচালনা করা খুব সহজ. এটি আক্ষরিক অর্থে দুটি দলে স্থাপন করা যেতে পারে।

অন্যান্য বিকল্প আছে:

• এলভিএম,

• স্টোরেজ (উদাহরণস্বরূপ, বিশুদ্ধ স্টোরেজ)।

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

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

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

এবং এই ব্যবহারকারী এই ধরনের একটি ডেটা সেট নিয়ে কাজ করবে। তিনি ধীরে ধীরে সেগুলি পরিবর্তন করবেন, নিজের স্ন্যাপশটগুলি তৈরি করবেন।

এবং আমরা শাখা হবে. আমাদের ক্ষেত্রে প্রতিটি বিকাশকারীর নিজস্ব ক্লোন থাকার সুযোগ থাকবে যা তিনি সম্পাদনা করেন এবং যে ডেটা ভাগ করা হবে তা সবার মধ্যে ভাগ করা হবে।

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

• প্রথমটি ডেটার উত্স, যেখান থেকে আপনি এটি নেবেন। আপনি উত্পাদন সঙ্গে প্রতিলিপি সেট আপ করতে পারেন. আপনি ইতিমধ্যে কনফিগার করা ব্যাকআপ ব্যবহার করতে পারেন, আমি আশা করি। ওয়াল-ই, ওয়াল-জি বা বর্মন। এমনকি যদি আপনি আরডিএস বা ক্লাউড এসকিউএল এর মতো ক্লাউড সমাধান ব্যবহার করেন তবে আপনি লজিক্যাল ডাম্প ব্যবহার করতে পারেন। তবে আমরা এখনও আপনাকে ব্যাকআপগুলি ব্যবহার করার পরামর্শ দিই, কারণ এই পদ্ধতির সাথে আপনি ফাইলগুলির শারীরিক গঠনও বজায় রাখবেন, যা আপনাকে সেই মেট্রিকের আরও কাছাকাছি হতে দেবে যা আপনি বিদ্যমান সমস্যাগুলি ধরতে উত্পাদনে দেখতে পাবেন।

• দ্বিতীয়টি হল যেখানে আপনি ডাটাবেস ল্যাব হোস্ট করতে চান। এটি ক্লাউড হতে পারে, এটি অন-প্রিমিস হতে পারে। এখানে বলা জরুরী যে ZFS ডেটা কম্প্রেশন সমর্থন করে। এবং এটি বেশ ভাল করে।

কল্পনা করুন যে এই ধরনের প্রতিটি ক্লোনের জন্য, আমরা বেস দিয়ে যে ক্রিয়াকলাপগুলি করি তার উপর নির্ভর করে, এক ধরণের দেব বৃদ্ধি পাবে। এর জন্য দেবেরও জায়গা লাগবে। কিন্তু আমরা 4,5 টেরাবাইটের একটি বেস গ্রহণ করার কারণে, ZFS এটিকে 3,5 টেরাবাইটে সংকুচিত করবে। এটি সেটিংসের উপর নির্ভর করে পরিবর্তিত হতে পারে। এবং আমাদের এখনও দেবের জন্য জায়গা আছে।

এই ধরনের একটি সিস্টেম বিভিন্ন ক্ষেত্রে ব্যবহার করা যেতে পারে।

• এগুলি হল ডেভেলপার, ডিবিএ ক্যোয়ারী ভ্যালিডেশনের জন্য, অপ্টিমাইজেশানের জন্য৷

• এটিকে আমরা প্রোডের জন্য রোল আউট করার আগে একটি নির্দিষ্ট স্থানান্তর পরীক্ষা করতে QA পরীক্ষায় ব্যবহার করা যেতে পারে। এবং আমরা বাস্তব ডেটা সহ QA-এর জন্য বিশেষ পরিবেশও বাড়াতে পারি, যেখানে তারা নতুন কার্যকারিতা পরীক্ষা করতে পারে। এবং এটি অপেক্ষার ঘন্টার পরিবর্তে সেকেন্ড সময় নেবে, এবং অন্য কিছু ক্ষেত্রে দিন যেখানে পাতলা কপি ব্যবহার করা হয় না।

• এবং আরেকটি মামলা। যদি কোম্পানির একটি বিশ্লেষণ সিস্টেম সেট আপ না থাকে, তাহলে আমরা পণ্যের ভিত্তির একটি পাতলা ক্লোন আলাদা করতে পারি এবং এটিকে দীর্ঘ প্রশ্ন বা বিশেষ সূচকে দিতে পারি যা বিশ্লেষণে ব্যবহার করা যেতে পারে।

এই পদ্ধতির সাথে:

1. "প্রোড"-এ ত্রুটির সম্ভাবনা কম, কারণ আমরা পূর্ণ-আকারের ডেটাতে সমস্ত পরিবর্তন পরীক্ষা করেছি৷

2. আমাদের পরীক্ষার সংস্কৃতি রয়েছে, কারণ এখন আপনার নিজের স্ট্যান্ডের জন্য আপনাকে ঘন্টার পর ঘন্টা অপেক্ষা করতে হবে না।

3. এবং পরীক্ষার মধ্যে কোন বাধা নেই, কোন অপেক্ষা নেই। আপনি আসলে যেতে এবং চেক করতে পারেন. এবং আমরা উন্নয়নের গতি বাড়ানোর সাথে সাথে এটি আরও ভাল হবে।

• কম রিফ্যাক্টরিং হবে। কম বাগ পণ্য শেষ হবে. আমরা পরে তাদের কম রিফ্যাক্টর করব।

• আমরা অপরিবর্তনীয় পরিবর্তনগুলিকে বিপরীত করতে পারি। এটি আদর্শ পদ্ধতি নয়।

1. এটি উপকারী কারণ আমরা পরীক্ষার বেঞ্চের সংস্থানগুলি ভাগ করি।

ইতিমধ্যে ভাল, কিন্তু আর কি ত্বরান্বিত হতে পারে?

এই ধরনের একটি সিস্টেমের জন্য ধন্যবাদ, আমরা এই ধরনের পরীক্ষার প্রবেশের জন্য থ্রেশহোল্ডকে ব্যাপকভাবে কমাতে পারি।

এখন একটি দুষ্ট বৃত্ত আছে, যখন একজন বিকাশকারীকে, প্রকৃত পূর্ণ আকারের ডেটা অ্যাক্সেস পেতে, অবশ্যই একজন বিশেষজ্ঞ হতে হবে। তিনি এই ধরনের অ্যাক্সেস সঙ্গে বিশ্বাস করা আবশ্যক.

কিন্তু তা না থাকলে বাড়বে কীভাবে। কিন্তু যদি আপনার কাছে পরীক্ষার ডেটার একটি খুব ছোট সেট থাকে তবে কী হবে? তাহলে আপনি কোন বাস্তব অভিজ্ঞতা পাবেন না।

কিভাবে এই বৃত্ত থেকে বের হবে? প্রথম ইন্টারফেস হিসাবে, যেকোনো স্তরের বিকাশকারীদের জন্য সুবিধাজনক, আমরা স্ল্যাক বট বেছে নিয়েছি। কিন্তু এটা অন্য কোন ইন্টারফেস হতে পারে.

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

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

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

কিন্তু এই পরীক্ষাগুলিকে যুক্তিসঙ্গত হওয়ার জন্য, আপনাকে এই সমস্যার সমাধান করতে হবে।

এটা স্পষ্ট যে গুরুত্বপূর্ণ পয়েন্ট একই তথ্য. কিন্তু আমরা ইতিমধ্যে এটা আছে. এবং আমরা একই কনফিগারেশন অর্জন করতে চাই। এবং আমরা যেমন একটি প্রায় অভিন্ন কনফিগারেশন দিতে পারেন.

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

আসুন মনে রাখবেন পোস্টগ্রেস মেমরির সাথে কীভাবে কাজ করে। আমরা দুটি ক্যাশে আছে. একটি ফাইল সিস্টেম থেকে এবং একটি নেটিভ পোস্টগ্রেস, অর্থাৎ শেয়ার্ড বাফার ক্যাশে।

এটা লক্ষ করা গুরুত্বপূর্ণ যে পোস্টগ্রেস শুরু হলে শেয়ার্ড বাফার ক্যাশে বরাদ্দ করা হয়, আপনি কনফিগারেশনে কোন আকার উল্লেখ করেছেন তার উপর নির্ভর করে।

এবং দ্বিতীয় ক্যাশে সমস্ত উপলব্ধ স্থান ব্যবহার করে।

এবং যখন আমরা একটি মেশিনে বেশ কয়েকটি ক্লোন তৈরি করি, তখন দেখা যাচ্ছে যে আমরা ধীরে ধীরে স্মৃতি পূরণ করি। এবং একটি ভাল উপায়ে, শেয়ার্ড বাফার ক্যাশে মেশিনে উপলব্ধ মোট মেমরির 25%।

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

কিন্তু অন্যদিকে, Buffer Cache সূচীগুলির জন্য প্রশ্নগুলি চালানোর জন্য ব্যবহৃত হয়, অর্থাৎ, আমাদের ক্যাশে কত বড় তার উপর পরিকল্পনাটি নির্ভর করে। এবং যদি আমরা এই প্যারামিটারটি গ্রহণ করি এবং এটি হ্রাস করি তবে আমাদের পরিকল্পনাগুলি অনেক পরিবর্তন করতে পারে।

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

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

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

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

কিন্তু এটি সময়কে প্রভাবিত করতে পারে। এবং আমরা সময়ের দ্বারা প্রশ্নগুলিকে অপ্টিমাইজ করি, তবে এটি গুরুত্বপূর্ণ যে সময় অনেকগুলি কারণের উপর নির্ভর করে:

• এটি বর্তমানে প্রোডের উপর থাকা লোডের উপর নির্ভর করে।

• এটি মেশিনের নিজস্ব বৈশিষ্ট্যের উপর নির্ভর করে।

এবং এটি একটি পরোক্ষ পরামিতি, কিন্তু প্রকৃতপক্ষে ফলাফল পাওয়ার জন্য এই ক্যোয়ারীটি যে পরিমাণ ডেটা পড়বে তার দ্বারা আমরা সঠিকভাবে অপ্টিমাইজ করতে পারি।

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

জো বিশেষভাবে অপ্টিমাইজ করা হয় কিভাবে এক কটাক্ষপাত করা যাক.

একটি বাস্তব সিস্টেম থেকে একটি অনুরোধ নেওয়া যাক. এই ক্ষেত্রে, ডাটাবেস 1 টেরাবাইট। এবং আমরা তাজা পোস্টের সংখ্যা গণনা করতে চাই যেগুলিতে 10 টিরও বেশি লাইক ছিল৷

আমরা চ্যানেলে একটি বার্তা লিখছি, আমাদের জন্য একটি ক্লোন স্থাপন করা হয়েছে। এবং আমরা দেখব যে এই ধরনের অনুরোধ 2,5 মিনিটের মধ্যে সম্পূর্ণ হবে। এই প্রথম জিনিস আমরা লক্ষ্য.

B জো আপনাকে প্ল্যান এবং মেট্রিক্সের উপর ভিত্তি করে স্বয়ংক্রিয় সুপারিশ দেখাবে।

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

চলুন ঘনিষ্ঠভাবে দেখুন কি ঘটেছে. প্রকৃতপক্ষে, আমরা দেখতে পাচ্ছি যে আমরা ফাইল ক্যাশে বা এমনকি ডিস্ক থেকে প্রায় দেড় গিগাবাইট ডেটা পড়েছি। এবং এটি ভাল নয়, কারণ আমরা মাত্র 142 লাইন পেয়েছি।

এবং, মনে হবে, আমাদের এখানে একটি সূচক স্ক্যান আছে এবং দ্রুত কাজ করা উচিত ছিল, কিন্তু যেহেতু আমরা অনেকগুলি লাইন ফিল্টার আউট করেছি (আমাদের সেগুলি গণনা করতে হয়েছিল), অনুরোধটি ধীরে ধীরে কার্যকর হয়েছে৷

এবং এটি পরিকল্পনায় ঘটেছে কারণ অনুসন্ধানের শর্ত এবং সূচকের শর্তগুলি আংশিকভাবে মেলে না।

আসুন সূচীটিকে আরও সুনির্দিষ্ট করার চেষ্টা করি এবং এর পরে ক্যোয়ারী এক্সিকিউশন কীভাবে পরিবর্তিত হয় তা দেখুন।

সূচক তৈরিতে বেশ দীর্ঘ সময় লেগেছিল, কিন্তু এখন আমরা ক্যোয়ারী পরীক্ষা করে দেখি যে 2,5 মিনিটের পরিবর্তে সময় মাত্র 156 মিলিসেকেন্ড, যা যথেষ্ট ভাল। এবং আমরা মাত্র 6 মেগাবাইট ডেটা পড়ি।

এবং এখন আমরা সূচক শুধুমাত্র স্ক্যান ব্যবহার.

আরেকটি গুরুত্বপূর্ণ ঘটনা হল আমরা পরিকল্পনাটি আরও কিছু বোধগম্য উপায়ে উপস্থাপন করতে চাই। আমরা শিখা গ্রাফ ব্যবহার করে ভিজ্যুয়ালাইজেশন বাস্তবায়ন করেছি।

এটি একটি ভিন্ন অনুরোধ, আরও তীব্র। এবং আমরা দুটি পরামিতি অনুসারে ফ্লেম গ্রাফ তৈরি করি: এটি এমন ডেটার পরিমাণ যা একটি নির্দিষ্ট নোড পরিকল্পনা এবং সময়ে গণনা করে, অর্থাৎ নোডের কার্যকর করার সময়।

এখানে আমরা একে অপরের সাথে নির্দিষ্ট নোড তুলনা করতে পারি। এবং তাদের মধ্যে কোনটি কম বা বেশি লাগে তা পরিষ্কার হবে, যা সাধারণত অন্যান্য রেন্ডারিং পদ্ধতিতে করা কঠিন।

অবশ্যই, সবাই ব্যাখ্যা.depesz.com জানে। এই ভিজ্যুয়ালাইজেশনের একটি ভাল বৈশিষ্ট্য হল যে আমরা পাঠ্য পরিকল্পনা সংরক্ষণ করি এবং কিছু মৌলিক পরামিতি একটি টেবিলে রাখি যাতে আমরা সাজাতে পারি।

এবং ডেভেলপাররা যারা এখনও এই বিষয়ে বিস্তারিত ভাবেননি তারা ব্যাখ্যা.depesz.com ব্যবহার করেন, কারণ কোন মেট্রিক্স গুরুত্বপূর্ণ এবং কোনটি নয় তা বের করা তাদের পক্ষে সহজ।

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

সহযোগিতা

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

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

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

এখানেই শেষ করছি। ধন্যবাদ!

প্রশ্ন

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

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

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

হ্যাঁ, আমি একটি নেস্টেড প্রশ্ন আছে. অর্থাৎ, আপনি কিভাবে এই মডিউলগুলির জীবনচক্র নিশ্চিত করবেন? আমরা এই সমস্যা এবং একটি সম্পূর্ণ পৃথক গল্প আছে. এটা কিভাবে হয়?

প্রতিটি ক্লোনের জন্য কিছু ttl আছে। মূলত, আমাদের একটি নির্দিষ্ট ttl আছে।

কি, গোপন না হলে?

1 ঘন্টা, অর্থাৎ নিষ্ক্রিয় - 1 ঘন্টা। যদি এটি ব্যবহার না করা হয়, তাহলে আমরা এটি ঠুং ঠুং শব্দ করি। কিন্তু এখানে অবাক হওয়ার কিছু নেই, যেহেতু আমরা সেকেন্ডের মধ্যে ক্লোনটি বাড়াতে পারি। এবং যদি আপনি আবার এটি প্রয়োজন, তারপর দয়া করে.

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

ZFS এর প্রধান সমস্যা কি? সত্য যে আপনাকে অবশ্যই একই হোস্টে চালাতে হবে, অর্থাৎ সমস্ত দৃষ্টান্ত একই OS এর মধ্যে থাকবে। এবং স্টোরেজ ক্ষেত্রে, আপনি বিভিন্ন সরঞ্জাম সংযোগ করতে পারেন। এবং বটলনেক শুধুমাত্র সেই ব্লকগুলি যা স্টোরেজ সিস্টেমে রয়েছে। এবং প্রযুক্তির পছন্দের প্রশ্নটি আকর্ষণীয়। কেন LVM না?

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

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

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

কিন্তু ZFS সবার জন্য উপলব্ধ। DelPhix ইতিমধ্যে যথেষ্ট, তাদের 300 ক্লায়েন্ট আছে। এর মধ্যে, fortune 100-এর 50 জন ক্লায়েন্ট রয়েছে, অর্থাৎ তারা NASA, ইত্যাদির দিকে লক্ষ্য করে। সবার জন্য এই প্রযুক্তি পাওয়ার সময় এসেছে। এবং সেই কারণেই আমাদের একটি ওপেন সোর্স কোর রয়েছে। আমাদের একটি ইন্টারফেস অংশ আছে যা ওপেন সোর্স নয়। এটি সেই প্ল্যাটফর্ম যা আমরা দেখাব। তবে আমরা চাই এটি সবার কাছে অ্যাক্সেসযোগ্য হোক। আমরা একটি বিপ্লব করতে চাই যাতে সমস্ত পরীক্ষক ল্যাপটপে অনুমান করা বন্ধ করে। আমাদের SELECT লিখতে হবে এবং অবিলম্বে দেখতে হবে যে এটি ধীর। এটি সম্পর্কে আপনাকে বলার জন্য DBA অপেক্ষা করা বন্ধ করুন। এখানেই মূল লক্ষ্য। এবং আমি মনে করি যে আমরা সবাই এটিতে আসব। এবং আমরা প্রত্যেকের জন্য এই জিনিস তৈরি. অতএব ZFS, কারণ এটি সর্বত্র উপলব্ধ হবে। সমস্যা সমাধানের জন্য এবং একটি ওপেন সোর্স লাইসেন্স ইত্যাদি থাকার জন্য সম্প্রদায়কে ধন্যবাদ।*

শুভেচ্ছা! প্রতিবেদনের জন্য ধন্যবাদ! আমার নাম ম্যাক্সিম। আমরা একই বিষয় নিয়ে কাজ করেছি। তারা নিজেরাই সিদ্ধান্ত নিয়েছে। আপনি কিভাবে এই ক্লোনগুলির মধ্যে সম্পদ ভাগ করবেন? প্রতিটি ক্লোন যেকোন সময়ে তার নিজস্ব কাজ করতে পারে: একজন একটি জিনিস পরীক্ষা করে, অন্যটি অন্যটি, কেউ একটি সূচক তৈরি করে, কেউ একটি ভারী কাজ করে। এবং যদি আপনি এখনও CPU দ্বারা ভাগ করতে পারেন, তাহলে IO দ্বারা, আপনি কীভাবে ভাগ করবেন? এই প্রথম প্রশ্ন.

এবং দ্বিতীয় প্রশ্নটি স্ট্যান্ডের ভিন্নতা সম্পর্কে। ধরা যাক আমার এখানে ZFS আছে এবং সবকিছুই দুর্দান্ত, কিন্তু প্রোডের ক্লায়েন্টের ZFS নেই, কিন্তু ext4, উদাহরণস্বরূপ। এই ক্ষেত্রে কিভাবে?

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

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

আমার দুটি প্রশ্ন আছে। এই খুব শান্ত জিনিস. ক্রেডিট কার্ড নম্বরের মতো প্রোডাকশন ডেটা ক্রিটিক্যাল, এমন কিছু ঘটনা আছে কি? ইতিমধ্যে কিছু প্রস্তুত আছে নাকি এটি একটি পৃথক কাজ? এবং দ্বিতীয় প্রশ্ন - MySQL এর জন্য এরকম কিছু আছে কি?

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

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

কিন্তু যেহেতু সিস্টেমটি এক্সটেনসিবল, তাই এটি MySQL এর জন্যও ব্যবহার করা যেতে পারে। এবং যেমন উদাহরণ আছে. ইয়ানডেক্সের একটি অনুরূপ জিনিস আছে, কিন্তু তারা এটি কোথাও প্রকাশ করে না। তারা Yandex.Metrica এর ভিতরে এটি ব্যবহার করে। এবং MySQL সম্পর্কে শুধু একটি গল্প আছে। কিন্তু প্রযুক্তি একই, ZFS.

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

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

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

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

প্রতিবার সূচক তৈরি হবে?

আপনি এটি তৈরি করতে পারেন যাতে আমরা ডেটা স্পর্শ করি, স্ন্যাপশট তৈরি করি, তারপর আমরা এই স্ন্যাপশট থেকে পুনরুদ্ধার করব এবং নতুন অনুরোধগুলি চালাব। অর্থাৎ, আপনি এটি তৈরি করতে পারেন যাতে আপনি ইতিমধ্যে সংযুক্ত সূচকগুলির সাথে নতুন ক্লোনগুলি বাড়াতে পারেন।

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

এখানে আরেকটি সমস্যা। আপনি যদি ক্লাউড সলিউশন ব্যবহার করেন, তাহলে সেখানে শুধুমাত্র লজিক্যাল ডাম্প পাওয়া যায়, কারণ Google, Amazon আপনাকে ফিজিক্যাল কপি নিতে দেয় না। সমস্যা হবে।

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

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

তারা যাবে না কারণ এভাবেই ZFS কাজ করে। আমরা ফাইল সিস্টেমের পরিবর্তনগুলিকে একটি থ্রেডে আলাদাভাবে রাখতে পারি যা প্রতিলিপির কারণে আসে। এবং ডেভেলপাররা ডেটার পুরানো সংস্করণগুলিতে যে ক্লোনগুলি ব্যবহার করে সেগুলি রাখুন৷ এবং এটা আমাদের জন্য কাজ করে, সবকিছু এই সঙ্গে ক্রমানুযায়ী হয়.

এটা দেখা যাচ্ছে যে আপডেটটি একটি অতিরিক্ত স্তর হিসাবে সঞ্চালিত হবে, এবং সমস্ত নতুন ছবি ইতিমধ্যেই যাবে, এই স্তরের উপর ভিত্তি করে, তাই না?

পূর্ববর্তী স্তরগুলি থেকে যা পূর্ববর্তী প্রতিলিপিগুলি থেকে ছিল৷

পূর্ববর্তী স্তরগুলি পড়ে যাবে, তবে তারা পুরানো স্তরটিকে উল্লেখ করবে এবং তারা কি আপডেটে প্রাপ্ত শেষ স্তর থেকে নতুন ছবি নেবে?

সাধারণভাবে, হ্যাঁ।

তারপর ফলস্বরূপ আমাদের একটি ডুমুর পর্যন্ত স্তর থাকবে। এবং সময়ের সাথে সাথে তাদের সংকুচিত হতে হবে?

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

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

এটা যে মত. উদাহরণ স্বরূপ, আমরা লিখতে পারি: "SELECT FROM WHERE email = to that"। অর্থাৎ, আমরা ডেটা নিজেই দেখতে পাব না, তবে আমরা কিছু পরোক্ষ লক্ষণ দেখতে পাব। এই বুঝতে হবে. কিন্তু অন্যদিকে, এটা সব আছে. আমাদের একটি লগ অডিট আছে, আমাদের অন্যান্য সহকর্মীদের নিয়ন্ত্রণ আছে যারা ডেভেলপাররা কী করছেন তাও দেখেন। এবং যদি কেউ এটি করার চেষ্টা করে, তবে নিরাপত্তা পরিষেবা তাদের কাছে এসে এই বিষয়ে কাজ করবে।

শুভ অপরাহ্ন প্রতিবেদনের জন্য ধন্যবাদ! আমি একটি ছোট প্রশ্ন আছে. যদি কোম্পানী স্ল্যাক ব্যবহার না করে, তাহলে কি এখন এটির সাথে কোন বাঁধাই আছে, বা ডেভেলপারদের পক্ষে ডেটাবেসের সাথে একটি পরীক্ষামূলক অ্যাপ্লিকেশন সংযোগ করার জন্য দৃষ্টান্ত স্থাপন করা কি সম্ভব?

এখন স্ল্যাকের একটি লিঙ্ক রয়েছে, অর্থাৎ অন্য কোনো মেসেঞ্জার নেই, তবে আমি সত্যিই অন্যান্য মেসেঞ্জারদের জন্যও সমর্থন করতে চাই। আপনি কি করতে পারেন? আপনি জো ছাড়াই DB ল্যাব স্থাপন করতে পারেন, REST API এর সাহায্যে বা আমাদের প্ল্যাটফর্মের সাহায্যে যান এবং ক্লোন তৈরি করতে পারেন এবং PSQL এর সাথে সংযোগ করতে পারেন। কিন্তু এটি করা যেতে পারে যদি আপনি আপনার ডেভেলপারদের ডেটা অ্যাক্সেস দিতে প্রস্তুত থাকেন, কারণ সেখানে আর কোনো স্ক্রিন থাকবে না।

আমার এই স্তরের দরকার নেই, তবে আমার এমন একটি সুযোগ দরকার।

তারপর হ্যাঁ, এটা করা যেতে পারে.

উত্স: www.habr.com