Datenbank des Messengers (Teil 1): Rahmen der Datenbank entwerfen

Wie man Geschäftsanforderungen in konkrete Datenstrukturen überträgt, am Beispiel der Gestaltung einer Datenbank für einen Messenger „von Grund auf“.

• Teil 1: Gestalten des Datenbankgerüsts
• Teil 2: Sektionierung „live“

Unsere Datenbank wird nicht so umfangreich und verteilt sein, wie bei VKontakte oder Badoo, sondern „nur damit es da ist“, doch es soll gut sein – funktional, schnell und auf einem Server Platz finden PostgreSQL – damit man einen separaten Dienst-Exemplar irgendwo an der Seite bereitstellen kann, zum Beispiel.

Deshalb werden wir die Fragen der Sharding, Replikation und geo-verteilten Systeme nicht behandeln, sondern uns auf schematische Lösungen innerhalb der DB konzentrieren.

Schritt 1: Etwas geschäftsspezifisches

Unser Nachrichtenaustausch wird nicht abstrakt entworfen, sondern in die Umgebung der Unternehmens-Sozialen Netzwerkeeingebettet. Das heißt, die Menschen „unterhalten sich“ nicht einfach, sondern kommunizieren im Kontext der Lösung bestimmter geschäftlicher Aufgaben.

Und welche Aufgaben gibt es im Geschäft?.. Schauen wir uns das am Beispiel von Wladimir – dem Leiter der Entwicklungsabteilung – an.

• „Nikolaj, für diese Aufgabe wird das Patch schon heute benötigt!“
  Das heißt, die Korrespondenz kann im Kontext eines des Dokuments.
• „Kola, lass am Abend in Dota gehen?“
  Das bedeutet, dass selbst bei einem Paar Gesprächspartner die Kommunikation gleichzeitig über verschiedene Themen geführt werden kann.
• „Peter, Nikolaj, schaut euch im Anhang den Preis für den neuen Server an.“
  So kann eine Nachricht mehrere Empfänger haben.Dabei kann die Nachricht anhängende Dateien enthalten.
• „Semen, schau du auch mal.“
  Und es muss möglich sein, einen neuen Teilnehmer in eine bereits bestehende Korrespondenz einzuladen..

Lassen Sie uns vorerst bei dieser Liste der „offensichtlichen“ Bedürfnisse bleiben.

Ohne das Verständnis der anwendungsbezogenen Spezifik der Aufgabe und der damit verbundenen Einschränkungen ist es praktisch unmöglich, eine effektive Datenbankschema für ihre Lösung zu entwerfen.

Schritt 2: Minimales logisches Schema

Schematisch sieht es bisher sehr ähnlich aus wie bei E-Mail-Korrespondenz – einem traditionellen Geschäftsinstrument. Tatsächlich sind viele geschäftliche Aufgaben „algorithmisch“ einander ähnlich, weshalb auch die Instrumente zu ihrer Lösung strukturell ähnlich sein werden.

Lassen Sie uns das bereits erhaltene logische Schema der Beziehungen der Entitäten festhalten. Zur Vereinfachung unserer Modellssicht verwenden wir die einfachste Variante der Darstellung ER-Modells ohne Komplikationen durch UML oder IDEF-Notationen:

In unserem Beispiel sind die Person, das Dokument und der binäre „Körper“ der Datei externe Entitäten, die unabhängig von unserem Dienst existieren. Daher werden wir sie in Zukunft einfach als Links „irgendwohin“ nach UUID betrachten.

Zeichnen Sie Diagramme so einfach wie möglich — die meisten von denen, denen Sie sie zeigen werden, sind keine Experten im Lesen von UML/IDEF. Aber — zeichnen Sie es auf jeden Fall.

Schritt 3: Skizzieren Sie die Struktur der Tabellen

Über die Namen von Tabellen und FeldernZu den „russischen“ Bezeichnungen von Feldern und Tabellen kann man unterschiedlich stehen, aber das ist Geschmackssache. Da wir in „Tensor“ keine ausländischen Entwickler haben und PostgreSQL es uns erlaubt, Namen sogar mit Hieroglyphen zu geben, wenn sie in Anführungszeichen gesetzt sind, ziehen wir es vor, Objekte eindeutig und klar zu benennen, um Missverständnisse zu vermeiden.
Da viele Menschen gleichzeitig Nachrichten schreiben, können einige dies sogar im Offline-Modus, ist die einfachste Variante — UUIDs als Identifikatoren zu verwenden nicht nur für externe Entitäten, sondern auch für alle Objekte innerhalb unseres Dienstes. Außerdem können sie sogar auf der Client-Seite generiert werden — das hilft uns, den Versand von Nachrichten bei kurzfristiger Nichtverfügbarkeit der Datenbank aufrechtzuerhalten, und die Wahrscheinlichkeit einer Kollision ist extrem gering.

Die grobe Struktur der Tabellen in unserer Datenbank wird folgendermaßen aussehen:
Tabellen : RU

CREATE TABLE "Thema"(
  "Thema"
    uuid
      PRIMARY KEY
, "Dokument"
    uuid
, "Titel"
    text
);

CREATE TABLE "Nachricht"(
  "Nachricht"
    uuid
      PRIMARY KEY
, "Thema"
    uuid
, "Autor"
    uuid
, "DatumUhrzeit"
    timestamp
, "Text"
    text
);

CREATE TABLE "Adressat"(
  "Nachricht"
    uuid
, "Person"
    uuid
, PRIMARY KEY("Nachricht", "Person")
);

CREATE TABLE "Datei"(
  "Datei"
    uuid
      PRIMARY KEY
, "Nachricht"
    uuid
, "BLOB"
    uuid
, "Name"
    text
);

Tabellen : 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
);

Das Einfachste bei der Beschreibung des Formats ist, mit den „verknüpften“ Beziehungen von Tabellen zu beginnen, die sich nicht auf niemanden beziehen.

Schritt 4: Unklarheiten ermitteln

Alles, wir haben eine Datenbank entworfen, in die man hervorragend schreiben kann und irgendwie lesen.

Lassen Sie uns in die Rolle des Nutzers unseres Dienstes schlüpfen – was möchten wir mit ihm erreichen?

• Letzte Nachrichten
  Das ist chronologisch sortiert nach verschiedenen Kriterien das Register „meiner“ Nachrichten. Wo ich einer der Adressaten bin, wo ich der Autor bin, wo mir geschrieben wurde, aber ich nicht geantwortet habe, wo ich keine Antwort erhalten habe, …
• Teilnehmer der Korrespondenz
  Wer nimmt eigentlich an diesem langen, langen Chat teil?

Unsere Struktur ermöglicht es, beide Aufgaben „überhaupt“ zu lösen, aber schnell – nein. Das Problem ist, dass es für die Sortierung im Rahmen der ersten Aufgabe unmöglich ist, einen Index zu erstellen,, der für jeden der Teilnehmer geeignet ist (und wir müssen alle Einträge abrufen), und zur Lösung der zweiten Aufgabe ist es notwendig, alle Nachrichten zum Thema abzurufen.

Unvorhergesehene Nutzeraufgaben können eine große Belastung für die Leistung darstellen..

Schritt 5: Sinnvolle Denormalisierung

Beide unsere Probleme können mit zusätzlichen Tabellen gelöst werden, in denen wir einen Teil der Daten duplizieren, die für die Bildung geeigneter Indizes für unsere Aufgaben notwendig sind.


Tabellen : RU

CREATE TABLE "NachrichtenRegister"(
  "Besitzer"
    uuid
, "RegisterTyp"
    smallint
, "DatumZeit"
    timestamp
, "Nachricht"
    uuid
, PRIMARY KEY("Besitzer", "RegisterTyp", "Nachricht")
);
CREATE INDEX ON "NachrichtenRegister"("Besitzer", "RegisterTyp", "DatumZeit" DESC);

CREATE TABLE "ThemaTeilnehmer"(
  "Thema"
    uuid
, "Person"
    uuid
, PRIMARY KEY("Thema", "Person")
);

Tabellen : 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)
);

Hier haben wir zwei typische Ansätze angewendet, die bei der Erstellung von Hilfstabellen verwendet werden:

• Multiplikation von Einträgen
  Wir erstellen aus einem einzelnen ursprünglichen Eintrag mehrere Folgeeinträge in verschiedene Arten von Registern für verschiedene Eigentümer – sowohl für den Absender als auch für den Empfänger. So hat nun jeder dieser Register einen Index – denn typischerweise möchten wir nur die erste Seite sehen.
• Eindeutigkeit von Einträgen
  Bei jedem Versand einer Nachricht innerhalb eines bestimmten Themas genügt es zu überprüfen, ob ein solcher Eintrag bereits existiert. Wenn nicht – fügen wir ihn in unser „Wörterbuch“ ein.

Im nächsten Teil des Artikels wird es um die Implementierung von Partitionierung in die Struktur unserer Datenbank gehen.

Quelle: habr.com