Dane uporządkowane
wokół procesu.

Projektujemy zapis, odczyt i dostęp do danych zgodnie z potrzebami aplikacji.

Dwa uporządkowane zbiory rekordów oraz trzy czerwone warstwy pamięci podręcznej — ilustracja modeli danych

Nie każda informacja potrzebuje tego samego modelu

Różne dane,
różne potrzeby.

Dobieramy technologię do sposobu, w jaki produkt zapisuje i wykorzystuje informacje. Relacje, dokumenty i cache mają różne zadania.

Relacje i transakcje

Struktura i spójnośćPostgreSQL

Model dokumentowy

Elastyczna strukturaMongoDB

Cache i krótkotrwały stan

Szybki dostępRedis

Przykład modelu danych

Ten sam rekord.
Trzy reprezentacje.

Przykład jednego zamówienia. Nie jest to zalecenie utrzymywania tych samych danych we wszystkich trzech bazach.

Zamówienie #10293

Klient: Anna Kowalska
Status: Opłacone
Suma: 399,00 PLN
Właściciel procesu: Dział sprzedaży

Dane demonstracyjne

Relacje — PostgreSQL

zamówienia

id · 10293
klient_id · 15
status · opłacone
suma · 399.00

klienci

id · 15
imię · Anna
nazwisko · Kowalska

zamówienie_id → zamówienia.idpozycje_zamówienia

zamówienie_id · 10293
produkt_id · p1
ilość · 1

Powiązane rekordy, reguły spójności i transakcje.

Dokument — MongoDB

{
  "_id": "10293",
  "klient": {
    "imie": "Anna",
    "nazwisko": "Kowalska"
  },
  "pozycje": [
    { "produkt": "p1", "ilosc": 1 }
  ],
  "status": "oplacone",
  "suma": 399.00
}

Informacje zebrane w dokumencie dopasowanym do odczytu.

Cache — Redis

KEY order:10293:summary

VALUE
{
  "status": "oplacone",
  "suma": 399.00
}

TTL 3600 sekund

Przykładowe podsumowanie z czasem ważności. Nie zastępuje źródła prawdy.

Jeden proces.
Trzy zastosowania.

Łączymy narzędzia wtedy, gdy ich role mają uzasadnienie. Prosty projekt może potrzebować tylko jednej bazy.

PostgreSQLRelacje i transakcjeDokumentacja ↗MongoDBModel dokumentowyDokumentacja ↗RedisCache i krótkotrwały stanDokumentacja ↗

Kopie, uprawnienia
i odtworzenie.

Dane wymagają nie tylko dobrego modelu, ale także kontroli dostępu i sprawdzonego planu odtworzenia.

Role i uprawnienia
Regularne kopie zapasowe
Próba odtworzenia po awarii

Zamówienie #10293Właściciel · zespół · dostęp · audyt

Właściciel

Decyzje i nadawanie dostępu

Zespół

Odczyt lub edycja według roli

Systemy

Wyłącznie wymagane operacje

Model przed migracją

Analizujemy obecny model i zależności. Planujemy zmianę, kontrolę spójności i możliwość bezpiecznego wycofania.

Omówmy migrację Zobacz model

Obecny model

Wspólna baza
Dzisiejsze ograniczenia
Istniejące integracje
Ryzyka zmiany

Docelowy model

Uzgodnione potrzeby
Dopasowana struktura
Plan przeniesienia danych
Kryteria odbioru

Pytania o dane

Kiedy wybrać PostgreSQL, a kiedy MongoDB?

Analizujemy strukturę informacji, relacje, transakcje oraz sposób odczytu i zmiany danych. Model relacyjny i dokumentowy rozwiązuje różne potrzeby; wybór wymaga kontekstu produktu.

Czy cache może zastąpić bazę danych?

Cache zwykle przechowuje wybrane informacje, które można odtworzyć ze źródła. W pokazanym przykładzie Redis przyspiesza odczyt podsumowania; nie przejmuje odpowiedzialności za zapis zamówienia.

Jak wygląda proces migracji danych?

Zaczynamy od inwentaryzacji, kopii i testowego przeniesienia. Sprawdzamy relacje i kompletność danych, dopiero później planujemy właściwe przełączenie i kontrolę po zmianie.