میسنجر ڈیٹا بیس (حصہ 2): "منافع کے لیے" تقسیم کرنا

ہم نے خط و کتابت کو ذخیرہ کرنے کے لیے اپنے PostgreSQL ڈیٹا بیس کا ڈھانچہ کامیابی کے ساتھ ڈیزائن کیا ہے، ایک سال گزر چکا ہے، صارفین اسے فعال طور پر بھر رہے ہیں، اور اب اس میں لاکھوں ریکارڈ، اور... کچھ سست ہونے لگا۔

• حصہ 1: بیس فریم ڈیزائن کرنا
• حصہ 2: سیکشننگ "منافع کے لیے"

حقیقت یہ ہے کہ ہے جیسے جیسے میز کا سائز بڑھتا ہے، اسی طرح اشاریہ جات کی "گہرائی" بھی بڑھتی ہے۔ - منطقی طور پر۔ لیکن وقت گزرنے کے ساتھ یہ سرور کو وہی پڑھنے/لکھنے کے کام کرنے پر مجبور کرتا ہے۔ ڈیٹا کے کئی گنا زیادہ صفحات پر کارروائی کریں۔شروع کے مقابلے میں.

یہ وہ جگہ ہے جہاں یہ بچاؤ کے لئے آتا ہے۔ سیکشننگ.

میں نوٹ کروں کہ ہم شارڈنگ کے بارے میں بات نہیں کر رہے ہیں، یعنی مختلف ڈیٹا بیس یا سرورز کے درمیان ڈیٹا کی تقسیم۔ یہاں تک کہ ڈیٹا کو تقسیم کرنا کچھ سرورز، آپ کو وقت کے ساتھ ساتھ اشاریہ جات "سوجن" کے مسئلے سے چھٹکارا نہیں ملے گا۔ یہ واضح ہے کہ اگر آپ ہر روز ایک نیا سرور چلانے کی استطاعت رکھتے ہیں، تو آپ کے مسائل اب کسی مخصوص ڈیٹا بیس کے جہاز میں نہیں رہیں گے۔

ہم "ہارڈ ویئر میں" تقسیم کاری کو لاگو کرنے کے لیے مخصوص اسکرپٹ پر غور نہیں کریں گے، بلکہ نقطہ نظر پر غور کریں گے - کیا اور کیسے "ٹکڑوں میں کاٹنا چاہیے"، اور ایسی خواہش کس طرف لے جاتی ہے۔

تصور

آئیے ایک بار پھر اپنے مقصد کی وضاحت کرتے ہیں: ہم اس بات کو یقینی بنانا چاہتے ہیں کہ آج، کل، اور ایک سال میں، کسی بھی پڑھنے/لکھنے کے آپریشن کے دوران PostgreSQL کے ذریعے پڑھے جانے والے ڈیٹا کی مقدار تقریباً ایک جیسی رہے۔

کسی کے لیے تاریخی طور پر جمع کردہ ڈیٹا (پیغامات، دستاویزات، نوشتہ جات، آرکائیوز، ...) تقسیم کی کلید کے طور پر قدرتی انتخاب ہے واقعہ کی تاریخ/وقت. ہمارے معاملے میں، ایسا واقعہ ہے پیغام بھیجنے کا لمحہ.

نوٹ کریں کہ صارفین تقریبا ہمیشہ صرف "تازہ ترین" کے ساتھ کام کریں۔ اس طرح کا ڈیٹا - وہ تازہ ترین پیغامات پڑھتے ہیں، تازہ ترین لاگز کا تجزیہ کرتے ہیں،... نہیں، یقیناً، وہ وقت کے ساتھ مزید پیچھے جا سکتے ہیں، لیکن وہ ایسا بہت کم کرتے ہیں۔

ان رکاوٹوں سے یہ واضح ہے کہ پیغام کا بہترین حل ہوگا۔ "روزانہ" حصے - بہر حال، ہمارا صارف تقریباً ہمیشہ وہی پڑھے گا جو اسے "آج" یا "کل" آیا۔

اگر ہم دن میں تقریباً صرف ایک حصے میں لکھتے اور پڑھتے ہیں، تو یہ بھی ہمیں دیتا ہے۔ میموری اور ڈسک کا زیادہ موثر استعمال - چونکہ تمام سیکشن انڈیکس آسانی سے RAM میں فٹ ہو جاتے ہیں، اس کے برعکس پورے ٹیبل میں "بڑے اور موٹے" والے۔

قدم بہ قدم

عام طور پر، اوپر بتائی گئی ہر چیز ایک مسلسل منافع کی طرح لگتی ہے۔ اور یہ قابل حصول ہے، لیکن اس کے لیے ہمیں سخت کوشش کرنی پڑے گی - کیونکہ ہستیوں میں سے ایک کو تقسیم کرنے کا فیصلہ متعلقہ کو "دیکھا" کرنے کی ضرورت کا باعث بنتا ہے۔.

پیغام، اس کی خصوصیات اور تخمینے۔

چونکہ ہم نے تاریخوں کے حساب سے پیغامات کو کاٹنے کا فیصلہ کیا ہے، اس لیے یہ سمجھ میں آتا ہے کہ ان ہستیوں کو بھی تقسیم کیا جائے جو ان پر منحصر ہیں (منسلک فائلیں، وصول کنندگان کی فہرست) اور پیغام کی تاریخ کے لحاظ سے بھی.

چونکہ ہمارے عام کاموں میں سے ایک پیغام کے رجسٹروں (بغیر پڑھے ہوئے، آنے والے، سبھی) کو درست طریقے سے دیکھنا ہے، اس لیے یہ بھی منطقی ہے کہ پیغام کی تاریخوں کے حساب سے تقسیم میں "ان کو کھینچنا"۔

ہم پارٹیشننگ کلید (پیغام کی تاریخ) کو تمام جدولوں میں شامل کرتے ہیں: وصول کنندگان، فائل، رجسٹریاں۔ آپ کو اسے خود پیغام میں شامل کرنے کی ضرورت نہیں ہے، لیکن موجودہ ڈیٹ ٹائم استعمال کریں۔

Темы

چونکہ متعدد پیغامات کے لیے صرف ایک ہی موضوع ہے، اس لیے اسے ایک ہی ماڈل میں "کاٹنے" کا کوئی طریقہ نہیں ہے؛ آپ کو کسی اور چیز پر انحصار کرنا ہوگا۔ ہمارے معاملے میں یہ مثالی ہے۔ خط و کتابت میں پہلے پیغام کی تاریخ - یعنی تخلیق کا لمحہ، حقیقت میں، موضوع کا۔

تمام جدولوں میں تقسیم کی کلید (موضوع کی تاریخ) شامل کریں: موضوع، شریک۔

لیکن اب ہمارے پاس بیک وقت دو مسائل ہیں:

• میں کس سیکشن میں موضوع پر پیغامات تلاش کروں؟
• مجھے کس سیکشن میں میسج سے موضوع تلاش کرنا چاہیے؟

ہم یقیناً تمام حصوں میں تلاش جاری رکھ سکتے ہیں، لیکن یہ بہت افسوسناک ہوگا اور ہماری تمام جیتوں کی نفی کرے گا۔ لہذا، یہ جاننے کے لیے کہ بالکل کہاں دیکھنا ہے، ہم حصوں کے لیے منطقی لنکس/پوائنٹر بنائیں گے:

• ہم پیغام میں شامل کریں گے موضوع کی تاریخ کا میدان
• آئیے موضوع میں اضافہ کرتے ہیں۔ پیغام کی تاریخ مقرر یہ خط و کتابت (ایک علیحدہ میز، یا تاریخوں کی ایک صف ہو سکتی ہے)

چونکہ ہر فرد کے خط و کتابت کے لیے پیغام کی تاریخوں کی فہرست میں کچھ تبدیلیاں ہوں گی (آخر کار، تقریباً تمام پیغامات 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
);

ایک خوبصورت پیسہ بچائیں۔

ٹھیک ہے، اگر ہم استعمال نہیں کرتے تو کیا ہوگا کلاسک سیکشننگ آپشن فیلڈ ویلیو کی تقسیم کی بنیاد پر (ٹرگرز اور وراثت یا PARTITION BY کے ذریعے)، اور ایپلیکیشن کی سطح پر "دستی طور پر"، آپ دیکھیں گے کہ پارٹیشننگ کلید کی قدر پہلے سے ہی ٹیبل کے نام میں محفوظ ہے۔

تو اگر تم ایسے ہو۔ کیا آپ ذخیرہ شدہ ڈیٹا کی مقدار کے بارے میں بہت پریشان ہیں؟، پھر آپ ان "اضافی" فیلڈز سے چھٹکارا حاصل کر سکتے ہیں اور مخصوص جدولوں کو ایڈریس کر سکتے ہیں۔ سچ ہے، اس معاملے میں کئی حصوں سے تمام انتخاب کو درخواست کی طرف منتقل کرنا ہوگا۔

ماخذ: www.habr.com