Valg af PostgreSQL frem for MongoDB til nye services
Kontekst
Vi designede en ny service til håndtering af kundeabonnementer med kompleks faktureringslogik. Teamet diskuterede mellem PostgreSQL og MongoDB, som vi havde brugt til andre services.
Beslutning
Bruge PostgreSQL til abonnementsservicen og gøre det til standard for nye services med relationelle data
Overvejede alternativer
Bruge MongoDB (vores hidtidige standard)
- Teamet har allerede erfaring med MongoDB
- Fleksibelt skema til krav under udvikling
- Godt til dokumentorienterede data
- Transaktioner på tværs af collections er komplekse
- Joins kræver logik på applikationsniveau
- Skemafleksibilitet kan føre til datainkonsistens
Bruge PostgreSQL
- ACID-transaktioner for faktureringsnøjagtighed
- Kraftfulde forespørgsler med JOINs
- Stærk dataintegritet med constraints
- JSONB til fleksible felter, når det er nødvendigt
- Teamet skal lære PostgreSQL
- Skemamigreringer kræver mere planlægning
- Anden driftsmodel end MongoDB
Begrundelse
Abonnementsfakturering kræver stærke konsistensgarantier, som er naturlige i PostgreSQL, men kræver omhyggelig håndtering i MongoDB. Den relationelle model passer bedre til vores data (kunder, planer, fakturaer, betalinger) end dokumenter. PostgreSQLs JSONB giver os skemafleksibilitet, når det er nødvendigt, uden at ofre relationelle muligheder.
Hvorfor denne beslutning var vigtig
Faktureringssystemer har nul tolerance over for inkonsistens. Det er uacceptabelt, at en kunde bliver opkrævet to gange eller slet ikke. Vi havde brug for:
- Atomare transaktioner på tværs af flere tabeller
- Stærk referentiel integritet
- Komplekse forespørgsler til rapportering
- Audit-spor til compliance
Erfaringen med MongoDB
Vi havde brugt MongoDB i 3 år. Det fungerede godt til:
- Brugerprofiler (dokumentorienteret)
- Produktkataloger (fleksibelt skema)
- Aktivitetslogs (mest tilføjelser)
Men vi kæmpede med:
- Transaktioner på tværs af flere dokumenter (tilføjet i 4.0, men stadig besværligt)
- Rapporteringsforespørgsler (aggregation pipeline er kraftfuld, men kompleks)
- Datakonsistens (ingen fremmednøgler betød forældreløse poster)
Evaluering af PostgreSQL
Vi kørte en to ugers spike for at evaluere PostgreSQL:
- Modellerede abonnementsdomænet relationelt
- Implementerede centrale faktureringsoperationer
- Testede transaktionsadfærd ved fejl
- Evaluerede forespørgselsydelse til rapportering
Resultaterne var overbevisende. Komplekse faktureringsforespørgsler, der tog over 50 linjer aggregation pipeline, blev til 10-linjers SQL-forespørgsler.
Migreringsvej
Vi migrerede ikke eksisterende MongoDB-services. I stedet:
- Nye services med relationelle data bruger PostgreSQL
- Eksisterende MongoDB-services forbliver (hvis de fungerer godt)
- Delte data tilgås via API’er, ikke direkte databaseadgang
Læring i teamet
Vi investerede i PostgreSQL-træning:
- Interne workshops om SQL og PostgreSQL-funktioner
- Pair programming under den indledende udvikling
- Dokumentation af mønstre og best practices
Efter 6 måneder er teamet fortrolig med begge databaser og kan vælge det rette værktøj til hver use case.