Σχεδιάζοντας μοντέλο δεδομένων B2B SaaS πολλών πελατών όταν έχετε δέκα πελάτες και όχι δέκα χιλιάδες

Βασικά συμπεράσματα

• Για ένα B2B SaaS με λίγους πελάτες, η κατάλληλη προεπιλογή είναι μία βάση Postgres, ένα σχήμα, μια στήλη tenant_id σε κάθε πίνακα που ανήκει σε πελάτη και Row-Level Security που επιβάλλει την απομόνωση μέσα στην ίδια τη βάση (AWS Prescriptive Guidance).
• Το σχήμα ανά πελάτη φαίνεται τακτοποιημένο στους πέντε πελάτες και γίνεται εφιάλτης για το pg_dump και τις μεταναστεύσεις στους πεντακόσιους. Είναι το μοντέλο που οι περισσότερες ομάδες μετανιώνουν πρώτο.
• Η βάση ανά πελάτη είναι σπάνια η σωστή απάντηση κάτω από είκοσι πελάτες — η αριθμητική των δεξαμενών συνδέσεων σας επιβαρύνει προτού αποκτήσετε ομάδα πωλήσεων που να τη δικαιολογεί (Crunchy Data).
• Η ίδια η Microsoft προειδοποιεί εξαρχής για το κόστος: «Η μετάβαση σε άλλο μοντέλο αργότερα είναι μερικές φορές δαπανηρή» — σχεδιάστε λοιπόν τώρα τα σημεία διαχωρισμού, ακόμη κι αν δεν αλλάξετε μοντέλο (Microsoft Learn).
• Οι ενδείξεις που δικαιολογούν την απομόνωση πελάτη είναι συγκεκριμένες και ελέγχονται χωριστά: συμβατική ρήτρα γεωγραφικής διαμονής δεδομένων, καθεστώς συμμόρφωσης που η πλατφόρμα σας δεν μπορεί να καλύψει με κοινή υποδομή, ένας πελάτης του οποίου ο φόρτος στερεί πόρους από τους υπόλοιπους ή πελάτης που πληρώνει αρκετά ώστε μια αποκλειστική βάση να κοστίζει λιγότερο από τη διαπραγμάτευση.

Συνοπτικά

Αν έχετε δέκα πελάτες B2B, επιλέξτε το κοινό μοντέλο. Μία βάση, ένα σχήμα, tenant_id σε κάθε πίνακα που ανήκει σε πελάτη και Postgres Row-Level Security που εξασφαλίζει ότι κανένα ερώτημα δεν επιστρέφει γραμμή άλλου πελάτη. Ορίστε τον πελάτη σε κάθε σύνδεση στο όριο της εφαρμογής, όχι μέσα στην επιχειρησιακή λογική. Αντισταθείτε στην παρόρμηση να δώσετε σε κάθε πελάτη δικό του σχήμα ή βάση «επειδή είναι πιο καθαρό» — αυτή η καθαρότητα είναι απατηλή και το λειτουργικό κόστος εμφανίζεται αργότερα, συνήθως στη χειρότερη στιγμή. Επενδύστε τον χρόνο μηχανικών που εξοικονομείτε σε τρία πράγματα: αξιόπιστο επίπεδο συνδέσεων που γνωρίζει τον πελάτη, εργαλείο μεταναστεύσεων που εκτελείται μία φορά ανά βάση (όχι ανά πελάτη) και τρόπο μεταφοράς ενός πελάτη από την κοινή υποδομή σε αποκλειστική βάση όταν προκύψει μία από πέντε συγκεκριμένες ενδείξεις. Αντιμετωπίστε το κοινό μοντέλο ως προεπιλογή και το απομονωμένο ως εξαίρεση που μπορείτε να αιτιολογήσετε, όχι ως αφετηρία.

Γιατί τα άλλα άρθρα συχνά απαντούν σε λάθος ερώτημα

Το μεγαλύτερο μέρος του διαδικτυακού περιεχομένου για SaaS πολλών πελατών γράφεται για ένα κοινό που δεν υπάρχει ακόμη για εσάς. Στα αποτελέσματα αναζήτησης κυριαρχούν αρχιτεκτονικές αναφοράς της AWS, οδηγοί ελαστικών δεξαμενών του Microsoft Azure SQL και άρθρα για πλατφόρμες δεδομένων κλίμακας Snowflake. Δεν είναι λανθασμένα, αλλά ο αναγνώστης τους έχει χιλιάδες πελάτες, ομάδα πλατφόρμας και υπεύθυνο συμμόρφωσης. Εσείς πιθανότατα έχετε δέκα πελάτες που πληρώνουν, δύο μηχανικούς και έναν οδικό χάρτη που δεν περιλαμβάνει πουθενά «επανασχεδιασμό του μοντέλου πελατών».

Το κόστος μιας λανθασμένης επιλογής είναι ασύμμετρο. Ένα κοινό μοντέλο που τελικά πρέπει να διαχωρίσετε ανά πελάτη είναι ενοχλητικό αλλά διαχειρίσιμο — τα δεδομένα έχουν tenant_id και μπορείτε να τα εξαγάγετε με ETL έναν πελάτη τη φορά. Ένα μοντέλο με σχήμα ανά πελάτη που πρέπει να ενοποιήσετε, ή με βάση ανά πελάτη που πρέπει να λειτουργήσετε χωρίς επαρκές προσωπικό, μπορεί να απορροφήσει ένα τρίμηνο. Επομένως, η απόφαση που αξίζει προσοχή στους δέκα πελάτες είναι «ποιο μοντέλο κοστίζει λιγότερο σήμερα και εγκαταλείπεται φθηνότερα αν κάνω λάθος», όχι «ποιο μοντέλο κερδίζει στους χίλιους».

Τα τρία μοντέλα, σύντομα και ειλικρινά

Η τεκμηρίωση των προμηθευτών χρησιμοποιεί διαφορετικές ονομασίες. Η AWS μιλά για silo, pool και bridge (AWS). Η Microsoft χρησιμοποιεί standalone, database-per-tenant και sharded multi-tenant (Microsoft Learn). Η κοινότητα του Postgres συνήθως λέει κοινό σχήμα, σχήμα ανά πελάτη και βάση ανά πελάτη. Οι όροι αντιστοιχούν περίπου μεταξύ τους. Η τρίτη ορολογία είναι η σαφέστερη για να τα κατανοήσετε.

Κοινό σχήμα (κοινή υποδομή). Μία βάση, ένα σύνολο πινάκων, μια στήλη tenant_id σε κάθε γραμμή που ανήκει σε πελάτη. Κάθε ερώτημα φιλτράρει ανά πελάτη. Η απομόνωση επιβάλλεται από τη βάση μέσω RLS, όχι από την εφαρμογή. Ο ίδιος ο πίνακας κλιμάκωσης της Microsoft δίνει γι' αυτό το μοντέλο εύρος «1–1,000,000s» πελατών — το μεγαλύτερο από όλες τις επιλογές (Microsoft Learn).

Σχήμα ανά πελάτη. Μία βάση, ένα σχήμα Postgres ανά πελάτη, με τους ίδιους πίνακες μέσα σε κάθε σχήμα. Η εφαρμογή ορίζει το search_path βάσει του τρέχοντος πελάτη. Η απομόνωση είναι δομική — δεν διαρρέουν γραμμές, επειδή οι πίνακες ενός πελάτη δεν είναι ορατοί στη συνεδρία άλλου. Αυτό ακούγεται ελκυστικό μέχρι να συνειδητοποιήσετε ότι κάθε μετανάστευση εκτελείται πλέον N φορές, ότι η απόδοση του pg_dump υποβαθμίζεται μη γραμμικά με το πλήθος σχημάτων και ότι οι κατάλογοι συστήματος του Postgres δεν έχουν σχεδιαστεί για χιλιάδες αντικείμενα της ίδιας μορφής.

Βάση ανά πελάτη (απομονωμένη υποδομή). Μία βάση Postgres ανά πελάτη, μερικές φορές μία συστοιχία ανά πελάτη. Μέγιστη απομόνωση, μέγιστη λειτουργική επιβάρυνση. Η αριθμητική των δεξαμενών συνδέσεων είναι αμείλικτη: οι δεξαμενές του PgBouncer υπολογίζονται ανά συνδυασμό (χρήστης, βάση), πράγμα που σημαίνει ότι το μοντέλο θα εξαντλήσει το max_connections πολύ πριν εξαντλήσετε τη CPU (Crunchy Data). Η AWS περιγράφει καθαρά το όριο: «Αν έχετε 20 απομονωμένους λογαριασμούς για τους πελάτες σας… αυτό μπορεί να είναι διαχειρίσιμο. Αν όμως έχετε χίλιους πελάτες, πιθανότατα θα αρχίσει να επηρεάζει τη λειτουργική αποδοτικότητα και ευελιξία» (AWS).

Η προεπιλογή για δέκα πελάτες: κοινή υποδομή με RLS

Το έχω εγκαταστήσει αρκετές φορές ώστε να το θεωρώ προεπιλογή. Επιλέξτε το κοινό μοντέλο και κάντε το Row-Level Security αδιαπραγμάτευτο. Η AWS το λέει χωρίς περιστροφές: το RLS «απαιτείται για τη διατήρηση της απομόνωσης δεδομένων πελατών σε κοινό μοντέλο με PostgreSQL» και «συγκεντρώνει την επιβολή πολιτικών απομόνωσης στο επίπεδο της βάσης δεδομένων, απαλλάσσοντας τους προγραμματιστές από το βάρος διατήρησής της» (AWS Prescriptive Guidance).

Η σημασία του είναι λειτουργική, όχι θεωρητική. Η κλασική καταστροφή σε περιβάλλον πολλών πελατών είναι ένα WHERE tenant_id = $1 που λείπει από κάποιο ερώτημα στον κώδικα. Το RLS μετατρέπει αυτό το περιστατικό διαρροής δεδομένων σε σφάλμα επιστροφής κενού συνόλου — η μηχανή της βάσης προσθέτει μόνη της τη συνθήκη. Η AWS το περιγράφει ως «μια αυτοματοποιημένη ρήτρα WHERE που διαχειρίζεται η ίδια η μηχανή της βάσης… κάθε εντολή SQL των προγραμματιστών σας θα μοιάζει ίδια, ανεξάρτητα από το πλαίσιο πελάτη, και το PostgreSQL επιβάλλει την απομόνωση για εσάς» (AWS Database Blog). Αυτή η ιδιότητα — ότι δεν μπορείτε κατά λάθος να γράψετε ερώτημα που διαρρέει δεδομένα — καθιστά βιώσιμη την κοινή υποδομή μετά τον πέμπτο πελάτη.

Στην πράξη, το μοτίβο είναι μια μεταβλητή συνεδρίας και μια πολιτική. Ορίστε το app.current_tenant_id κάθε φορά που αποκτάτε σύνδεση από τη δεξαμενή. Κάθε πολιτική συγκρίνει το tenant_id της γραμμής με αυτή τη μεταβλητή. Ο Craig Kerstiens, πρώην στέλεχος των Heroku Postgres και Citus, συνοψίζει την προσέγγιση: «Όταν σχεδιάζετε την εφαρμογή σας για πολλούς πελάτες, ιδανικά έχετε αυτό το org_id σε κάθε πίνακα… Αντί για έναν χρήστη ανά πελάτη, θα ορίζουμε μια μεταβλητή συνεδρίας όταν συνδεόμαστε» (Crunchy Data).

Δύο λάθη γίνονται εύκολα εδώ. Πρώτον, η μεταβλητή πελάτη πρέπει να ορίζεται πριν επιτραπεί στον κώδικα της εφαρμογής να εκτελεί ερωτήματα — συνήθως σε ενδιάμεσο επίπεδο απόκτησης σύνδεσης, όχι μέσα σε χειριστές διαδρομών. Δεύτερον, οι ρόλοι υπερχρήστη και μεταναστεύσεων πρέπει να παρακάμπτουν ρητά το RLS, αλλά ο ρόλος της εφαρμογής δεν πρέπει. Ελέγξτε το με ένα εχθρικό ερώτημα: συνδεθείτε ως χρήστης της εφαρμογής, ορίστε τη μεταβλητή πελάτη σε μία τιμή, επιχειρήστε να διαβάσετε γραμμή άλλου πελάτη μέσω πρωτεύοντος κλειδιού και επιβεβαιώστε ότι δεν επιστρέφεται τίποτα. Αυτή η δοκιμή πρέπει να παραμείνει στο CI για πάντα.

Γιατί δεν θα σας ξεκινούσα με σχήμα ανά πελάτη

Το μοντέλο που δελεάζει συχνότερα τις μικρές ομάδες είναι το σχήμα ανά πελάτη. Φαίνεται δομικά καθαρό. Τα δεδομένα κάθε πελάτη είναι εμφανώς διαχωρισμένα. Μπορείτε να καταργήσετε έναν πελάτη διαγράφοντας ένα σχήμα. Οι ανακτήσεις μοιάζουν περιορισμένες σε συγκεκριμένο πεδίο. Το πρόβλημα είναι ότι η γοητεία είναι αισθητική, ενώ τα κόστη είναι λειτουργικά και μεγαλώνουν μαζί σας.

Τρία προβλήματα εμφανίζονται με αυτή τη σειρά. Οι μεταναστεύσεις πολλαπλασιάζονται: κάθε αλλαγή σχήματος εκτελείται N φορές, σε N σχήματα, και το εργαλείο σας πρέπει να ξέρει πώς να το κάνει συναλλακτικά. Η πολυπλοκότητα αυτής της ενορχήστρωσης συνήθως υποτιμάται μέχρι μια μετανάστευση να αποτύχει στα μισά του πελάτη 47. Η ομαδοποίηση συνδέσεων παραμένει πρόβλημα, επειδή το search_path είναι κατάσταση ανά συνεδρία, άρα η επαναχρησιμοποίηση συνδέσεων ενέχει κίνδυνο αν δεν το επαναφέρετε προσεκτικά. Και οι κατάλογοι συστήματος του Postgres — pg_class, pg_attribute, pg_namespace — συσσωρεύουν μία καταχώριση ανά αντικείμενο ανά σχήμα. Με εκατό σχήματα, είκοσι πίνακες και σαράντα ευρετήρια στο καθένα, έχετε εκατοντάδες χιλιάδες γραμμές καταλόγου, και λειτουργίες που τον σαρώνουν (όπως το pg_dump, η ενδοσκόπηση σχημάτων σε ORM και ορισμένες εργασίες autovacuum) επιβραδύνονται με τρόπους που είναι δύσκολο να διαγνωστούν.

Υπάρχουν θεμιτοί λόγοι για σχήμα ανά πελάτη — ισχυρή λογική απομόνωση χωρίς ξεχωριστές συστοιχίες, δυνατότητα διαγραφής σχήματος για συμμόρφωση, απλούστερα αντίγραφα ασφαλείας ανά πελάτη. Όμως κανένας από αυτούς δεν ισχύει στους δέκα πελάτες με τρόπο που να μην καλύπτει και το κοινό μοντέλο. Το RLS παρέχει απομόνωση. Η σήμανση πελάτη ως διαγραμμένου καλύπτει τη διαγραφή. Τα λογικά αντίγραφα ασφαλείας μπορούν να περιορίζονται με tenant_id. Πληρώνετε το κόστος του σχήματος ανά πελάτη για προβλήματα που δεν έχετε ακόμη.

Γιατί η βάση ανά πελάτη σπάνια είναι η σωστή αφετηρία

Η βάση ανά πελάτη προσφέρει τη μέγιστη απομόνωση και σήμερα λειτουργεί με πραγματικά μικρότερο κόστος από ό,τι πριν από πέντε χρόνια. Οι πάροχοι serverless Postgres έχουν κάνει βιώσιμο το μοτίβο «ένα έργο ανά πελάτη»· η Neon, για παράδειγμα, παρουσιάζει τη βάση ανά πελάτη ως φυσική λύση για απαιτήσεις γεωγραφικής διαμονής δεδομένων και HIPAA, σημειώνοντας ότι ορισμένοι πελάτες λειτουργούν εκατοντάδες χιλιάδες βάσεις μέσω του API της (Neon). Πρόκειται για πραγματική και ουσιαστική αλλαγή στους διαθέσιμους συμβιβασμούς.

Παραμένει ακατάλληλη αφετηρία για τις περισσότερες μικρές ομάδες B2B SaaS. Οι λόγοι είναι κυρίως όσα δεν προβάλλουν πρώτα τα ιστολόγια των προμηθευτών: διαχείριση N μεταναστεύσεων, N συνόλων διαπιστευτηρίων, N στόχων παρακολούθησης, N ρυθμίσεων αντιγράφων ασφαλείας και N παραθύρων αναβάθμισης. Η εργασία αυξάνεται γραμμικά με τους πελάτες — ακριβώς το είδος εργασίας που εξαντλεί μικρές ομάδες μηχανικών. Οι αναφορές μεταξύ πελατών γίνονται πρόβλημα ομοσπονδιακών ερωτημάτων αντί για ένα GROUP BY tenant_id. Η διάθεση νέων λειτουργιών εξαρτάται από την ολοκλήρωση μεταναστεύσεων ανά πελάτη. Την πρώτη φορά που πρέπει να διαθέσετε επείγουσα διόρθωση και το CI χρειάζεται σαράντα πέντε λεπτά για να μεταναστεύσει διαδοχικά όλους τους πελάτες, θα καταλάβετε γιατί υπάρχει το κοινό SaaS.

Αν το πελατολόγιό σας ξεπερνά πράγματι μερικές εκατοντάδες και οι απαιτήσεις απομόνωσης είναι ουσιαστικές, θα καταλήξετε κάπου στο μοντέλο bridge: μια προεπιλεγμένη κοινή υποδομή και λίγες αποκλειστικές βάσεις για όσους τις χρειάζονται. Η Notion κατέληξε σε «480 λογικά τμήματα κατανεμημένα σε 32 φυσικές βάσεις», με διαμερισμό βάσει αναγνωριστικού χώρου εργασίας, αλλά έφτασε εκεί από έναν ενιαίο μονόλιθο και μόνο όταν οι εμπλοκές του VACUUM έγιναν συνηθισμένο περιστατικό παραγωγής (Notion). Δεν ξεκίνησε από εκεί. Ούτε εσείς πρέπει.

Οι πέντε ενδείξεις που δικαιολογούν απομόνωση

Η απομόνωση πελάτη είναι συγκεκριμένη απόφαση με συγκεκριμένο κόστος. Αξίζει όταν υπάρχει συγκεκριμένος λόγος. Ακολουθούν οι πέντε ενδείξεις που, βάσει της εμπειρίας μου, δικαιολογούν πραγματικά τη μεταφορά πελάτη εκτός κοινής υποδομής. Αρκεί οποιαδήποτε μία.

1. Συμβατική ρήτρα γεωγραφικής διαμονής δεδομένων που δεν καλύπτει η κοινή υποδομή. Η σύμβαση απαιτεί τα δεδομένα του πελάτη να αποθηκεύονται φυσικά στη Γερμανία, στην Αυστραλία ή στο US-East. Αν η κοινή βάση σας βρίσκεται σε μία μόνο περιοχή, δεν μπορείτε να τηρήσετε τη ρήτρα χωρίς να απομονώσετε τον πελάτη σε βάση στην απαιτούμενη περιοχή. Αυτός είναι ο συνηθέστερος λόγος σε ρυθμιζόμενους κλάδους και η σαφέστερη αιτιολόγηση.

2. Ρυθμιστικό καθεστώς που απαιτεί αποδείξιμη απομόνωση. HIPAA, FedRAMP, ορισμένοι έλεγχοι SOC 2 βάσει συγκεκριμένων συμβάσεων ή εθνική αρχή προστασίας δεδομένων που έχει κρίνει ότι η «λογική απομόνωση μέσω RLS» δεν ταυτίζεται με τη «φυσική απομόνωση». Οι οδηγίες συμμόρφωσης της Microsoft εξηγούν πώς αντιστοιχούν τα επίπεδα απομόνωσης σε αυτά τα καθεστώτα (Microsoft Learn). Αντιμετωπίστε το ως συμβατικό και ελεγκτικό ζήτημα — η απάντηση της ομάδας ασφάλειας στο «μπορείτε να αποδείξετε ότι τα δεδομένα αυτού του πελάτη δεν χρησιμοποιούν ποτέ τους υπολογιστικούς πόρους άλλου;» καθορίζει αν απαιτείται απομόνωση.

3. Ένας υπερβολικά απαιτητικός πελάτης που στερεί πόρους από τους υπόλοιπους. Μερικές φορές ένας πελάτης είναι δεκαπλάσιος από τον αμέσως επόμενο. Τα αναλυτικά ερωτήματά του κρατούν κλειδώματα· οι εγγραφές του κορέζουν τα IOPS· οι πλήρεις σαρώσεις πινάκων εκτοπίζουν την προσωρινή μνήμη όλων των άλλων. Η λύση δεν είναι επ' αόριστον «μεγαλύτερο μηχάνημα» — κάποια στιγμή μια δική του βάση κοστίζει λιγότερο.

4. Σύμβαση αρκετά μεγάλη ώστε η αποκλειστική βάση να κοστίζει λιγότερο από τη διαπραγμάτευση. Ένας εταιρικός πελάτης με εξαψήφιο συμβόλαιο ζητά «αποκλειστική υποδομή». Το πραγματικό κόστος μιας διαχειριζόμενης εγκατάστασης Postgres είναι μικρό. Το κόστος δύο εβδομάδων συζητήσεων για το τι σημαίνει «αποκλειστική» στην κοινή σας αρχιτεκτονική είναι μεγάλο. Δώστε του τη βάση. Είναι εμπορική απάντηση με τεχνικό περίβλημα, και αυτό είναι απολύτως θεμιτό.

5. Μετρήσιμη ένδειξη ορίου κλιμάκωσης στην κοινή βάση. Η ομάδα μηχανικών της Figma δημοσίευσε ένα χρήσιμο όριο από τη δική της πορεία: στις αρχές του 2022 η κύρια βάση της «πλησίαζε το 65% χρήσης CPU στις ώρες αιχμής», οπότε ξεκίνησε τον κάθετο διαμερισμό (Figma). Επιλέξτε μια τέτοια ένδειξη και καταγράψτε την — παρατεταμένη χρήση CPU αιχμής πάνω από όριο, καθυστέρηση αντιγραφής πάνω από όριο, καθυστέρηση P99 σε κρίσιμο πίνακα πάνω από όριο — ώστε η απόφαση απομόνωσης να προκύπτει από λειτουργικό ερέθισμα και όχι από αίσθηση.

Από τη λίστα απουσιάζει σκόπιμα το «έχουμε εκατό πελάτες και μάλλον ήρθε η ώρα». Ο αριθμός πελατών από μόνος του δεν είναι ένδειξη. Με καλό σχεδιασμό σχήματος μπορείτε να λειτουργείτε κοινό μοντέλο με δεκάδες χιλιάδες πελάτες· πρέπει να απομονώσετε έναν πελάτη από τον πρώτο μήνα αν το απαιτεί η σύμβασή του.

Πώς να σχεδιάσετε σήμερα ώστε η απομόνωση να κοστίσει λίγο αύριο

Αν η απόφαση είναι «κοινή υποδομή τώρα, με δυνατότητα απομόνωσης πελάτη αργότερα», η εκδοχή που εγκαταλείπεται εύκολα έχει τέσσερις ιδιότητες. Ενσωματώστε τις από την πρώτη ημέρα — στην αρχή είναι σχεδόν δωρεάν, ενώ η εκ των υστέρων προσθήκη τους κοστίζει.

Πρώτον, κάθε πίνακας που ανήκει σε πελάτη έχει tenant_id NOT NULL, με ευρετήριο και παρουσία σε κάθε δευτερεύον ευρετήριο μέσω του οποίου εκτελείτε ερωτήματα. Αυτή η ιδιότητα μετατρέπει την εξαγωγή ανά πελάτη σε ερώτημα μίας γραμμής αντί για ETL πολλών εβδομάδων.

Δεύτερον, η εφαρμογή αποκτά συνδέσεις μέσω επιπέδου που γνωρίζει τον πελάτη και ορίζει τη μεταβλητή συνεδρίας του πριν επιστρέψει τη σύνδεση στον καλούντα. Ο κώδικας πρόσβασης δεδομένων δεν πρέπει ποτέ να βλέπει σύνδεση χωρίς πελάτη. Αν τα σημεία κλήσης που ορίζουν το πλαίσιο πελάτη δεν μετριούνται στα δάχτυλα του ενός χεριού, υπάρχει διαρροή που περιμένει να συμβεί.

Τρίτον, οι μεταναστεύσεις γράφονται μία φορά και εφαρμόζονται μία φορά ανά βάση, όχι ανά πελάτη. Αυτό σημαίνει αποφυγή DDL που εξαρτάται από ονοματοδοσία συγκεκριμένου πελάτη. Αν μπείτε στον πειρασμό να γράψετε CREATE TABLE customer_42_orders, σταματήστε.

Τέταρτον, υπάρχει σενάριο μεταφοράς πελάτη — τεκμηριωμένη διαδικασία εξαγωγής των δεδομένων του από την κοινή βάση, επαναφοράς σε νέα αποκλειστική βάση, αλλαγής της δρομολόγησης πελάτη προς βάση στην εφαρμογή και απόσυρσης των αρχικών γραμμών. Δεν χρειάζεται αυτοματοποίηση την πρώτη ημέρα· χρειάζεται εγχειρίδιο διαδικασίας και μία δοκιμή σε πραγματικό πελάτη σε περιβάλλον προπαραγωγής. Την πρώτη φορά που θα το χρειαστείτε θα υπάρχει συμβατική πίεση και προθεσμία. Δεν θέλετε να το σχεδιάζετε τότε.

Αυτές οι τέσσερις ιδιότητες κοστίζουν σχεδόν τίποτα στην αρχή ενός έργου. Η εκ των υστέρων προσθήκη τους δύο χρόνια αργότερα κοστίζει ένα τρίμηνο μηχανικής εργασίας.

Τι να παραλείψετε στους δέκα πελάτες

Μια σύντομη λίστα πραγμάτων που προτείνουν τα ιστολόγια προμηθευτών, αλλά πρέπει συνειδητά να αναβάλετε:

• Οριζόντιος διαμερισμός. Έχετε δέκα πελάτες. Ο διαμερισμός λύνει προβλήματα μεγαλύτερης κλίμακας από τα δικά σας. Ένα σωστά σχεδιασμένο κοινό μοντέλο μπορεί να διαμεριστεί αργότερα ανά πελάτη με την ίδια προσπάθεια.
• Ειδική υπηρεσία ρυθμίσεων ανά πελάτη. Μέχρι να έχετε τουλάχιστον τρεις ρυθμίσεις που διαφέρουν πραγματικά ανά πελάτη, αρκεί ένας πίνακας tenant_settings.
• «Πλαίσιο εξέλιξης σχημάτων» πάνω από το εργαλείο μεταναστεύσεων. Επιλέξτε ένα εργαλείο και εκτελέστε το CLI του. Πλαίσια πάνω από πλαίσια είναι καθαρό κόστος σε αυτό το στάδιο.
• Αντιγραφή μεταξύ συστοιχιών για αναλύσεις. Με δέκα πελάτες αρκεί μια νυχτερινή λογική εξαγωγή σε ξεχωριστή βάση αναφορών. Η υποδομή αναλύσεων σε πραγματικό χρόνο μπορεί να περιμένει μέχρι να τη ζητήσει πελάτης σε σύμβαση.

Κρατήστε τους πόρους για τις τέσσερις παραπάνω ιδιότητες. Αυτές θα καθορίσουν αν η απόφαση του επόμενου έτους θα χρειαστεί ένα απόγευμα Τρίτης ή πλήρη επανασχεδιασμό αρχιτεκτονικής.

Επίλογος

Η παγίδα με τα μοντέλα δεδομένων πολλών πελατών είναι να αντιμετωπίζετε την απόφαση σαν να αφορά κλίμακα FAANG. Δεν αφορά. Στους δέκα πελάτες, η καλύτερη απόφαση είναι η απλή: κοινή υποδομή με RLS, στήλη πελάτη σε κάθε πίνακα, απομόνωση στο επίπεδο σύνδεσης και γραπτή διαδρομή εξόδου για όσους δικαιολογήσουν μελλοντικά αποκλειστική βάση. Το μοντέλο που κερδίζει στους δέκα αντέχει και στους χίλιους, αρκεί να έχετε προβλέψει νωρίς τα σημεία διαχωρισμού. Όσα φαίνονται καθαρότερα στο αρχιτεκτονικό διάγραμμα τείνουν να κοστίζουν περισσότερο στη λειτουργία, και το ανακαλύπτετε τη χρονιά που έχετε τα μικρότερα περιθώρια.

Η DevLume σχεδιάζει και εκσυγχρονίζει αρχιτεκτονικές δεδομένων για πλατφόρμες B2B ακριβώς σε αυτό το στάδιο — θα χαρούμε να συζητήσουμε αν θέλετε μια δεύτερη ματιά στο μοντέλο διαχωρισμού πελατών πριν το διαθέσετε.