মেসেঞ্জার ডাটাবেস (পর্ব 2): "লাভের জন্য" বিভাজন

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

• পার্ট 1: বেস ফ্রেম ডিজাইন করা
• পার্ট 2: বিভাগকরণ "লাভ"

মূল উদ্দেশ্য হল টেবিলের আয়তনের বৃদ্ধির সাথে সাথে সূচকগুলির "গভীরতা"ও বৃদ্ধি পায় - লগারিদমিকভাবে যদিও। কিন্তু সময়ের সাথে সাথে এটি সার্ভারকে একই পড়া/লেখার কাজগুলি করতে বাধ্য করে বহুগুণ বেশি ডেটা পেজ প্রক্রিয়া করুনশুরুতে তুলনায়

এই যেখানে এটি উদ্ধার আসে বিভাগ.

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

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

ধারণা

আবারও, আমরা আমাদের লক্ষ্য সংজ্ঞায়িত করি: আমরা নিশ্চিত করতে চাই যে আজ, আগামীকাল এবং এক বছর পরে, যেকোনো পঠন/রাইট অপারেশনের জন্য PostgreSQL দ্বারা পড়া ডেটার পরিমাণ প্রায় একই থাকে।

কোন জন্য কালানুক্রমিকভাবে সঞ্চিত তথ্য (বার্তা, নথি, লগ, সংরক্ষণাগার, ...) একটি পার্টিশন কী এর জন্য স্বাভাবিক পছন্দ হল ইভেন্টের তারিখ/সময়. আমাদের ক্ষেত্রে, এই ঘটনা বার্তাটি পাঠানোর মুহুর্ত.

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

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

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

ধাপে ধাপে দ্বারা

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

বার্তা, এর বৈশিষ্ট্য এবং অনুমান

যেহেতু আমরা তারিখ অনুসারে বার্তাগুলি কাটার সিদ্ধান্ত নিয়েছি, তাই তাদের উপর নির্ভরশীল সত্তা-সম্পত্তিগুলিকে ভাগ করাও যুক্তিসঙ্গত (সংযুক্ত ফাইল, প্রাপকদের তালিকা), এবং এছাড়াও পোস্ট তারিখ দ্বারা.

যেহেতু আমাদের সাধারণ কাজগুলির মধ্যে একটি হল শুধুমাত্র মেসেজ রেজিস্ট্রিগুলি দেখা (অপঠিত, ইনকামিং, সমস্ত), বার্তা তারিখ অনুসারে সেগুলিকে "আঁকে" দেওয়াও যৌক্তিক৷

আমরা সমস্ত টেবিলে পার্টিশন কী (বার্তা তারিখ) যোগ করি: প্রাপক, ফাইল, রেজিস্ট্রি। আপনি নিজেই বার্তা যোগ করতে পারবেন না, কিন্তু বিদ্যমান DateTime ব্যবহার করুন.

থ্রেড

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

সমস্ত টেবিলে একটি পার্টিশন কী (বিষয় তারিখ) যোগ করুন: বিষয়, সদস্য।

কিন্তু এখন আমাদের একসাথে দুটি সমস্যা আছে:

• কোন বিভাগে বিষয়ের বার্তা খুঁজতে হবে?
• কোন বিভাগে বার্তার বিষয় খুঁজতে হবে?

আপনি, অবশ্যই, সমস্ত বিভাগে অনুসন্ধান চালিয়ে যেতে পারেন, তবে এটি খুব দুঃখজনক হবে এবং আমাদের সমস্ত জয়কে অস্বীকার করবে। অতএব, ঠিক কোথায় দেখতে হবে তা জানার জন্য, আমরা বিভাগগুলিতে লজিক্যাল লিঙ্ক / পয়েন্টার তৈরি করব:

• বার্তা যোগ করুন বিষয় তারিখ ক্ষেত্র
• বিষয় যোগ করুন বার্তা তারিখ সেট এই চিঠিপত্র (আপনি একটি পৃথক টেবিল ব্যবহার করতে পারেন, অথবা আপনি তারিখের অ্যারে ব্যবহার করতে পারেন)

যেহেতু প্রতিটি পৃথক চিঠিপত্রের জন্য বার্তা তারিখের তালিকায় কিছু পরিবর্তন করা হবে (সর্বশেষে, প্রায় সমস্ত বার্তা 1-2 সংলগ্ন দিনে পড়ে), আমি এই বিকল্পটিতে ফোকাস করব।

সামগ্রিকভাবে, আমাদের ডাটাবেসের গঠন বিভাজন বিবেচনা করে নিম্নলিখিত ফর্মটি গ্রহণ করেছে:

টেবিল: RU

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

CREATE TABLE "РеестрСообщений_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений_YYYYMMDD"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "УчастникТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

একটি সুন্দর পয়সা সংরক্ষণ করুন

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

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

উত্স: www.habr.com