د میسنجر ډیټابیس (دوهمه برخه): د "ګټې لپاره" ویشل

موږ په بریالیتوب سره د لیکونو ذخیره کولو لپاره زموږ د PostgreSQL ډیټابیس جوړښت ډیزاین کړی، یو کال تیر شوی، کاروونکي یې په فعاله توګه ډکوي، او اوس دا لري ملیونونه ریکارډونه، او ... یو څه ورو پیل شو.

• 1 برخه: د بنسټ چوکاټ ډیزاین کول
• 2 برخه: د "ګټې لپاره" برخه

چې ده لکه څنګه چې د میز اندازه وده کوي، نو د شاخصونو "ژورتیا" هم کوي. - که څه هم په لوګاریتمیک ډول. مګر د وخت په تیریدو سره دا سرور مجبوروي چې ورته لوستل / لیکلو دندې ترسره کړي د معلوماتو څو ځله ډیر پاڼې پروسس کړئد پیل په پرتله.

دا هغه ځای دی چې د ژغورنې لپاره راځي قطع کول.

اجازه راکړئ یادونه وکړم چې موږ د شارډینګ په اړه خبرې نه کوو ، دا د مختلف ډیټابیسونو یا سرورونو ترمینځ ډیټا توزیع کول دي. ځکه چې حتی د معلوماتو ویشل څو سرورونه، تاسو به د وخت په تیریدو سره د شاخصونو "پړسوب" له ستونزې څخه خلاص نه شئ. دا روښانه ده چې که تاسو کولی شئ هره ورځ یو نوی سرور په کار واچوئ، نو ستاسو ستونزې به نور د یو ځانګړي ډیټابیس په الوتکه کې پاتې نشي.

موږ به "په هارډویر کې" د تقسیم کولو پلي کولو لپاره ځانګړي سکریپټونه په پام کې ونیسو، مګر پخپله طریقه - څه او څنګه باید "په ټوټو کې پرې شي"، او دا ډول غوښتنې څه لامل کیږي.

مفهوم

راځئ چې یو ځل بیا خپل هدف تعریف کړو: موږ غواړو ډاډ ترلاسه کړو چې نن، سبا، او په یو کال کې، د هرې لوستلو / لیکلو عملیاتو په جریان کې د PostgreSQL لخوا لوستل شوي ډاټا اندازه تقریبا ورته پاتې کیږي.

د هر چا لپاره په تاریخي ډول راټول شوي معلومات (پیغامونه، سندونه، لاګونه، آرشیفونه، ...) د ویشلو کیلي په توګه طبیعي انتخاب دی د پیښې نیټه / وخت. زموږ په قضیه کې، دا ډول پیښه ده د پیغام لیږلو شیبه.

په یاد ولرئ چې کاروونکي تقریبا تل یوازې د "وروستیو" سره کار وکړئ دا ډول معلومات - دوی وروستي پیغامونه لولي، وروستي لاګونه تحلیلوي، ... نه، البته، دوی کولی شي د وخت په تیریدو سره نور بیرته وګرځي، مګر دوی دا خورا لږ ترسره کوي.

له دې خنډونو څخه دا روښانه ده چې د پیغام غوره حل به وي "ورځنۍ" برخې - په هرصورت ، زموږ کارونکي به نږدې تل هغه څه ولولي چې هغه ته "نن" یا "پرون" راغلی.

که موږ د ورځې په اوږدو کې تقریبا یوازې په یوه برخه کې لیکل او لوستل کوو، نو دا هم موږ ته راکوي د حافظې او ډیسک ډیر اغیزمن کارول - ځکه چې ټولې برخې شاخصونه په اسانۍ سره په RAM کې فټ کیږي، د میز په اوږدو کې د "لوی او غوړ" برعکس.

ګام-by-ګام

په عموم کې، پورته ذکر شوي هرڅه د یوې دوامداره ګټې په څیر ښکاري. او دا د لاسته راوړلو وړ دی، مګر د دې لپاره موږ باید سخته هڅه وکړو - ځکه د یوې ادارې د ویشلو پریکړه د اړوندو "لید" اړتیا ته الر پیدا کوي.

پیغام، د هغې ځانګړتیاوې او اټکلونه

له هغه وخته چې موږ پریکړه وکړه چې پیغامونه د نیټې له مخې پرې کړو، دا معنی لري چې د ادارو ملکیتونه هم وویشل شي چې په دوی پورې اړه لري (نصل شوي فایلونه، د ترلاسه کونکو لیست)، او همدارنګه د پیغام نیټې له مخې.

څرنګه چې زموږ یوه عادي دنده په دقیقه توګه د پیغام راجسترونو لیدل دي (نه لوستل شوي، راتلونکی، ټول)، دا هم منطقي ده چې د پیغام نیټې په واسطه ویشلو ته "دوی په نښه کړئ".

موږ ټولو جدولونو ته د تقسیم کولو کیلي (د پیغام نیټه) اضافه کوو: ترلاسه کونکي ، فایل ، راجسټرې. تاسو اړتیا نلرئ دا پخپله پیغام کې اضافه کړئ، مګر د موجوده نیټې وخت وکاروئ.

تارونو

څرنګه چې د څو پیغامونو لپاره یوازې یوه موضوع شتون لري، په ورته ماډل کې د "کټ" کولو لپاره هیڅ لاره نشته؛ تاسو باید په بل څه تکیه وکړئ. زموږ په قضیه کې دا مثالی دی په لیک کې د لومړي پیغام نیټه - دا د تخلیق شیبه ده، په حقیقت کې، د موضوع.

ټولو جدولونو ته د تقسیم کولو کیلي (د موضوع نیټه) اضافه کړئ: موضوع، برخه اخیستونکی.

مګر اوس موږ په یو وخت کې دوه ستونزې لرو:

• په کومه برخه کې باید د موضوع په اړه پیغامونه وګورم؟
• په کومه برخه کې باید د پیغام څخه موضوع وګورم؟

موږ کولی شو، البته، په ټولو برخو کې لټون ته دوام ورکړو، مګر دا به خورا غمجن وي او زموږ ټولې بریاوې به رد کړي. له همدې امله، د دې لپاره چې پوه شو چې په ریښتیا چیرته ګورو، موږ به برخو ته منطقي لینکونه / اشارې جوړ کړو:

• موږ به په پیغام کې اضافه کړو د موضوع نیټې ساحه
• راځئ چې موضوع ته اضافه کړو د پیغام نیټه ټاکل دا لیکنه (کیدای شي یو جلا میز وي، یا د نیټې لړۍ وي)

څرنګه چې د هر انفرادي لیک لپاره د پیغام نیټې لیست کې لږ بدلونونه شتون لري (په هرصورت، نږدې ټول پیغامونه په 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