Messenger мэдээллийн сан (1-р хэсэг): үндсэн хүрээг зохион бүтээх

Мессенжерийн мэдээллийн санг эхнээс нь зохион бүтээх жишээг ашиглан бизнесийн шаардлагыг тодорхой өгөгдлийн бүтцэд хэрхэн хөрвүүлэх вэ.

• 1-р хэсэг: үндсэн хүрээний загварчлал
• 2-р хэсэг: "ашгийн төлөө" гэсэн хэсэг

Манай бааз тийм ч том биш, тархсан байх болно, ВКонтакте шиг буюу Badoo, гэхдээ "ийм байсан" гэхдээ энэ нь сайн байсан - ажиллагаатай, хурдан бөгөөд нэг серверт багтах PostgreSQL - ингэснээр та үйлчилгээний тусдаа жишээг хаа нэгтээ байрлуулж болно.

Тиймээс бид хуваах, хуулбарлах, гео тархсан системийн асуудлыг хөндөхгүй, харин мэдээллийн сан доторх хэлхээний шийдлүүдэд анхаарлаа хандуулах болно.

Алхам 1: Зарим бизнесийн онцлог

Бид мессежээ хийсвэр байдлаар зохион бүтээхгүй, харин хүрээлэн буй орчинд нэгтгэх болно корпорацийн нийгмийн сүлжээ. Өөрөөр хэлбэл, манайхан “зөвхөн захидал бичдэг” биш, харин бизнесийн тодорхой асуудлуудыг шийдвэрлэх хүрээнд хоорондоо харилцдаг.

Мөн аж ахуйн нэгжийн үүрэг даалгавар юу вэ?.. Хөгжлийн хэлтсийн дарга Василийгийн жишээг авч үзье.

• "Николай, энэ даалгаварт өнөөдөр бидэнд нөхөөс хэрэгтэй!"
  Энэ нь зарим хүмүүсийн хүрээнд захидал харилцааг явуулж болно гэсэн үг юм баримт бичиг.
• "Коля, чи өнөө орой Дота руу явах уу?"
  Өөрөөр хэлбэл, нэг хос ярилцагч ч гэсэн нэгэн зэрэг харилцаж чадна янз бүрийн сэдвээр.
• "Петр, Николай, шинэ серверийн үнийн жагсаалтыг хавсралтаас харна уу."
  Тиймээс нэг мессеж байж болно хэд хэдэн хүлээн авагч. Энэ тохиолдолд мессеж агуулж болно Хавсаргасан файлууд.
• "Семён, бас хараарай."
  Мөн одоо байгаа захидал харилцаанд орох боломж байх ёстой шинэ гишүүн урьж байна.

Одоохондоо энэхүү "илэрхий" хэрэгцээний жагсаалтад анхаарлаа хандуулцгаая.

Асуудлын хэрэглээний онцлог, түүнд өгсөн хязгаарлалтыг ойлгохгүйгээр дизайн хийх үр дүнтэй өгөгдлийн сангийн схем нь үүнийг шийдэх бараг боломжгүй юм.

Алхам 2: Хамгийн бага логик хэлхээ

Одоогийн байдлаар бүх зүйл уламжлалт бизнесийн хэрэгсэл болох цахим шуудангийн захидал харилцаатай маш төстэй болж байна. Тийм ээ, "алгоритмын хувьд" бизнесийн олон асуудлууд бие биетэйгээ төстэй тул тэдгээрийг шийдвэрлэх хэрэгслүүд нь бүтцийн хувьд ижил төстэй байх болно.

Байгууллагын харилцааны аль хэдийн олж авсан логик диаграммыг засъя. Манай загварыг ойлгоход хялбар болгохын тулд бид хамгийн энгийн дэлгэцийн сонголтыг ашиглах болно ER загварууд UML эсвэл IDEF тэмдэглэгээний хүндрэлгүйгээр:

Бидний жишээнд файлын хүн, баримт бичиг, хоёртын "бинар" нь манай үйлчилгээгүйгээр бие даан оршин тогтнох "гадаад" биетүүд юм. Тиймээс бид ирээдүйд тэдгээрийг UUID-ийн "хаа нэгтээ" холбоос гэж үзэх болно.

Зурах диаграммуудыг аль болох энгийн байдлаар харуулах - Таны харуулах хүмүүсийн ихэнх нь UML/IDEF унших мэргэжилтэн биш юм. Гэхдээ зурахаа мартуузай.

Алхам 3: Хүснэгтийн бүтцийг зурах

Хүснэгт болон талбайн нэрсийн тухайТалбай, хүснэгтийн "орос" нэрийг өөр өөрөөр авч үзэж болох боловч энэ нь амтны асуудал юм. Учир нь Энд Тенсорт гадаадын хөгжүүлэгч байхгүй бөгөөд PostgreSQL бидэнд нэрсийг иероглифээр ч өгөх боломжийг олгодог. ишлэлд хавсаргав, дараа нь бид объектуудыг хоёрдмол утгагүй, тодорхой нэрлэхийг илүүд үздэг бөгөөд ингэснээр ямар ч зөрүү гарахгүй.
Олон хүмүүс нэгэн зэрэг бидэнд мессеж бичдэг тул зарим нь үүнийг хийж магадгүй юм офлайн, тэгвэл хамгийн энгийн сонголт UUID-г танигч болгон ашиглах зөвхөн гадны байгууллагуудад төдийгүй манай үйлчилгээний доторх бүх объектуудад зориулагдсан. Нэмж дурдахад тэдгээрийг үйлчлүүлэгчийн талд ч үүсгэж болно - энэ нь мэдээллийн сан түр ажиллах боломжгүй, мөргөлдөх магадлал маш бага үед мессеж илгээхийг дэмжихэд тусална.

Манай мэдээллийн сан дахь ноорог хүснэгтийн бүтэц дараах байдалтай байна.
Хүснэгтүүд: RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

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

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

Хүснэгтүүд: EN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

Форматыг тайлбарлахдаа хамгийн энгийн зүйл бол холболтын графикийг "тайлж" эхлэх явдал юм лавлагаагүй хүснэгтүүдээс өөрсдийгөө хэнд ч биш.

Алхам 4: Тодорхой бус хэрэгцээг олж мэд

Ингээд л та төгс бичих боломжтой мэдээллийн баазыг бүтээв ямар нэгэн байдлаар унших.

Үйлчилгээнийхээ хэрэглэгчийн оронд өөрсдийгөө тавиад үзье - бид үүнийг юу хийхийг хүсч байна вэ?

• Сүүлийн мессежүүд
  энэ он цагийн дарааллаар ангилсан янз бүрийн шалгуурт суурилсан "миний" мессежүүдийн бүртгэл. Би хүлээн авагчдын нэг хаана байна, зохиогч нь хаана байна, тэд надад хаана бичсэн, би хариулаагүй, тэд надад хариулаагүй, ...
• Захидлын оролцогчид
  Энэ урт, урт чатанд хэн оролцож байна вэ?

Манай бүтэц эдгээр хоёр асуудлыг "ерөнхийдөө" шийдвэрлэх боломжийг олгодог, гэхдээ хурдан биш. Асуудал нь эхний ажлын хүрээнд эрэмбэлэх явдал юм индекс үүсгэх боломжгүй, оролцогч тус бүрт тохиромжтой (мөн та бүх бүртгэлийг задлах шаардлагатай болно), хоёрдахь бичлэгийг шийдэхийн тулд танд хэрэгтэй болно. бүх мессежийг задлах энэ сэдвээр.

Хэрэглэгчийн хүсээгүй даалгавар нь тод томруунаар зурж болно бүтээмжтэй холбоотой.

Алхам 5: Ухаалаг хэвийн бус байдал

Бидний хоёр асуудлыг нэмэлт хүснэгтээр шийдэх болно өгөгдлийн хэсгийг хуулбарлах, тэдгээрийн дээр бидний даалгаварт тохирсон индексийг бүрдүүлэх шаардлагатай.


Хүснэгтүүд: RU

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

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

Хүснэгтүүд: EN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

Энд бид туслах хүснэгт үүсгэхэд ашигладаг хоёр энгийн аргыг ашигласан болно.

• Бичлэгүүдийг үржүүлэх
  Нэг мессежийн бичлэгийг ашиглан бид илгээгч болон хүлээн авагчийн хувьд өөр өөр эзэмшигчдэд зориулж өөр өөр төрлийн бүртгэлд хэд хэдэн хяналтын бүртгэлийг үүсгэдэг. Гэхдээ бүртгэл тус бүр индекс дээр унадаг - ердийн тохиолдолд бид зөвхөн эхний хуудсыг харахыг хүсэх болно.
• Өвөрмөц рекордууд
  Тодорхой сэдвийн хүрээнд мессеж илгээх бүртээ ийм оруулга байгаа эсэхийг шалгахад хангалттай. Үгүй бол үүнийг манай "толь бичиг"-т нэмнэ үү.

Өгүүллийн дараагийн хэсэгт бид ярих болно хуваалтын хэрэгжилт манай мэдээллийн сангийн бүтцэд.

Эх сурвалж: www.habr.com