ميسينجر ڊيٽابيس (حصو 2): ورهاڱي “منافع لاءِ”

اسان خط و ڪتابت کي محفوظ ڪرڻ لاءِ پنهنجي PostgreSQL ڊيٽابيس جي جوڙجڪ کي ڪاميابيءَ سان ترتيب ڏنو آهي، هڪ سال گذري چڪو آهي، صارفين ان کي فعال طور تي ڀري رهيا آهن، ۽ هاڻي ان ۾ شامل آهن لکين رڪارڊ۽... ڪجهه سست ٿيڻ لڳو.

• حصو 1: بنيادي فريم ڊزائين ڪرڻ
• حصو 2: سيڪشننگ "نفعي لاء"

نڪتو ته آهي جيئن ٽيبل جي سائيز وڌي ٿي، تيئن انڊيڪس جي ”گہرا“ به ٿيندي آهي. - جيتوڻيڪ logarithmically. پر وقت سان گڏ اهو سرور کي ساڳيو پڙهڻ/لکڻ جي ڪمن کي انجام ڏيڻ تي مجبور ڪري ٿو ڊيٽا جا ڪيترائي ڀيرا وڌيڪ صفحا پروسيس ڪريوشروعات جي ڀيٽ ۾.

اهو آهي جتي اهو بچاء لاء اچي ٿو سيڪشن ڪرڻ.

مون کي نوٽ ڪرڻ ڏيو ته اسان شارڊنگ جي باري ۾ نه ڳالهائي رهيا آهيون، اهو آهي، مختلف ڊيٽابيس يا سرور جي وچ ۾ ڊيٽا کي ورهائڻ. ڇو ته ڊيٽا کي به ورهائڻ ۾ ڪيترن سرورز، توهان انڊيڪس جي مسئلي کان نجات حاصل نه ڪندا "سوجن" وقت سان. اهو واضح آهي ته جيڪڏهن توهان برداشت ڪري سگهو ٿا هڪ نئون سرور هر روز آپريشن ۾، پوء توهان جا مسئلا هاڻي ڪنهن خاص ڊيٽابيس جي جهاز ۾ ڪوڙ نه هوندا.

اسان "هارڊويئر ۾" ورهاڱي کي لاڳو ڪرڻ لاء مخصوص اسڪرپٽ تي غور نه ڪنداسين، پر اهو طريقو آهي - ڇا ۽ ڪيئن "ڪٽ ۾ ڪٽڻ" گهرجي، ۽ اهڙي خواهش ڪهڙي طرف وٺي ٿي.

تصور

اچو ته اسان جو مقصد هڪ ڀيرو ٻيهر بيان ڪريون: اسان پڪ ڪرڻ چاهيون ٿا ته اڄ، سڀاڻي، ۽ هڪ سال ۾، ڪنهن به پڙهڻ/لکڻ جي آپريشن دوران PostgreSQL پاران پڙهيل ڊيٽا جي مقدار لڳ ڀڳ ساڳي رهي.

ڪنهن به لاء chronologically گڏ ڪيل ڊيٽا (پيغام، دستاويز، لاگز، آرڪائيوز، ...) قدرتي چونڊ هڪ ورهاڱي واري چاٻي جي طور تي آهي. واقعي جي تاريخ/وقت. اسان جي صورت ۾، هڪ اهڙي واقعي آهي پيغام موڪلڻ جو لمحو.

نوٽ ڪريو ته صارفين تقريبا هميشه صرف "تازو" سان ڪم ڪريو اهڙي ڊيٽا - اهي تازه ترين پيغام پڙهندا آهن، تازه ترين لاگز جو تجزيو ڪن ٿا، ... نه، يقينا، اهي وقت ۾ وڌيڪ پوئتي اسڪرال ڪري سگهن ٿا، پر اهي اهو تمام گهٽ ڪن ٿا.

انهن رڪاوٽن مان اهو واضح ٿئي ٿو ته بهترين پيغام جو حل هوندو "روزاني" سيڪشن - سڀ کان پوء، اسان جو صارف تقريبا هميشه پڙهي سگهندو جيڪو هن وٽ آيو آهي "اڄ" يا "ڪالهه".

جيڪڏهن اسان ڏينهن ۾ لڳ ڀڳ صرف هڪ حصي ۾ لکي ۽ پڙهون ٿا، ته اهو پڻ اسان کي ڏئي ٿو ميموري ۽ ڊسڪ جو وڌيڪ موثر استعمال - جيئن ته سڀئي سيڪشن انڊيڪس آسانيءَ سان رام ۾ فٽ ٿين ٿا، ان جي ابتڙ ”وڏيون ۽ ٿلهيون“ وارين ٽيبل تي.

قدم به قدم

عام طور تي، مٿي بيان ڪيل هر شيء هڪ مسلسل منافعي وانگر آواز آهي. ۽ اهو حاصل ڪري سگهجي ٿو، پر ان لاء اسان کي سخت ڪوشش ڪرڻو پوندو - ڇاڪاڻ ته ھڪڙي اداري کي ورهائڻ جو فيصلو ان سان لاڳاپيل "ڏسڻ" جي ضرورت آھي.

پيغام، ان جي ملڪيت ۽ تخميني

جيئن ته اسان تاريخن ذريعي پيغامن کي ڪٽڻ جو فيصلو ڪيو آهي، ان ڪري اهو سمجھ ۾ اچي ٿو ته انهن ادارن جي ملڪيتن کي به ورهايو وڃي جيڪي انهن تي منحصر آهن (منسلڪ فائلون، وصول ڪندڙن جي فهرست)، ۽ پڻ پيغام جي تاريخ طرفان.

جيئن ته اسان جي عام ڪمن مان هڪ صحيح طور تي پيغام جي رجسٽرن کي ڏسڻ آهي (اڻ پڙهيل، ايندڙ، سڀ)، اهو پڻ منطقي آهي ته "انهن کي اندر آڻيو" پيغام جي تاريخن جي ورهاڱي ۾.

اسان سڀني جدولن ۾ ورهاڱي واري ڪي (پيغام جي تاريخ) شامل ڪندا آهيون: وصول ڪندڙ، فائل، رجسٽري. توهان کي ان کي پيغام ۾ شامل ڪرڻ جي ضرورت ناهي، پر موجوده 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
);

هڪ خوبصورت پئسو بچايو

خير، جيڪڏھن اسان استعمال نه ڪندا آھن کلاسي سيڪشن جا اختيار فيلڊ جي قدرن جي ورڇ جي بنياد تي (ٽريگرز ۽ وراثت يا PARTITION BY ذريعي)، ۽ ايپليڪيشن جي سطح تي "دستي طور تي"، توهان کي خبر پوندي ته ورهاڱي واري چيڪ جي قيمت اڳ ۾ ئي ٽيبل جي نالي ۾ محفوظ ٿيل آهي.

پوء جيڪڏھن تون ائين آھين ڇا توهان تمام گهڻو پريشان آهيو ڊيٽا جي ذخيرو بابت؟، پوءِ توھان حاصل ڪري سگھوٿا انھن ”اضافي“ شعبن مان ۽ پتو مخصوص جدولن کي. سچ، هن معاملي ۾ ڪيترن ئي حصن مان سڀئي چونڊون ايپليڪيشن واري پاسي ڏانهن منتقل ٿيڻ گهرجن.

جو ذريعو: www.habr.com