મેસેન્જર ડેટાબેઝ (ભાગ 1): આધાર ફ્રેમવર્ક ડિઝાઇન

શરૂઆતથી મેસેન્જર ડેટાબેઝ ડિઝાઇન કરવાના ઉદાહરણનો ઉપયોગ કરીને તમે વ્યવસાયિક આવશ્યકતાઓને વિશિષ્ટ ડેટા સ્ટ્રક્ચર્સમાં કેવી રીતે અનુવાદિત કરી શકો છો.

• ભાગ 1: આધાર ફ્રેમ ડિઝાઇન
• ભાગ 2: "નફા માટે" વિભાગીકરણ

અમારો આધાર એટલો મોટો અને વિતરિત નહીં હોય, જેમ કે VKontakte અથવા 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