আপনি বড় হওয়ার সাথে সাথে আপনার ডাটাবেসকে সহজতর করার জন্য সহজ টিপস

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

আমি এটা বলতে পারি কারণ এখানে হানিব্যাজারে, আমরা এমন কিছু কাজ করেছি যা আমাদের জীবনকে যা হওয়ার চেয়ে অনেক কঠিন করে তুলেছে। আমরা কয়েকটি মূল পয়েন্ট বুঝতে পারলে স্কেলিং অনেক কম বেদনাদায়ক হত।

UUID ব্যবহার করুন

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

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

প্রাথমিক কী হিসাবে UUID ব্যবহার করা এই সমস্যাটিকে পাশ কাটিয়ে যায়। আপনি যদি তাদের সাথে পরিচিত না হন তবে UUID হল অনন্য শনাক্তকারী যা দেখতে এইরকম:123e4567-e89b-12d3-a456-426655440000 .

এখানে উইকিপিডিয়া কিভাবে তাদের বর্ণনা করে:

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

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

আপনি যখন প্রাথমিক কী হিসাবে UUID ব্যবহার করেন, তখন সমস্ত লেখাকে আর একটি ডাটাবেসের মধ্য দিয়ে যেতে হবে না। পরিবর্তে আপনি অনেক সার্ভার জুড়ে তাদের ছড়িয়ে দিতে পারেন.

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

Rails অ্যাপে ডিফল্টরূপে UUID সক্রিয় করা সহজ। শুধু কনফিগার ফাইল সম্পাদনা করুন:

# config/application.rb
config.active_record.primary_key = :uuid

আপনি রেল মাইগ্রেশন সহ একটি পৃথক টেবিলের জন্য UUID ব্যবহার করতে পারেন:

create_table :users, id: :uuid do |t|
  t.string :name
end

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

গণনা এবং কাউন্টার

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

কাউন্টারে দুটি স্কেলিং সমস্যা রয়েছে:

1. ডাটাবেস প্রশ্ন যেমন select count(*) from users সহজাতভাবে ধীর হয় তারা আক্ষরিক অর্থে তাদের ফলাফল তৈরি করতে রেকর্ডসেটের প্রতিটি রেকর্ডের মধ্য দিয়ে লুপ করে। আপনার যদি এক মিলিয়ন রেকর্ড থাকে তবে এটি কিছুটা সময় নেবে।
2. "কাউন্টার ক্যাশে" ব্যবহার করে কাউন্টারকে গতি বাড়ানোর প্রচেষ্টা কাজ করে, কিন্তু তারা অনেক ডাটাবেস সার্ভারে লেখা ছড়িয়ে দেওয়ার আপনার ক্ষমতাকে সীমিত করে।

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

উদাহরণস্বরূপ, আপনি গণনার পরিবর্তে তারিখ-পরিসর অনুসারে পৃষ্ঠা বেছে নিতে পারেন। আপনি হয়ত একটি মৃদু-উপযোগী পরিসংখ্যান না দেখানোর জন্য বেছে নিতে পারেন যা পরবর্তীতে তৈরি করা নারকীয় হবে। আপনি ধারণা পেতে.

মেয়াদ উত্তীর্ণ ও গুদামজাতকরণ ডেটা

আপনার কাছে যে পরিমাণ RAM, CPU এবং ডিস্ক IO আছে তা দিয়ে আপনি একটি পোস্টগ্রেস টেবিলে কতটা ডেটা সংরক্ষণ করতে পারেন তার একটি উচ্চ সীমা রয়েছে। এর মানে এমন একটি বিন্দু আসবে যখন আপনাকে আপনার প্রধান টেবিল থেকে বাসি ডেটা সরাতে হবে।

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

আপনি যদি আগে কখনো এই সমস্যাটির সাথে মোকাবিলা না করে থাকেন তাহলে আপনি এইরকম কিছু করতে প্রলুব্ধ হতে পারেন:

MyRecords.where("created_at < ?", 1.year.ago).destroy

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

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

আপনি যদি এগিয়ে পরিকল্পনা পরিচালনা করেন তবে একটি সহজ সমাধান রয়েছে। শুধু আপনার টেবিল পার্টিশন. আপনার সমস্ত ডেটা my_records-এ লেখার পরিবর্তে আপনি my_records_1-এ এই সপ্তাহের ডেটা লেখেন এবং পরবর্তী সপ্তাহের ডেটা my_records_2-এ . গত সপ্তাহের মুছে ফেলার সময় হলে, শুধু drop table my_records_1 ছেড়ে দিন . মুছে ফেলার বিপরীতে, এই প্রশ্নটি খুব দ্রুত সম্পন্ন হয়।

তারিখ ব্যতীত অন্যান্য ক্ষেত্রেও বিভাজন করা সম্ভব। যাই হোক না কেন আপনার ব্যবহারের ক্ষেত্রে অর্থপূর্ণ.

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

পার্টিং শব্দ

পরের বার যখন আপনি নিজেকে স্ক্র্যাচ থেকে একটি প্রকল্প তৈরি করতে দেখবেন, আমি আপনাকে স্কেলিং সম্পর্কে চিন্তা করার জন্য কয়েক মুহূর্ত নিতে উত্সাহিত করব। এটা উপর আবেশ না. HAML বা ERB ব্যবহার করবেন কিনা তা নিয়ে চিন্তায় দিন কাটাবেন না। তবে নিজেকে জিজ্ঞাসা করুন যদি এমন কোনও সহজ জয় নেই যা আপনি কেবল আগাম পরিকল্পনা করে নিতে পারেন।