ಮಲ್ಟಿ-ಟೆನೆಂಟ್ SaaS ಆರ್ಕಿಟೆಕ್ಚರ್: ಮೂರು ಮಾದರಿಗಳು ಮತ್ತು ಆಯ್ಕೆ ಮಾಡುವುದು ಹೇಗೆ

ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿ ಎಂಬುದು ನಿಮ್ಮ SaaS ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸುವವರೆಗೆ ಅಮೂರ್ತವಾಗಿರುವ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಂತರ ಅದು ಎಲ್ಲವನ್ನೂ ಸ್ಪರ್ಶಿಸುತ್ತದೆ — ನೀವು ಡೇಟಾವನ್ನು ಹೇಗೆ ಕ್ವೆರಿ ಮಾಡುತ್ತೀರಿ, ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಕೇಲ್ ಮಾಡುತ್ತೀರಿ, ಮೈಗ್ರೇಶನ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಗ್ರಾಹಕರ ಐಸೋಲೇಶನ್ ಬಗ್ಗೆಯೂ ಸಹ. ಆರಂಭದಲ್ಲಿಯೇ ಅದನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿ, ಮತ್ತು ನೀವು ಸಾವಿರಾರು ಖಾತೆಗಳಿಗೆ ಸುಗಮವಾಗಿ ಸ್ಕೇಲ್ ಮಾಡುತ್ತೀರಿ. ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಗ್ರಾಹಕರು ನೋಡುತ್ತಿರುವಾಗಲೇ ನೀವು ಬೆಳವಣಿಗೆಯ ಮಧ್ಯೆ ನಿಮ್ಮ ಡೇಟಾ ಲೇಯರ್ ಅನ್ನು ಮರುಬರೆಯಬೇಕಾಗುತ್ತದೆ.

ಇಂದು, 9 ಜುಲೈ 2026, ಮಲ್ಟಿ-ಟೆನೆಂಟ್ SaaS ಸಾಮಾನ್ಯವಾಗಿದೆ, ವಿನಾಯಿತಿಯಲ್ಲ. ನೀವು ತಂಡಗಳಿಗಾಗಿ ಟೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿರಲಿ, ಎಂಟರ್‌ಪ್ರೈಸ್‌ಗಳಿಗೆ ಮಾರಾಟ ಮಾಡುತ್ತಿರಲಿ ಅಥವಾ ಬಳಕೆಯ ಆಧಾರಿತ ಬೆಲೆಯನ್ನು ನೀಡುತ್ತಿರಲಿ, ನೀವು ಈ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದೀರಿ. ಒಳ್ಳೆಯ ಸುದ್ದಿ: ಹೆಚ್ಚಿನ ಉತ್ಪನ್ನಗಳಿಗೆ, ಸರಿಯಾದ ಉತ್ತರವು ಇಂಟರ್ನೆಟ್ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಸರಳವಾಗಿದೆ.

ಮೂರು ಕ್ಯಾನೊನಿಕಲ್ ಮಾದರಿಗಳು

SaaS ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಟೆನೆಂಟ್‌ಗಳನ್ನು ಐಸೋಲೇಟ್ ಮಾಡಲು ಮೂರು ಸುಸ್ಥಾಪಿತ ಮಾರ್ಗಗಳಿವೆ, ಮತ್ತು ಅವು ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚದ ವಿರುದ್ಧ ಐಸೋಲೇಶನ್ ಅನ್ನು ವ್ಯಾಪಾರ ಮಾಡುತ್ತವೆ.

ರೋ-ಲೆವೆಲ್ ಟೆನೆನ್ಸಿ (ಹಂಚಿದ ಸ್ಕೀಮಾ)

ಪ್ರತಿ ಟೇಬಲ್ ಒಂದು tenant_id ಕಾಲಮ್ ಅನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ ಕ್ವೆರಿಯು ಅದರ ಮೇಲೆ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ. ಒಂದು ಡೇಟಾಬೇಸ್, ಒಂದು ಸ್ಕೀಮಾ, ಎಲ್ಲಾ ಟೆನೆಂಟ್‌ಗಳು ಒಟ್ಟಿಗೆ. ಇದು ತರ್ಕಬದ್ಧಗೊಳಿಸಲು ಸರಳವಾದ ಮಾದರಿಯಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಗ್ಗವಾಗಿದೆ.

ನೀವು ಪ್ರಾಜೆಕ್ಟ್-ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಟೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ tasks ಟೇಬಲ್ ಪ್ರತ್ಯೇಕ ಸ್ಟೋರೇಜ್ ಆಗಿ ವಿಭಜನೆಯಾಗುವುದಿಲ್ಲ — ಬದಲಾಗಿ, ಪ್ರತಿ ಸಾಲು ಅದನ್ನು ಹೊಂದಿರುವ ಟೆನೆಂಟ್‌ನ ID ಅನ್ನು ಒಯ್ಯುತ್ತದೆ. ಬಳಕೆದಾರರು ತಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ಕ್ವೆರಿ ಮಾಡಿದಾಗ, ಅಪ್ಲಿಕೇಶನ್ WHERE ಕ್ಲಾಸ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ: WHERE tenant_id = current_user.tenant_id.

ಸ್ಕೀಮಾ-ಪರ್-ಟೆನೆಂಟ್

ಪ್ರತಿಯೊಬ್ಬ ಟೆನೆಂಟ್ ಹಂಚಿದ ಡೇಟಾಬೇಸ್ ಒಳಗೆ ತನ್ನದೇ ಆದ PostgreSQL ಸ್ಕೀಮಾವನ್ನು ಪಡೆಯುತ್ತಾನೆ. ಪ್ರತಿ ಸ್ಕೀಮಾವು ತನ್ನದೇ ಆದ ನೇಮ್‌ಸ್ಪೇಸ್ ಆಗಿರುವುದರಿಂದ ಬಲವಾದ ಐಸೋಲೇಶನ್, ಆದರೆ ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚಿನ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿರುತ್ತವೆ. ಮೈಗ್ರೇಶನ್‌ಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತವೆ — ನೀವು ಅವುಗಳನ್ನು ಬಹು ಸ್ಕೀಮಾಗಳಾದ್ಯಂತ ರನ್ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಈ ಮಾದರಿಯು ರೋ-ಲೆವೆಲ್ ಮತ್ತು ಪೂರ್ಣ ಐಸೋಲೇಶನ್ ನಡುವೆ ಇರುತ್ತದೆ.

ಡೇಟಾಬೇಸ್-ಪರ್-ಟೆನೆಂಟ್

ಪ್ರತಿಯೊಬ್ಬ ಟೆನೆಂಟ್ ಡೆಡಿಕೇಟೆಡ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಪಡೆಯುತ್ತಾನೆ. ಗರಿಷ್ಠ ಐಸೋಲೇಶನ್ — ಒಬ್ಬ ಟೆನೆಂಟ್‌ನ ಡೇಟಾವು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ. ಗರಿಷ್ಠ ಕಾರ್ಯಾಚರಣೆಯ ತೂಕ ಕೂಡ — ನೀವು ಪ್ರತಿಯೊಬ್ಬ ಗ್ರಾಹಕರಿಗೆ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳು, ಬ್ಯಾಕಪ್‌ಗಳು ಮತ್ತು ಅಪ್‌ಗ್ರೇಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೀರಿ.

ಹೆಚ್ಚಿನ SaaS ಗಳಿಗೆ ರೋ-ಲೆವೆಲ್ ಏಕೆ ಗೆಲ್ಲುತ್ತದೆ

ಬಹುಪಾಲು B2B SaaS ಉತ್ಪನ್ನಗಳಿಗೆ, ರೋ-ಲೆವೆಲ್ ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿಯು ಸರಿಯಾದ ಡಿಫಾಲ್ಟ್ ಆಗಿದೆ. ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಗ್ಗವಾಗಿದೆ, ಮೈಗ್ರೇಶನ್‌ಗಳನ್ನು ರನ್ ಮಾಡಲು ಸುಲಭವಾಗಿದೆ ಮತ್ತು ಸಂಸ್ಥಾಪಕರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮಟ್ಟಿಗೆ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ.

ಆಕ್ಷೇಪಣೆ ಯಾವಾಗಲೂ ಹೀಗಿರುತ್ತದೆ: "ಆದರೆ ಐಸೋಲೇಶನ್ ಬಗ್ಗೆ ಏನು?" ಮತ್ತು ಇಲ್ಲಿ Postgres ಬಲವಾದ ಉತ್ತರವನ್ನು ಹೊಂದಿದೆ.

ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿ (RLS) ಮತ್ತು Postgres

Postgres ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿ ಎಂಬ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನೀಡುತ್ತದೆ. RLS, ಕ್ವೆರಿಯು ತನ್ನದೇ ಆದ ಟೆನೆಂಟ್‌ನ ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ನೋಡಬಹುದು ಎಂಬುದನ್ನು ಡೇಟಾಬೇಸ್ নিজেই ಜಾರಿಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಒಮ್ಮೆ ಪಾಲಿಸಿಯನ್ನು ಹೊಂದಿಸುತ್ತೀರಿ — ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ — ಮತ್ತು ದೋಷಯುಕ್ತ ಕ್ವೆರಿಯು ಸಹ ಟೆನೆಂಟ್‌ಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ಸೋರಿಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

Supabase, ಒಂದು ಹೋಸ್ಟೆಡ್ Postgres ಪ್ಲಾಟ್‌ಫಾರ್ಮ್, RLS ಅನ್ನು ಸ್ಥಳೀಯ ಮಾದರಿಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ನೀವು ಪಾಲಿಸಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಕೇವಲ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ ಮಾತ್ರವಲ್ಲದೆ ಭದ್ರತಾ ಗಡಿಯಾಗುತ್ತದೆ.

ಪ್ರತಿ ಟೇಬಲ್‌ನಲ್ಲಿ ಒಂದು tenant_id ಮತ್ತು ಅದರೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುವ ಇಂಡೆಕ್ಸ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಈ ಮಾದರಿಯು ದೊಡ್ಡ ಗ್ರಾಹಕರ ನೆಲೆಗಳಿಗೆ ಆರಾಮದಾಯಕವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಜಾರಿಗೊಳಿಸುವಿಕೆಯನ್ನು ಮಾಡುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಫಿಲ್ಟರ್ ಮಾಡಲು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.

RLS ಬಗ್ಗೆ ನೈಜ ಎಚ್ಚರಿಕೆ

ಅನುಭವದಿಂದ ಒಂದು ಪ್ರಮುಖ ವಿವರ: ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್‌ಗಳು ಪ್ರತಿ ಸಾಲಿಗೆ ಒಮ್ಮೆಯಲ್ಲ, ಪ್ರತಿ ಕ್ವೆರಿಗೆ ಒಮ್ಮೆ ರನ್ ಆಗುವಂತೆ RLS ಪಾಲಿಸಿಗಳನ್ನು ಬರೆಯಿರಿ. ಪ್ರತಿ ಸಾಲಿಗೆ ಲುಕ್ಅಪ್ ಅನ್ನು ಮರು-ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಪಾಲಿಸಿಯು ಟೇಬಲ್‌ಗಳು ಬೆಳೆದಂತೆ ವೇಗದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ಕ್ವೆರಿ ಪ್ಲಾನರ್ ಅದನ್ನು init-plan ಆಗಿ ರನ್ ಮಾಡುವಂತೆ ಚೆಕ್ ಅನ್ನು ಸುತ್ತಿಕೊಳ್ಳುವುದು ಇದರ ಪರಿಹಾರವಾಗಿದೆ — ಪ್ರಾರಂಭದಲ್ಲಿ ಒಂದು ಬಾರಿಯ ಚೆಕ್, ಪ್ರತಿ-ಸಾಲಿಗೆ ಅಲ್ಲ.

ಬಲವಾದ ಐಸೋಲೇಶನ್‌ಗೆ ಯಾವಾಗ ಏರಬೇಕು

ಹೆಚ್ಚಿನವರಿಗೆ ರೋ-ಲೆವೆಲ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಕೆಲವು ಗ್ರಾಹಕರಿಗೆ ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಏರಿ, ಪ್ರತಿಫಲಿತವಾಗಿ ಅಲ್ಲ:

• ನಿಯಂತ್ರಕ ಅಥವಾ ಒಪ್ಪಂದದ ಐಸೋಲೇಶನ್ — ಗ್ರಾಹಕರಿಗೆ ಭೌತಿಕವಾಗಿ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ತಮ್ಮ ಡೇಟಾ ಅಗತ್ಯವಿರುತ್ತದೆ. ಬಹುಶಃ ಅವರು ನಿಯಂತ್ರಿತ ಉದ್ಯಮದಲ್ಲಿದ್ದಾರೆ ಅಥವಾ ಅದನ್ನು ಬೇಡುವ ಒಪ್ಪಂದದ ಷರತ್ತು ಹೊಂದಿರಬಹುದು.
• ಗದ್ದಲದ-ನೆರೆಹೊರೆಯವರ ಅಪಾಯ — ಒಬ್ಬ ದೊಡ್ಡ ಗ್ರಾಹಕರ ಕೆಲಸದ ಹೊರೆಯು ಪ್ರತಿಯೊಬ್ಬರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಮೂಲಸೌಕರ್ಯವು ಇದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
• ಪ್ರತಿ-ಟೆನೆಂಟ್ ಕಸ್ಟಮೈಸೇಶನ್ — ಕೇವಲ ಡೇಟಾ ಮಾತ್ರವಲ್ಲ, ಸ್ಕೀಮಾಗಳು ನಿಜವಾಗಿಯೂ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ನೀವು ವಿಭಿನ್ನ ಗ್ರಾಹಕರಿಗೆ ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನ ರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಿದ್ದೀರಿ.

ಆಗಲೂ, ಹೈಬ್ರಿಡ್ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಹೆಚ್ಚಿನ ಟೆನೆಂಟ್‌ಗಳನ್ನು ರೋ-ಲೆವೆಲ್‌ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಅತಿದೊಡ್ಡ ಅಥವಾ ಅತ್ಯಂತ ಸೂಕ್ಷ್ಮ ಖಾತೆಗಳನ್ನು ಮಾತ್ರ ಡೆಡಿಕೇಟೆಡ್ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪದವಿ ನೀಡಿ.

ಮುಖ್ಯವಾದ ವಿನ್ಯಾಸ ತತ್ವಗಳು

ನೀವು ಏನೇ ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡರೂ, ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿಯನ್ನು ಮೊದಲೇ ಅಳವಡಿಸಿ. ಅದನ್ನು ನಂತರ ಬೋಲ್ಟ್ ಮಾಡಬೇಡಿ.

tenant_id ಅನ್ನು ಅದು ಮುಖ್ಯವಾಗಿರುವಲ್ಲೆಲ್ಲಾ ಹಾಕಿ

ಪ್ರತಿ ಡೊಮೇನ್ ಟೇಬಲ್‌ಗೆ tenant_id ಅನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಅದರೊಂದಿಗೆ ನಿಮ್ಮ ಕಾಂಪೋಸಿಟ್ ಇಂಡೆಕ್ಸ್‌ಗಳನ್ನು ಮುನ್ನಡೆಸಿ. ಇದು ಕ್ವೆರಿಗಳನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಟೆನೆಂಟ್‌ನಿಂದ ನೈಸರ್ಗಿಕವಾಗಿ ಆಯೋಜಿಸುತ್ತದೆ.

ಟೆನೆಂಟ್ ಐಡೆಂಟಿಟಿಗಾಗಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಎಂದಿಗೂ ನಂಬಬೇಡಿ

ಯಾವಾಗಲೂ ದೃಢೀಕರಿಸಿದ ಸೆಶನ್‌ನಿಂದ ಟೆನೆಂಟ್ ಅನ್ನು ಪಡೆಯಿರಿ, ರಿಕ್ವೆಸ್ಟ್ ಪ್ಯಾರಾಮೀಟರ್ ಅಥವಾ ಕುಕೀಯಿಂದ ಅಲ್ಲ. ನೀವು ಕ್ಲೈಂಟ್ ಅನ್ನು "ನೀವು ಯಾವ ಟೆನೆಂಟ್?" ಎಂದು ಕೇಳಿದರೆ, ದುರುದ್ದೇಶಪೂರಿತ ಅಥವಾ ದೋಷಯುಕ್ತ ಕ್ಲೈಂಟ್ ಸುಳ್ಳು ಹೇಳಬಹುದು.

ಡೇಟಾಬೇಸ್ ಲೇಯರ್‌ನಲ್ಲಿ ಐಸೋಲೇಶನ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸಿ

ತನ್ನ WHERE ಕ್ಲಾಸ್ ಅನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮಾತ್ರ ನಂಬಬೇಡಿ. ಡೇಟಾ ಸೋರಿಕೆಗಳನ್ನು ಅಸಾಧ್ಯವಾಗಿಸಲು ಡೇಟಾಬೇಸ್ ಕನ್ಸ್ಟ್ರೈಂಟ್‌ಗಳು ಮತ್ತು RLS ಅನ್ನು ಬಳಸಿ. ಡೆವಲಪರ್ ಎಲ್ಲೋ ಫಿಲ್ಟರ್ ಅನ್ನು ಮರೆತರೆ, ಡೇಟಾಬೇಸ್ ಸ್ವತಃ ತಪ್ಪನ್ನು ತಡೆಯುತ್ತದೆ.

ಟೆನೆಂಟ್ ಪ್ರಾವಿಷನಿಂಗ್ ಅನ್ನು ಒಂದು ಪರೀಕ್ಷಿತ ಕೋಡ್ ಪಾಥ್ ಮಾಡಿ

ನೀವು ಹೊಸ ಟೆನೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ಒಂದು ಸ್ಪಷ್ಟ, ಪರೀಕ್ಷಿತ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಓಡಿ. ಕೋಡ್‌ಬೇಸ್‌ನ ವಿವಿಧ ಭಾಗಗಳು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಟೆನೆಂಟ್‌ಗಳನ್ನು ರಚಿಸಲು ಬಿಡಬೇಡಿ. ಸ್ಥಿರತೆಯು ದೋಷಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಅತ್ಯಂತ ನೋವುಂಟುಮಾಡುವ ತಪ್ಪು

"ತಪ್ಪು" ಮಾದರಿಯನ್ನು ಆರಿಸುವುದು ತಪ್ಪಲ್ಲ. ಟೆನೆನ್ಸಿಯನ್ನು ಸೂಚ್ಯವಾಗಿ ಬಿಡುವುದು ಮತ್ತು ಕೋಡ್‌ಬೇಸ್‌ನಾದ್ಯಂತ ಐಸೋಲೇಶನ್ ಲಾಜಿಕ್ ಅನ್ನು ಹರಡುವುದು ತಪ್ಪಾಗಿದೆ. ನೀವು ಕೆಲವು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಲ್ಲಿ WHERE ಕ್ಲಾಸ್‌ಗಳು, ಇತರರಲ್ಲಿ SQL ಜಾಯಿನ್‌ಗಳು ಮತ್ತು ಯಾವುದೇ ಸ್ಪಷ್ಟ ನಿಯಮವಿಲ್ಲದ ಸ್ಥಿತಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ.

ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿಯನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ. ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಜಾರಿಗೊಳಿಸಿ. ಒಮ್ಮೆ ಪಾಲಿಸಿಯನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ಅಲ್ಲಿಂದ ನಿರ್ಮಿಸಿ. ವಿಕಸನಗೊಳ್ಳುವ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ನೀವು ಉಳಿಸಿಕೊಳ್ಳುತ್ತೀರಿ.

ತೀರ್ಮಾನ

ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದು ಮೂಲಭೂತ ಆಯ್ಕೆಯಾಗಿದೆ. Postgres ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿಯೊಂದಿಗೆ ರೋ-ಲೆವೆಲ್ ಟೆನೆನ್ಸಿಯು ಹೆಚ್ಚಿನ SaaS ಗೆ ಸರಿಯಾದ ಡಿಫಾಲ್ಟ್ ಆಗಿದೆ — ಇದು ಅಗ್ಗವಾಗಿದೆ, ಇದು ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಐಸೋಲೇಶನ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ನಿಮಗೆ ಸ್ಪಷ್ಟ ಕಾರಣವಿದ್ದಾಗ ಮಾತ್ರ ಬಲವಾದ ಮಾದರಿಗಳಿಗೆ ಏರಿ: ನಿಯಂತ್ರಣ, ಕಾರ್ಯಕ್ಷಮತೆ ಐಸೋಲೇಶನ್ ಅಥವಾ ನೈಜ ಸ್ಕೀಮಾ ಭಿನ್ನತೆ. ಮೊದಲ ದಿನದಿಂದಲೇ ಅದನ್ನು ನಿರ್ಮಿಸಿ, ನಿಮ್ಮ ಆಯ್ಕೆಯನ್ನು ಡಾಕ್ಯುಮೆಂಟ್ ಮಾಡಿ, ಮತ್ತು ನೀವು ಸುಗಮವಾಗಿ ಸ್ಕೇಲ್ ಮಾಡುತ್ತೀರಿ.

ಮೆರಿಟ್‌ಗಳು

• ಹೆಚ್ಚಿನ ಉತ್ಪನ್ನಗಳಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ರೋ-ಲೆವೆಲ್ ಟೆನೆನ್ಸಿಯು ಅಗ್ಗದ ಮತ್ತು ಸರಳವಾದದ್ದಾಗಿದೆ.
• Postgres ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿಯು ಐಸೋಲೇಶನ್ ಲಾಜಿಕ್ ಅನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಚಲಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅದನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ.
• ಸಿಂಗಲ್ ಡೇಟಾಬೇಸ್, ಒಂದು ಸ್ಕೀಮಾವು ಮೈಗ್ರೇಶನ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ನೇರವಾಗಿಸುತ್ತದೆ.
• ನೀವು ನಂತರ ಮರು-ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾಡದೆಯೇ ವೈಯಕ್ತಿಕ ಟೆನೆಂಟ್‌ಗಳನ್ನು ಬಲವಾದ ಐಸೋಲೇಶನ್‌ಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಬಹುದು.
• ಒಂದು tenant_id + ಇಂಡೆಕ್ಸ್-ಲೀಡಿಂಗ್ ಮಾದರಿಯು ದೊಡ್ಡ ಗ್ರಾಹಕರ ನೆಲೆಗಳಿಗೆ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ.

ಡಿಮೆರಿಟ್‌ಗಳು

• ಭೌತಿಕ ಡೇಟಾ ಬೇರ್ಪಡಿಕೆ ಬೇಡುವ ನಿಯಂತ್ರಕ ಅಥವಾ ಒಪ್ಪಂದದ ಅವಶ್ಯಕತೆಗಳಿಗೆ ರೋ-ಲೆವೆಲ್ ಐಸೋಲೇಶನ್ ಸಾಕಾಗುವುದಿಲ್ಲ.
• ಒಬ್ಬ ಗದ್ದಲದ ಟೆನೆಂಟ್‌ನ ಭಾರೀ ಕ್ವೆರಿಗಳು ಅದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಇತರ ಟೆನೆಂಟ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು.
• RLS ಪಾಲಿಸಿ ತಪ್ಪುಗಳು (ಪ್ರತಿ ಸಾಲಿಗೆ ಲಾಜಿಕ್ ಅನ್ನು ಮರು-ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಂತಹವು) ಸದ್ದಿಲ್ಲದೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಗ್ಗಿಸಬಹುದು.
• ರೋ-ಲೆವೆಲ್‌ನಿಂದ ಸ್ಕೀಮಾ-ಪರ್-ಟೆನೆಂಟ್ ಅಥವಾ ಡೇಟಾಬೇಸ್-ಪರ್-ಟೆನೆಂಟ್‌ಗೆ ನಂತರ ಮೈಗ್ರೇಟ್ ಮಾಡುವುದು ಸಂಕೀರ್ಣ ಮತ್ತು ಅಪಾಯಕಾರಿಯಾಗಿದೆ.
• ಡೆವಲಪರ್‌ಗಳು ಯಾವಾಗಲೂ ಟೆನೆಂಟ್ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಸೇರಿಸಲು ತಮ್ಮನ್ನು ತಾವು ಶಿಸ್ತುಗೊಳಿಸಿಕೊಳ್ಳಬೇಕು — ಡೇಟಾಬೇಸ್ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ದೋಷಗಳು ಇನ್ನೂ ಸಾಧ್ಯ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕವಾಗಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಆಧರಿಸಿದೆ. ಮೂಲ ವಸ್ತುವು ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ನಿಂದ ಬಂದಿದೆ; ಆರ್ಕಿಟೆಕ್ಚರಲ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಮೂಲ ಪ್ರಕಟಣೆಯ ವಿರುದ್ಧ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಅವಶ್ಯಕತೆಗಳ ವಿರುದ್ಧ ಹಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಉದ್ಯಮ ಮತ್ತು ನ್ಯಾಯವ್ಯಾಪ್ತಿಯಿಂದ ನಿಯಂತ್ರಕ ಮತ್ತು ಅನುಸರಣೆ ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗುತ್ತವೆ — ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಬಳಕೆಯ ಸಂದರ್ಭಕ್ಕಾಗಿ ಕಾನೂನು ಮತ್ತು ಭದ್ರತಾ ತಜ್ಞರನ್ನು ಸಂಪರ್ಕಿಸಿ. ನಿಮ್ಮ ಸ್ವಂತ ಪರಿಸರದಲ್ಲಿ RLS ಪಾಲಿಸಿಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ವಿಶೇಷವಾಗಿ ಸ್ಕೇಲ್‌ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ನಡವಳಿಕೆಯನ್ನು. ಈ ಲೇಖನವು ಮಿಷನ್-ಕ್ರಿಟಿಕಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ವೃತ್ತಿಪರ ಆರ್ಕಿಟೆಕ್ಚರ್ ವಿಮರ್ಶೆಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• SaaS ನಲ್ಲಿ ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿ ಎಂದರೇನು ಮತ್ತು ಅದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ?
• Postgres ನಲ್ಲಿ ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿಯು ಟೆನೆಂಟ್‌ಗಳ ನಡುವೆ ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ಹೇಗೆ ತಡೆಯುತ್ತದೆ?
• ರೋ-ಲೆವೆಲ್ ಟೆನೆನ್ಸಿಯ ಬದಲಿಗೆ ನಾನು ಸ್ಕೀಮಾ-ಪರ್-ಟೆನೆಂಟ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು?
• ಗದ್ದಲದ-ನೆರೆಹೊರೆಯವರ ಸಮಸ್ಯೆ ಎಂದರೇನು ಮತ್ತು ಅದು SaaS ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
• ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಿಂಗಲ್-ಟೆನೆಂಟ್ ಡೇಟಾಬೇಸ್‌ಗೆ ನಾನು tenant_id ಅನ್ನು ಹೇಗೆ ಸೇರಿಸುವುದು?
• ನಾನು ರೋ-ಲೆವೆಲ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ ನಂತರ ಡೇಟಾಬೇಸ್-ಪರ್-ಟೆನೆಂಟ್‌ಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಬಹುದೇ?
• ಸ್ಕೇಲ್‌ನಲ್ಲಿ RLS ಪಾಲಿಸಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಣಾಮಗಳೇನು?
• ನನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ಐಸೋಲೇಶನ್ ಅನ್ನು ನಾನು ಹೇಗೆ ಪರೀಕ್ಷಿಸುವುದು?

ಟ್ಯಾಗ್‌ಗಳು

#saas #architecture #postgres #scaling #multitenant #database #security #rls