ਸਿੱਖੋ ਕਿ multi-tenant ਡੇਟਾਬੇਸ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਮੁੱਖ ਖਤਰਿਆਂ (ਇਨਸੋਲੇਸ਼ਨ, noisy neighbors) ਅਤੇ tenants ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ عملي ਨਿਯੰਤਰਣ ਕੀ ਹਨ।
A multi-tenant database ਉਹ ਸੈਟਅੱਪ ਹੈ ਜਿੱਥੇ ਕਈ ਗਾਹਕ (tenants) ਇੱਕੋ ਹੀ ਡੇਟਾਬੇਸ ਸਿਸਟਮ ਸਾਂਝਾ ਕਰਦੇ ਹਨ—ਉਹੀ ਡੇਟਾਬੇਸ ਸਰਵਰ, ਉਹੀ ਅਧਾਰਭੂਤ ਸਟੋਰੇਜ, ਅਤੇ ਅਕਸਰ ਉਹੀ schema—ਜਦਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਹਰ tenant ਸਿਰਫ਼ ਆਪਣਾ ਡੇਟਾ ਹੀ ਵੇਖ ਸਕੇ।
ਇਸਨੂੰ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਵਾਂਗ ਸੋਚੋ: ਹਰ ਕੋਈ ਬਿਲਡਿੰਗ ਦੀ ਬਣਤਰ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, ਪਰ ਹਰ tenant ਦਾ ਆਪਣਾ ਲੱਕਡ ਯੂਨਿਟ ਹੁੰਦਾ ਹੈ।
ਇੱਕ single-tenant ਰਵੱਈਏ ਵਿੱਚ, ਹਰ ਗਾਹਕ ਨੂੰ ਨਿਰਧਾਰਤ ਡੇਟਾਬੇਸ ਸਰੋਤ ਮਿਲਦੇ ਹਨ—ਉਦਾਹਰਣ ਲਈ, ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਡੇਟਾਬੇਸ ਇੰਸਟੈਂਸ ਜਾਂ ਆਪਣਾ ਸਰਵਰ। ਇਨਸੋਲੇਸ਼ਨ ਸਮਝਣ ਲਈ ਆਸਾਨ ਹੁੰਦੀ ਹੈ, ਪਰ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਵੱਧਣ ਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਮਹਿੰਗਾ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ।
Multi-tenancy ਨਾਲ, tenants ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਜੋ ਕੁਸ਼ਲਤਾਪੂਰਕ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਬਾਊਂਡਰੀਜ਼ ਲਾਗੂ ਕਰਨੀ ਪੈਂਦੀਆਂ ਹਨ।
SaaS ਕੰਪਨੀਆਂ ਅਕਸਰ ਪ੍ਰਾਇਕਟਿਕ ਕਾਰਨਾਂ ਕਰਕੇ multi-tenancy ਚੁਣਦੀਆਂ ਹਨ:
Multi-tenancy ਆਪਣੇ ਆਪ ਵਿੱਚ “ਸੁਰੱਖਿਅਤ” ਜਾਂ “ਤੇਜ਼” ਨਹੀਂ ਹੁੰਦੀ। ਨਤੀਜੇ ਇਹਨਾਂ ਚੋਣਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ tenants ਨੂੰ ਕਿਵੇਂ ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਹੈ (schema, rows, ਜਾਂ databases), ਕਿਵੇਂ access control ਲਾਗੂ ਹੁੰਦੀ ਹੈ, encryption keys ਕਿਵੇਂ ਹੱਥਾਂ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਸਿਸਟਮ ਇਹ ਰੋਕਦਾ ਹੈ ਕਿ ਇੱਕ tenant ਦੀ workload ਦੂਜਿਆਂ ਨੂੰ ਧੀਮਾ ਨਾ ਕਰ ਦੇਵੇ।
ਇਸ ਗਾਈਡ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਇਨ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦਾ ਹੈ—ਕਿਉਂਕਿ multi-tenant ਸਿਸਟਮਾਂ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਉਹ ਫੀਚਰ ਹਨ ਜੋ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਨਾ ਕਿ ਉਹ ਅਨੁਮਾਨ ਜੋ ਤੁਹਾਨੂੰ ਮਿਲਦੇ ਹਨ।
Multi-tenancy ਇੱਕ ਹੀ ਡਿਜ਼ਾਈਨ ਚੋਣ ਨਹੀਂ ਹੈ—ਇਹ ਉਸ ਸਪੈਕਟ੍ਰਮ ਦੀ ਗੱਲ ਹੈ ਕਿ ਤੁਸੀਂ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਕਿੰਨੀ ਕਠੋਰਤਾ ਨਾਲ ਸਾਂਝੀ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਜੋ ਮਾਡਲ ਚੁਣਦੇ ਹੋ, ਉਹ ਤੁਹਾਡੀ ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ (ਕਿਹੜਾ ਹਿੱਸਾ ਕਦੇ ਵੀ ਸਾਂਝਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ), ਅਤੇ ਇਸਦਾ ਸਿੱਧਾ ਪ੍ਰਭਾਵ ਡੇਟਾਬੇਸ ਸੁਰੱਖਿਆ, ਪ੍ਰਦਰਸ਼ਨ ਅਲੱਗ ਕਰਨ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨਸ 'ਤੇ ਪੈਂਦਾ ਹੈ।
ਹਰ tenant ਨੂੰ ਆਪਣਾ ਡੇਟਾਬੇਸ ਮਿਲਦਾ ਹੈ (ਅਕਸਰ ਇੱਕੋ ਸਰਵਰ ਜਾਂ ਕਲੱਸਟਰ ਤੇ)।
ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ: ਡੇਟਾਬੇਸ ਖੁਦ। ਇਹ ਆਮਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਾਫ਼ tenant ਇਨਸੋਲੇਸ਼ਨ ਕਹਾਣੀ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ cross-tenant ਪਹੁੰਚ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਹੱਦ ਪਾਰ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ।
ਓਪਰੇਸ਼ਨਲ ਟਰੇਡ-ਆਫ਼: ਸਕੇਲ 'ਤੇ ਓਪਰੇਟ ਕਰਨਾ ਬੋਝਿਲ। ਅਪਗਰੇਡ ਅਤੇ schema migrations ਹਜ਼ਾਰਾਂ ਵਾਰ ਚਲਾਣੇ ਪੈ ਸਕਦੇ ਹਨ, ਅਤੇ connection pooling ਜਟਿਲ ਹੋ ਸਕਦੀ ਹੈ। Backups/restores tenant-ਸਤਰ 'ਤੇ ਸਿੱਧੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਸਟੋਰੇਜ ਅਤੇ ਪ੍ਰਬੰਧਨ ਓਹਲੇ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਸਕਦੇ ਹਨ।
ਸੁਰੱਖਿਆ ਅਤੇ ਟਿਊਨਿੰਗ: ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਗਾਹਕ ਲਈ ਸੁਰੱਖਿਆ ਅਤੇ ਟਿਊਨਿੰਗ ਅਸਾਨ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਹਵੇਲੇ ਲਈ ਵਧੀਆ ਹੈ ਜਦੋਂ tenants ਦੀਆਂ compliance ਲੋੜਾਂ ਵੱਖ-ਵੱਖ ਹੋਣ।
Tenants ਇੱਕ ਡੇਟਾਬੇਸ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਪਰ ਹਰ tenant ਦਾ ਆਪਣਾ schema ਹੁੰਦਾ ਹੈ।
ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ: schema। ਇਹ ਯਥਾਰਥਪੂਰਨ ਵੱਖਰਾ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਸਹੀ permissions ਅਤੇ tooling 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਓਪਰੇਸ਼ਨਲ ਟਰੇਡ-ਆਫ਼: upgrades ਅਤੇ migrations ਫਿਰ ਵੀ ਦੋਹਰਾਏ ਜਾਂਦੇ ਹਨ, ਪਰ database-per-tenant ਨਾਲੋਂ ਹਲਕੇ। Backups ਔਖੇ ਹੋ ਸਕਦੇ ਹਨ: ਕਈ ਟੂਲ ਡੇਟਾਬੇਸ ਨੂੰ ਬੈਕਅੱਪ ਯੂਨਿਟ ਮੰਨਦੇ ਹਨ, ਇਸ ਲਈ tenant-ਸਤਰ ਕਾਰਵਾਈਆਂ ਲਈ schema-ਲੈਵਲ ਨਿਰਯਾਤ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਟਿਊਨਿੰਗ: shared tables ਨਾਲੋਂ ਇਨਸੋਲੇਸ਼ਨ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ, ਪਰ privileges ਅਤੇ ਕਵੇਰੀਆਂ ਦਾ ਸਹੀ schema ਨਹੀਂ ਰੇਫਰੰਸ ਕਰਨ ਤੋਂ ਸਾਵਧਾਨ ਰਹਿਣਾ ਜ਼ਰੂਰੀ ਹੈ।
ਸਾਰੇ tenants ਇੱਕ ਡੇਟਾਬੇਸ ਅਤੇ schema ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਪਰ ਹਰ tenant ਦੇ ਵੱਖਰੇ tables ਹੁੰਦੇ ਹਨ (ਉਦਾਹਰਣ ਲਈ orders_tenant123).
ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ: table ਸੈਟ। ਇਹ ਘੱਟ tenants ਲਈ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਨਹੀਂ ਕਰਦਾ: metadata ਬਹੁਤ ਵਧ ਜਾਂਦਾ ਹੈ, migration ਸਕ੍ਰਿਪਟ ਜਟਿਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ query planning ਖਰਾਬ ਹੋ ਸਕਦੀ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਟਿਊਨਿੰਗ: permissions ਨਿੱਜੀ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਉੱਚੀ ਹੈ, ਅਤੇ ਨਵੀਂ ਟੇਬਲ ਜਾਂ ਫੀਚਰ ਸ਼ਾਮਿਲ ਕਰਦੇ ਸਮੇਂ ਗਲਤੀਆਂ ਹੋਣਾ ਆਸਾਨ ਹੈ।
ਸਾਰੇ tenants ਇੱਕੋ Tabellen ਸਾਂਝੇ ਕਰਦੇ ਹਨ, ਜੋ tenant_id ਕਾਲਮ ਨਾਲ ਵੱਖਰੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ: ਤੁਹਾਡੀ ਕਵੇਰੀ ਅਤੇ access-control ਲੇਅਰ (ਆਮ ਤੌਰ 'ਤੇ row-level security)। ਇਹ ਮਾਡਲ ਓਪਰੇਸ਼ਨ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ—ਇੱਕ schema ਨੂੰ migrate ਕਰਨ, ਇੱਕ ਇੰਡੈਕਸ ਰਣਨੀਤੀ ਨੂੰ ਮੈਨੇਜ ਕਰਨ—ਪਰ ਇਹ ਡੇਟਾਬੇਸ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਲੱਗ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਮੰਗਵਾਲਾ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਟਿਊਨਿੰਗ: ਸਹੀ ਬਣਾਉਣਾ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕਵੇਰੀ tenant-ਜਾਣੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ noisy neighbor ਸਮੱਸਿਆ ਜ਼ਿਆਦਾ ਸੰਭਾਵਿਤ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਰੋਤ ਸੀਮਾਵਾਂ ਅਤੇ ਧਿਆਨਪੂਰਵਕ ਇੰਡੈਕਸਿੰਗ ਨਹੀਂ ਜੋੜਦੇ।
ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਤੁਸੀਂ ਸਾਂਝਾ ਕਰਦੇ ਹੋ, ਉਤਨੀ ਹੀ ਸੌਖੀ upgrades ਹੁੰਦੀ ਹੈ—ਪਰ ਉਤਨੀ ਹੀ ਜ਼ਿਆਦਾ ਕਠੋਰ tenant ਇਨਸੋਲੇਸ਼ਨ ਨਿਯੰਤਰਣਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਲੱਗ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Multi-tenancy ਸਿਰਫ਼ “ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕਈ ਗਾਹਕ” ਹੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਤੁਹਾਡਾ threat model ਬਦਲ ਦਿੰਦੀ ਹੈ: ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਬਾਹਰੀ ਹਮਲਿਆਂ ਤੋਂ ਬਦਲ ਕੇ ਅਧਿਕਾਰਤ ਵਰਤੋਂਕਾਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਗਲਤੀ ਨਾਲ (ਜਾਂ ਜਜ਼ਬਾਤੀ ਤੌਰ 'ਤੇ) ਕਿਸੇ ਹੋਰ tenant ਦਾ ਡੇਟਾ ਵੇਖ ਲੈਂਦੇ ਹਨ।
Authentication ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ “ਤੁਸੀਂ ਕੌਣ ਹੋ?” Authorization ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ “ਤੁਸੀਂ ਕੀ ਏਕਸੈਸ ਕਰ ਸਕਦੇ ਹੋ?” Multi-tenant ਡੇਟਾਬੇਸ ਵਿੱਚ, tenant context (tenant_id, account_id, org_id) ਨੂੰ authorization ਦੌਰਾਨ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਇੱਕ ਵੈਕਲਪਿਕ ਫਿਲਟਰ ਵਜੋਂ ਨਹੀਂ।
ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਮੰਨ ਲੈਣਾ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਯੂਜ਼ਰ authenticate ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਦਾ tenant “ਜਾਣ ਲੈਂਦੇ” ਹੋ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਆਪੋ ਆਪਣੀ ਕਵੇਰੀਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੇਗੀ। ਅਮਲੀ طور 'ਤੇ, ਵੱਖਰਾ ਰੱਖਣਾ explicit ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਲਗਾਤਾਰ ਨਿਯੰਤਰਣ ਬਿੰਦੂ ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਜਿਵੇਂ ਡੇਟਾਬੇਸ ਨੀਤੀਆਂ ਜਾਂ ਇੱਕ ਜ਼ਰੂਰੀ ਕਵੇਰੀ ਲੇਅਰ)।
ਸਭ ਤੋਂ ਸੌਖਾ ਪਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ: ਹਰ ਰੀਡ ਅਤੇ ਰਾਈਟ ਨੂੰ ਬਿਲਕੁਲ ਇਕ ਹੀ tenant ਲਈ ਸਕੋਪ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਹ ਲਾਗੂ ਹੁੰਦਾ ਹੈ:
ਜੇ tenant ਸਕੋਪਿੰਗ ਵੈਕਲਪਿਕ ਹੈ, ਇਹ ਅਖੀਰਕਾਰ ਛੱਡ ਦਿੱਤੀ ਜਾਵੇਗੀ।
Cross-tenant leaks ਅਕਸਰ ਛੋਟੀ, ਰੋਟੀਨ ਗਲਤੀਆਂ ਕਾਰਨ ਹੁੰਦੇ ਹਨ:
tenant_id ਨੂੰ ਬਾਈਂਡ ਕਰ ਦੇਂਦੇ ਹਨਟੈਸਟ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ ਡੇਟਾ ਸੈੱਟ ਅਤੇ ਸਾਫ਼ ਧਾਰਾਣਾਂ ਨਾਲ ਚਲਦੇ ਹਨ। ਉਤਪਾਦਨ concurrency, retries, caches, mixed tenant data, ਅਤੇ ਅਸਲੀ edge ਕੇਸਾਂ ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਫੀਚਰ ਟੈਸਟ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਟੈਸਟ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਇਕ tenant ਹੁੰਦਾ ਹੈ, ਜਾਂ fixtures ਵਿੱਚ tenants ਦੇ overlapping IDs ਨਹੀਂ ਹੁੰਦੇ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਜ਼ਾਈਨ ਉਹ ਹਨ ਜੋ ਅਨਸਕੋਪਡ ਕਵੇਰੀ ਲਿਖਣਾ ਹੀ ਔਖਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਹਰ ਵਾਰੀ reviewer 'ਤੇ ਭਰੋਸਾ ਰੱਖਣ।
Multi-tenant ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੋਰ ਸੁਰੱਖਿਅਤ ਖਤਰਾ ਬਹੁਤ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਕਵੇਰੀ ਜੋ tenant ਫਿਲਟਰ ਭੁੱਲ ਜਾਂਦੀ ਹੈ ਉਹ ਕਿਸੇ ਹੋਰ ਦਾ ਡੇਟਾ ਖੋਲ ਸਕਦੀ ਹੈ। ਮਜ਼ਬੂਤ ਇਨਸੋਲੇਸ਼ਨ ਨਿਯੰਤਰਣ ਇਹ ਮੰਨ ਕੇ ਚਲਦੇ ਹਨ ਕਿ ਗਲਤੀਆਂ ਹੋਣਗੀਆਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਿਰਪੇਕ ਕਰਨਗੀਆਂ।
ਹਰ tenant-ਮਾਲਕ ਰਿਕਾਰਡ 'ਤੇ tenant identifier (ਜਿਵੇਂ tenant_id) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ access layer ਨੂੰ ਹਮੇਸ਼ਾ ਇਸ ਨਾਲ reads ਅਤੇ writes ਨੂੰ ਸਕੋਪ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਹੈ “tenant context ਪਹਿਲਾਂ”: ਐਪ tenant ਨੂੰ (subdomain, org ID, ਜਾਂ token claims ਤੋਂ) ਸੁਲਝਾਉਂਦੀ ਹੈ, ਇਸਨੂੰ request context ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਡੇਟਾ ਐਕਸੇਸ ਕੋਡ ਉਸ context ਤੋਂ ਬਿਨਾਂ ਚੱਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦੀ ਹੈ।
ਮਦਦਗਾਰ ਗਾਰਡਰੇਲ:
tenant_id ਦੀ ਲੋੜ ਰੱਖੋ (tenant-ਅੰਦਰ ਟਕਰਾਅ ਰੋਕਣ ਲਈ)।tenant_id ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ cross-tenant ਸੰਬੰਧ ਗਲਤੀ ਨਾਲ ਬਣਨ ਨਾ ਪਾੜਨ।ਜਿੱਥੇ ਸਮਰਥਿਤ (ਖਾਸ ਕਰ ਕੇ PostgreSQL), row-level security tenant ਚੈੱਕਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਆ ਸਕਦੀ ਹੈ। ਨੀਤੀਆਂ ਹਰ SELECT/UPDATE/DELETE ਨੂੰ ਸੁਚਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਸਿਰਫ਼ current tenant ਨਾਲ ਮਿਲਣ ਵਾਲੀਆਂ ਰੋਜ਼ ਹੀ ਦਿਖਾਈ ਦੇਣ।
ਇਹ “ਹਰ ਡਿਵੈਲਪਰ ਨੇ WHERE ਕੌਲਮ ਯਾਦ ਰੱਖ ਲਈ” 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਕੁਝ injection ਜਾਂ ORM ਗਲਤੀਆਂ ਦੇ ਖਿਲਾਫ਼ ਵੀ ਰੱਖਿਆ ਕਰ ਸਕਦਾ ਹੈ। RLS ਨੂੰ ਦੂਜੇ ਲੌਕ ਵਜੋਂ ਮੰਨੋ, ਇਕੱਲੇ ਲੌਕ ਵਜੋਂ ਨਹੀਂ।
ਜੇ tenants ਦੀ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਜ਼ਿਆਦਾ ਹੈ ਜਾਂ compliance ਦੀਆਂ ਕਠੋਰ ਲੋੜਾਂ ਹਨ, ਤਾਂ tenants ਨੂੰ schema (ਯਾਂ ਡੇਟਾਬੇਸ) ਵਾਰ ਵੱਖਰਾ ਰੱਖਣਾ blast radius ਘਟਾ ਸਕਦਾ ਹੈ। ਟਰੇਡ-ਆਫ਼ ਓਪਰੇਸ਼ਨਲ ਢੇਰ ਹੋਣਾ ਹੈ।
Permissions ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਡਿਫਾਲਟ “ਕੋਈ ਐਕਸੈਸ ਨਹੀਂ” ਹੋਵੇ:
ਇਹ ਨਿਯੰਤਰਣ ਇਕੱਠੇ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ: ਮਜ਼ਬੂਤ tenant ਸਕੋਪਿੰਗ, ਜਿੱਥੇ ਹੋ ਸਕੇ ਡੇਟਾਬੇਸ-ਲਾਗੂ ਨੀਤੀਆਂ, ਅਤੇ ਢਿੱਲੇ-ਚੌਣੇ privileges ਜੋ ਗਲਤੀ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਸੀਮਿਤ ਕਰਦੇ ਹਨ।
ਇਨਕ੍ਰਿਪਸ਼ਨ ਉਹਨਾਂ ਕੁਝ ਨਿਯੰਤਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਬਾਕੀ ਇਨਸੋਲੇਸ਼ਨ ਸਤਰਾਂ ਫੇਲ ਹੋਣ 'ਤੇ ਵੀ ਮਦਦ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਾਂਝੇ ਡੇਟਾਸਟੋਰ ਵਿੱਚ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਨੂੰ "ਜਦੋਂ ਚਲਦਾ ਹੈ", "ਜਦੋਂ ਰਿਹਾ ਹੈ", ਅਤੇ "ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਕਿਹੜੇ tenant ਲਈ ਕੰਮ ਕਰ ਰਹੀ ਹੈ"—ਇਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ।
ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਡੇਟਾ ਲਈ, ਹਰੇਕ ਹੌਪ ਲਈ TLS ਲਾਜ਼ਮੀ ਰੱਖੋ: client → API, API → database, ਅਤੇ ਕੋਈ ਵੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਕਾਲ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਡੇਟਾਬੇਸ ਪੱਧਰ 'ਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, non-TLS ਕਨੈਕਸ਼ਨ ਰੱਦ ਕਰਨਾ) ਤਾਂ ਕਿ "ਅਸਥਾਈ ਛੱਡ-ਦਿਓ" ਮਾਮਲੇ ਚੁਪਚਾਪ ਕਾਇਮ ਨਾ ਹੋ ਜਾਣ।
ਐਟ-ਰੈਸਟ ਲਈ, ਡੇਟਾਬੇਸ ਜਾਂ ਸਟੋਰੇਜ-ਪੱਧਰ ਇਨਕ੍ਰਿਪਸ਼ਨ ਵਰਤੋ (managed disk encryption, TDE, encrypted backups)। ਇਹ ਖੋਏ ਹੋਏ ਮੀਡੀਆ, ਸਨੇਪਸ਼ਾਟ ਉਦਘਾਟ, ਅਤੇ ਕੁਝ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦਾ ਹੈ—ਪਰ ਇਹ ਇੱਕ ਬੱਗੀ ਕਵੇਰੀ ਨੂੰ ਦੂਜੇ tenant ਦੀਆਂ ਰੋਜ਼ ਵਾਪਸ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕੇਗਾ।
ਇੱਕ ਸਾਂਝੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੀ ਚਲਾਉਣਾ ਚਲਾਉਣ ਲਈ ਸਧਾਰਣ ਹੈ (ਘੱਟ keys ਨੂੰ ਰੋਟੇਟ ਕਰਨ ਦੀ ਲੋੜ, ਘੱਟ failure modes)। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਜੇ ਉਹ ਕੀ ਲਿਕ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਾਰੇ tenants ਪ੍ਰਭਾਵਿਤ ਹੋ ਜਾਂਦੇ ਹਨ।
ਪ੍ਰਤੀ-tenant ਕੀਜ਼ blast radius ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਗਾਹਕ ਦੀਆਂ ਮੰਗਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਕੁਝ ਉਦਯੋਗਗਾਹਕ tenant-ਨਿਰਧਾਰਿਤ ਕੀ ਨਿਆਮਣ ਚਾਹੁੰਦੇ ਹਨ)। ਟਰੇਡ-ਆਫ਼ ਹੈ ਕਿ ਇਹ ਓਪਰੇਸ਼ਨਲ ਰੂਪ ਵਿੱਚ ਜਟਿਲ ਹੈ: ਕੀ ਲਾਈਫਸਾਇਕਲ ਪ੍ਰਬੰਧਨ, ਰੋਟੇਸ਼ਨ ਸ਼ਡਿਊਲ, ਅਤੇ ਸਹਾਇਤਾ ਵਰਕਫਲੋ (ਉਦਾਹਰਣ ਲਈ, ਜੇ ਇੱਕ tenant ਆਪਣੀ ਕੀ ਅਨੁਮਤੀ ਰੱਦ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ) ਆਦਿ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਧਯਮ ਰਾਹ envelope encryption ਹੈ: ਇੱਕ ਮਾਸਟਰ ਕੀ ਪ੍ਰਤੀ-tenant ਡੇਟਾ-ਕੀਜ਼ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ, ਰੋਟੇਸ਼ਨ ਨੂੰ ਪ੍ਰਬੰਧਨਯੋਗ ਰੱਖਦੀ ਹੈ।
ਡੇਟਾਬੇਸ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਸ ਨੂੰ secrets manager ਵਿੱਚ ਰੱਖੋ, ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ environment variables ਵਿੱਚ ਨਹੀਂ। ਛੋਟੇ-ਅਰੱਸੇ ਵਾਲੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਜਾਂ ਆਟੋਮੈਟਿਕ ਰੋਟੇਸ਼ਨ ਤਰਜੀਹ ਦਿਓ, ਅਤੇ ਸਰਵਿਸ ਰੋਲ ਦੇ ਨਾਲ ਐਕਸੇਸ ਸਕੋਪ ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ ਕੰਪੋਨੈਂਟ ਦੇ ਸਾਹਮਣੇ ਸਮਝੌਤਾ ਹੋਣ 'ਤੇ ਹਰ ਡੇਟਾਬੇਸ ਤੱਕ ਆਟੋਮੈਟਿਕ ਪਹੁੰਚ ਨਾ ਬਣ ਜਾਏ।
tenant ਪਛਾਣ ਨੂੰ ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਮਝੋ। ਕਦੇ ਵੀ ਕਲਾਇੰਟ ਤੋਂ ਆਏ raw tenant ID ਨੂੰ "ਸੱਚ" ਨਾ ਮੰਨੋ। tenant context ਨੂੰ signed tokens ਅਤੇ ਸਰਵਰ-ਸਾਈਡ authorization ਚੈੱਕ ਨਾਲ ਬਾਈਂਡ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਡੇਟਾਬੇਸ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਬੇਨਤੀ 'ਤੇ ਵੈਧਤਾ ਕਰੋਂ।
Multi-tenancy "ਸਧਾਰਨ" ਦ੍ਰਿਸ਼ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਨਹੀਂ ਦੇਖ ਰਹੇ—ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ tenants ਨੂੰ ਇੱਕੋ ਸਿਸਟਮ ਵਿੱਚ ਦੇਖ ਰਹੇ ਹੋ, ਜਿੱਥੇ ਇੱਕ ਗਲਤੀ cross-tenant ਉਲਟ-ਪ੍ਰਭਾਵ ਬਣ ਸਕਦੀ ਹੈ। ਚੰਗੀ auditability ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਦੋਹਾਂ ਘਟਨਾਵਾਂ ਦੀ ਸੰਭਾਵਨਾ ਅਤੇ blast radius ਦੋਹਾਂ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਘੱਟੋ-ਘੱਟ, ਹਰ ਐਕਸ਼ਨ ਜਿਹੜਾ tenant ਡੇਟਾ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ, ਬਦਲ ਸਕਦਾ, ਜਾਂ ਐਕਸੈਸ ਦਿੰਦਾ ਹੈ ਉਸਨੂੰ ਲੌਗ ਕਰੋ। ਸਭ ਤੋਂ ਉਪਯੋਗੀ ਆਡੀਟ ਇਵੈਂਟ ਇਹ ਉੱਤਰ ਦਿੰਦੀਆਂ ਹਨ:
ਅਡਮਿਨ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵੀ ਲਾਗ ਕਰੋ: tenants ਬਣਾਉਣਾ, ਇਨਸੋਲੇਸ਼ਨ ਨੀਤੀਆਂ ਬਦਲਣਾ, row-level security ਨੀਤੀਆਂ ਸੰਪਾਦਿਤ ਕਰਨਾ, keys ਰੋਟੇਟ ਕਰਨਾ, ਅਤੇ connection strings ਬਦਲਣਾ।
ਮਾਨੀਟਰਿੰਗ ਉਹ ਪੈਟਰਨ ਪਛਾਣੇ ਜੋ ਸਧਾਰਣ SaaS ਵਰਤੋਂ ਵਿੱਚ ਅਸਧਾਰਣ ਹਨ:
ਅਲਰਟਾਂ ਨੂੰ actionable runbooks ਨਾਲ ਜੋੜੋ: ਕੀ ਜਾਂਚਣਾ ਹੈ, ਕਿਵੇਂ ਰੋਕਣਾ ਹੈ, ਅਤੇ ਕਿਸਨੂੰ page ਕਰਨਾ ਹੈ।
ਪ੍ਰivilੇਜਡ ਐਕਸੈਸ ਨੂੰ production ਬਦਲਾਅ ਵਜੋਂ ਮਾਨੋ। least-privilege roles, ਛੋਟੇ-ਅਰੱਸੇ ਵਾਲੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ (schema changes, data exports, policy edits) ਲਈ approvals ਵਰਤੋ। ਐਮਰਜੈਂਸੀ ਲਈ ਇੱਕ break-glass ਅਕਾਉਂਟ ਰੱਖੋ ਜੋ ਕਠੋਰ ਨਿਯੰਤਰਿਤ ਹੋ: ਵੱਖਰੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ, ਲਾਜ਼ਮੀ ਟਿਕਟ/ਅਨੁਮਤੀ, ਸਮੇਂ-ਸੀਮਿਤ ਐਕਸੇਸ, ਅਤੇ ਵਧੀਕ ਲੌਗਿੰਗ।
ਰਿਟੇਨਸ਼ਨ compliance ਅਤੇ ਜਾਂਚ ਦੀ ਲੋੜ ਦੇ ਅਨੁਸਾਰ ਸੈੱਟ ਕਰੋ, ਪਰ ਐਸਾ ਸਕੋਪ ਰੱਖੋ ਕਿ tenant ਸਪੋਰਟ ਸਟਾਫ਼ ਸਿਰਫ਼ ਆਪਣੇ tenant ਦੇ ਲੌਗ ਹੀ ਵੇਖ ਸਕੇ। ਜਦੋਂ ਗਾਹਕ audit exports ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਤਾਂ ਕੱਚੇ ਸਾਂਝੇ ਲੌਗਾਂ ਦੀ ਥਾਂ tenant-ਫਿਲਟਰਡ ਰਿਪੋਰਟ ਦਿਓ।
Multi-tenancy ਪ੍ਰਭਾਵੀ ਹੈ ਕਿਉਂਕਿ ਕਈ ਗਾਹਕ ਇਕੋ ਡੇਟਾਬੇਸ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਟਰੇਡ-ਆਫ਼ ਇਹ ਹੈ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਵੀ ਸਾਂਝਾ ਤਜਰਬਾ ਬਣ ਜਾਂਦਾ ਹੈ: ਇੱਕ tenant ਜੋ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਹੋਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ ਹੋਵੇ।
"Noisy neighbor" ਉਹ tenant ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਸਰਗਰਮੀ ਇੰਨੀ ਤੇਜ਼ ਜਾਂ ਜ਼ਿਆਦਾ ਹੈ ਕਿ ਉਹ ਸਾਂਝੇ ਸਰੋਤ ਜ਼ਿਆਦਾ ਉਪਭੋਗ ਕਰ ਲੈਂਦਾ ਹੈ। ਡੇਟਾਬੇਸ "ਟੁੱਟਿਆ" ਨਹੀਂ ਹੁੰਦਾ—ਸਿਰਫ਼ ਉਹ ਉਸ tenant ਦੇ ਕੰਮ ਨੂੰ ਹਿੱਸਾ ਦੇ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਹੋਰ tenants ਨੂੰ ਜ਼ਿਆਦਾ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਇਸਨੂੰ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਦੇ ਸਾਂਝੇ ਪਾਣੀ ਦੇ ਦਬਾਅ ਵਾਂਗ ਸੋਚੋ: ਇੱਕ ਯੂਨਿਟ ਬਹੁਤ ਸਾਰੇ showers ਅਤੇ washing machine ਇਕੱਠੇ ਚਲਾ ਰਹੀ ਹੈ, ਅਤੇ ਹੋਰ ਲੋਕ ਉਹ ਫਰਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਭਾਵੇਂ ਹਰ tenant ਦੀਆਂ rows ਜਾਂ schemas ਅਲੱਗ ਹੋਣ, ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਘਟਕ ਫ਼ਿਰ ਵੀ ਸਾਂਝੇ ਰਹਿੰਦੇ ਹਨ:
ਜਦੋਂ ਇਹ ਸਾਂਝੇ ਪੁੱਲ ਸੇਚੇ ਹੋ ਜਾਂਦੇ ਹਨ, latency ਸਾਰਿਆਂ ਲਈ ਵੱਧ ਜਾਂਦੀ ਹੈ।
ਬਹੁਤ ਸਾਰੇ SaaS ਵਰਕਲੋਡ ਬਰਸਟ ਹੋਏ ਆਉਂਦੇ ਹਨ: ਇੱਕ import, ਮਹੀਨੇ ਦੇ ਅੰਤ ਦੀ ਰਿਪੋਰਟ, ਇੱਕ marketing ਕੈਂਪੇਨ, ਇੱਕ cron ਕੰਮ ਜੋ ਘੰਟੇ ਦੀ ਸ਼ੁਰੂਆਤ 'ਤੇ ਚਲਦਾ ਹੈ।
ਬਰਸਟ ਡੇਟਾਬੇਸ ਦੇ ਅੰਦਰ "ਟ੍ਰੈਫਿਕ ਜ਼ੈਮ" ਬਣਾਉਂਦੇ ਹਨ:
ਇਹ ਬਰਸਟਾਂ ਭਾਵੇਂ ਕੁਝ ਮਿੰਟਾਂ ਲਈ ਹੀ ਹੋਣ, ਕਿਸੇ ਹੋਰ ਕੰਮ ਦੀ ਕਤਾਰ ਨੂੰ ਡਰੇਨ ਕਰਨ ਕਰਕੇ knock-on delays ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
ਗਾਹਕ ਲਈ, noisy-neighbor ਮੁੱਦੇ ਬੇਨਿਸ਼ਾਨ ਅਤੇ ਅਨਿਯਾਇਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਆਮ ਲੱਛਣ:
ਇਹ ਲੱਛਣ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ ਹੁੰਦੇ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਇਨਸੋਲੇਸ਼ਨ ਤਕਨੀਕਾਂ ਦੀ ਲੋੜ ਹੈ (ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ), ਸਿਰਫ਼ "ਹੋਰ hardware" ਨਹੀਂ।
Multi-tenancy ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਗਾਹਕ "ਜ਼ਿਆਦਾ" ਸਾਂਝੇ ਡੇਟਾਬੇਸ ਸਮਰਥਾ ਤੋਂ ਨਹੀਂ ਲੈ ਸਕਦਾ। ਸਰੋਤ ਇਨਸੋਲੇਸ਼ਨ ਉਹ ਗਾਰਡਰੇਲ ਹਨ ਜੋ ਭਾਰੀ tenant ਨੂੰ ਹਰ ਕਿਸੇ ਨੂੰ ਧੀਮ੍ਹਾ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਅਕਸਰ ਨੁਕਸਾਨ unbounded connections ਹੁੰਦਾ ਹੈ: ਇੱਕ tenant ਦਾ traffic spike ਸੈਂਕੜੇ sessions ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਦਬੋਚ ਲੈਂਦਾ ਹੈ।
ਕਠੋਰ کیپس ਦੋ ਥਾਂ ਤੇ ਲਗਾਓ:
ਜੇ ਡੇਟਾਬੇਸ ਸਿੱਧਾ "connections per tenant" ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਤਾਂ ਤੁਸੀਂ ਹਰ tenant ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ pool ਜਾਂ pool partition ਰਾਹੀਂ ਰਾਹ ਦਿਖਾ ਕੇ ਇਸਦੀ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ।
Rate limiting ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਨਿਆਇਵਿਕਤਾ ਲਈ ਹੈ। ਇਸਨੂੰ edge (API gateway/app) ਦੇ ਕੋਲ ਲਾਗੂ ਕਰੋ ਅਤੇ ਜਿੱਥੇ ਸਮਰਥ ਹੈ, ਡੇਟਾਬੇਸ ਦੇ ਅੰਦਰ (resource groups/workload management) ਵੀ।
ਉਦਾਹਰਣ:
ਡੇਟਾਬੇਸ ਨੂੰ "ਭਟਕਣ ਵਾਲੀਆਂ" ਕਵੇਰੀਆਂ ਤੋਂ ਬਚਾਓ:
ਇਹ ਨਿਯੰਤਰਣ graceful ਤਰੀਕੇ ਨਾਲ fail ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ: ਇੱਕ ਸਪੱਸ਼ਟ error ਵਾਪਸ ਕਰੋ ਅਤੇ retry/backoff ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰੋ।
ਪੜ੍ਹਨ ਵਾਲੇ traffic ਨੂੰ primary ਤੋਂ ਦੂਰ ਲਿਜਾਓ:
ਮਕਸਦ ਸਿਰਫ਼ ਗਤੀ ਨਹੀਂ—ਇਹ lock ਦਬਾਅ ਅਤੇ CPU contention ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ noisy tenants ਕੋਲ ਹੋਰ tenants ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੇ ਘੱਟ ਰਾਹ ਹੋਣ।
Multi-tenant ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਅਜਿਹੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਕਿ "ਡੇਟਾਬੇਸ ਧੀਮਾ ਹੈ," ਪਰ ਮੂਲ ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾ ਮਾਡਲ ਹੁੰਦਾ ਹੈ: tenant ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਕੀ ਕੀਤਾ ਗਿਆ, ਫਿਲਟਰ ਕੀਤਾ ਗਿਆ, ਇੰਡੈਕਸ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਰੱਖਿਆ ਗਿਆ। ਚੰਗਾ ਮਾਡਲ tenant-ਸਕੋਪਡ ਕਵੇਰੀਆਂ ਨੂੰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ; ਮਾੜਾ ਮਾਡਲ ਡੇਟਾਬੇਸ ਨੂੰ ਵਧੀਕ ਮਿਹਨਤ ਕਰਵਾਉਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ SaaS ਕਵੇਰੀਆਂ ਵਿੱਚ tenant identifier ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਖੁੱਲ੍ਹਾ ਰੱਖੋ (ਉਦਾਹਰਣ ਲਈ tenant_id) ਅਤੇ ਐਸੇ ਇੰਡੈਕਸ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਇਸ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਅਮਲੀ ਜੀਵਨ ਵਿੱਚ, ਇੱਕ composite index ਜਿਵੇਂ (tenant_id, created_at) ਜਾਂ (tenant_id, status) ਉਹਨਾਂ ਇੰਡੈਕਸਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰੀ ਹੁੰਦੇ ਹਨ ਜੋ صرف created_at ਜਾਂ status ਨੂੰ ਇੰਡੈਕਸ ਕਰਦੇ ਹਨ।
ਇਹ uniqueness ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਜੇ emails ਸਿਰਫ਼ tenant-ਅੰਦਰ unique ਨੇ, ਤਾਂ ਇਸਨੂੰ (tenant_id, email) ਨਾਲ enforce ਕਰੋ ਨਾ ਕਿ ਗਲੋਬਲ email constraint ਨਾਲ।
ਇੱਕ ਆਮ slow-query pattern ਇੱਕ ਅਕਸਮਾਤ cross-tenant scan ਹੁੰਦਾ ਹੈ: ਇੱਕ ਕਵੇਰੀ ਜੋ tenant filter ਭੁੱਲ ਜਾਂਦੀ ਹੈ ਅਤੇ ਟੇਬਲ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਛੇਹ ਲੈਂਦੀ ਹੈ।
ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਆਸਾਨ ਬਣਾਓ:
Partitioning ਇਹ ਘਟਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਕਿਵੇਂ ਕਵੇਰੀ ਨੂੰ ਕਿੰਨਾ ਡੇਟਾ ਦੇਖਣਾ ਪੈਦਾ ਹੈ। ਜਦੋਂ tenants ਵੱਡੇ ਅਤੇ ਅਸਮਾਨਹੋਣ, ਤਾਂ tenant ਅਨੁਸਾਰ partition ਕਰੋ। ਜਦੋਂ ਪਹੁੰਚ ਆਮ ਤੌਰ 'ਤੇ ਹਾਲੀਆ ਹੋਵੇ (events, logs, invoices), ਤਦੋਂ ਸਮੇਂ ਅਨੁਸਾਰ partition ਕਰੋ, ਆਮ ਤੌਰ 'ਤੇ tenant_id ਨੂੰ ਹਰ partition ਵਿੱਚ ਅਗਲਾ ਇੰਡੈਕਸ ਕਾਲਮ ਰੱਖੋ।
ਜਦੋਂ ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਉੱਚੀ peak throughput ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਾਂ ਇੱਕ tenant ਦੀ workload ਸਾਰਿਆਂ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਰਹੀ ਹੋਵੇ, ਤਾਂ sharding 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
“Hot tenants” ਵਧੀਆ read/write ਆਉਂਦੀਆਂ ਹਨ, lock contention, ਜਾਂ oversized indexes ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਉਹਨਾਂ ਨੂੰ per-tenant query ਸਮਾਂ, ਪੰਤੀਆਂ ਪੜ੍ਹੀਆਂ, ਅਤੇ ਲਿਖਣ ਦੀ ਦਰ ਟਰੈੱਕ ਕਰਕੇ ਪਛਾਣੋ। ਜਦ ਇੱਕ tenant dominate ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਅਲੱਗ ਕਰੋ: ਇੱਕ ਵੱਖਰਾ shard/database ਵਿੱਚ ਮੂਵ ਕਰੋ, ਵੱਡੇ tables ਨੂੰ tenant ਅਨੁਸਾਰ ਵੰਡੋ, ਜਾਂ dedicated caches ਅਤੇ rate limits ਲਗਾਓ ਤਾਂ ਕਿ ਹੋਰ tenants ਆਪਣੀ ਗਤੀ ਬਣਾਈ ਰੱਖਣ।
Multi-tenancy ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਵਜੇFail ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨ ਛੋਟੀ ਅਸਮਰਥਤਾਵਾਂ ਨੂੰ ਵੱਡੇ ਸੁਰੱਖਿਆ ਗੈਪ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਘਟਾਊਂ ਵਿੱਚ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਮੰਦਾ ਇਹ ਹੈ ਕਿ ਹਰ ਬਦਲਾਅ, ਜੌਬ, ਅਤੇ deploy ਲਈ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਡਿਫਾਲਟ ਹੋਵੇ।
ਇੱਕ canonical tenant identifier ਚੁਣੋ (ਉਦਾਹਰਣ tenant_id) ਅਤੇ ਇਸਨੂੰ tables, indexes, logs, ਅਤੇ APIs 'ਚ ਲਗਾਤਾਰ ਵਰਤੋਂ। ਇੱਕਰੂਪਤਾ ਸੁਰੱਖਿਆ ਗਲਤੀਆਂ (ਗਲਤ tenant ਨੂੰ ਕਵੇਰੀ ਕਰਨਾ) ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਹੈਰਾਨੀ (ਸਹੀ composite indexes ਦੀ ਘਾਟ) ਦੋਹਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਸੁਰੱਖਿਆ:
tenant_id ਦੀ ਲੋੜ ਰੱਖੋtenant_id ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ composite indexes ਜੋੜੋAsync workers cross-tenant incidents ਦੇ ਆਮ ਸਰੋਤ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ request ਦੇ ਅੰਬੀਐਂਟ context ਤੋਂ “ਬਾਹਰ” ਚਲਦੇ ਹਨ।
ਮਦਦਗਾਰ ਓਪਰੇਸ਼ਨਲ ਪੈਟਰਨ:
tenant_id ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਭੇਜੋ; ambient context 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋtenant_id ਲੌਗ ਕਰੋ ਤਾਂ ਜाँच ਤੇਜ਼ੀ ਨਾਲ ਸਿਕੋਪ ਹੋ ਸਕੇSchema ਅਤੇ ਡੇਟਾ migrations ਐਸੇ ਤਰੀਕੇ ਨਾਲ deploy ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਕਿ ਇੱਕ ਪੂਰਨ synchronized rollout ਦੀ ਲੋੜ ਨਾ ਪਏ।
Rolling changes ਵਰਤੋ:
ਆਟੋਮੇਟਿਕ ਨੈਗੇਟਿਵ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਜਾਣਬੂਝ ਕੇ ਦੂਜੇ tenant ਦਾ ਡੇਟਾ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ release blockers ਵੱਜੋਂ ਰੱਖੋ।
ਉਦਾਹਰਣ:
tenant_id ਨਾਲ background job ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਕਠੋਰ ਫੇਲਿਯਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋBackups ਬਿਆਨ ਕਰਨ ਲਈ ਆਸਾਨ ਹਨ ("ਡੇਟਾਬੇਸ ਦੀ ਨਕਲ ਬਣਾ ਲੋ") ਪਰ multi-tenant ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਕਾਂਡੇ ਕਰਨਾ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਔਖਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕਈ ਗਾਹਕ ਟੇਬਲਾਂ ਸਾਂਝੀਆਂ ਕਰਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਇੱਕ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ ਕਿ ਇੱਕ tenant ਨੂੰ ਕਿਵੇਂ recover ਕਰਨਾ है ਬਿਨਾਂ ਹੋਰਾਂ ਨੂੰ ਖੋਲ੍ਹੇ ਜਾਂ overwrite ਕੀਤੇ।
Full-database backup ਫਿਰ ਵੀ disaster recovery ਲਈ ਬੁਨਿਆਦ ਹੈ, ਪਰ day-to-day support cases ਲਈ ਇਹ ਕਾਫੀ ਨਹੀਂ। ਆਮ ਤਰੀਕੇ:
tenant_id ਨਾਲ ਫਿਲਟਰ ਕੀਤੇ) ਇੱਕ single tenant ਦੀ ਡੇਟਾ بحالی ਲਈਜੇ ਤੁਸੀਂ logical exports 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ export job ਨੂੰ production ਕੋਡ ਵਾਂਗ ਸਮਝੋ: ਇਸਨੂੰ tenant isolation ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਉਦਾਹਰਣ ਲਈ row-level security ਰਾਹੀਂ) ਨਾ ਕਿ ਇੱਕ WHERE ਕਲੌਜ਼ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨਾ ਜੋ ਇੱਕ ਵਾਰੀ ਲਿਖ ਦਿੱਤਾ ਗਿਆ।
Privacy requests (export, delete) tenant-ਸਤਰ ਕਾਰਵਾਈਆਂ ਹਨ ਜੋ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੋਹਾਂ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ। ਕਾਇਮ ਰੱਖੋ ਦੋਹਰਾਉਣ ਯੋਗ, ਆਡੀਟ ਕੀਤੀਆਂ ਵਰਕਫਲੋਜ਼:
ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਕਿਸੇ ਹੈਕਰ ਨਹੀਂ—ਇੱਕ අදਾਏ ਕਰਨ ਵਾਲਾ ਓਪਰੇਟਰ ਹੈ। ਮਨੁੱਖੀ ਗਲਤੀ ਘਟਾਉਣ ਲਈ ਗਾਰਡਰੇਲ:
ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ ਡ੍ਰਿਲ ਤੋਂ ਬਾਅਦ, ਕੇਵਲ "ਐਪ ਚੱਲ ਰਿਹਾ ਹੈ" ਤੇ ਰੁਕੋ ਨਾ। automated checks ਚਲਾਓ ਜੋ tenant ਇਨਸੋਲੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀਆਂ ਹਨ: tenants 'ਚੋਂ ਨਮੂਨਾ ਕਵੇਰੀਆਂ, audit log ਸਮੀਖਿਆ, ਅਤੇ ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ encryption keys ਅਤੇ access roles ਅਜੇ ਵੀ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਸਕੋਪਡ ਹਨ।
Multi-tenancy ਆਮ ਤੌਰ 'ਤੇ SaaS ਲਈ ਚੰਗੀ ਡਿਫਾਲਟ ਹੈ, ਪਰ ਇਹ ਸਦੀਵੀ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਜਿਵੇਂ ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਤੇ ਗਾਹਕ ਮਿਕਸ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ, "ਇੱਕ ਸਾਂਝਾ ਡੇਟਾਸਟੋਰ" ਦਾ ਤਰੀਕਾ ਕਾਰੋਬਾਰੀ ਖਤਰਾ ਬਣ ਸਕਦਾ ਹੈ ਜਾਂ ਡਿਲਿਵਰੀ ਨੂੰ ਮੰਦ ਕਰ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੰਨ੍ਹ ਲਗਾਤਾਰ ਦਿਖਾਈ ਦੇਣ, ਤਾਂ ਸੋਚੋ ਕਿ ਹੋਰ ਇਨਸੋਲੇਸ਼ਨ ਵਧਾਈਏ:
ਤੁਹਾਨੂੰ “ਸਭ ਸਾਂਝਾ” ਅਤੇ “ਸਭ ਡੈਡੀਕੇਟਡ” ਵਿਚੋਂ ਚੁਣਨਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਆਮ ਹਾਈਬਰਿਡ ਢੰਗ:
ਵਧੇਰੇ ਇਨਸੋਲੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਉੱਚ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਖਰਚ, ਜ਼ਿਆਦਾ ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ (migrations, monitoring, on-call), ਅਤੇ ਜ਼ਿਆਦਾ release coordination (ਕਈ ਮਾਹੌਲਾਂ ਵਿੱਚ schema changes) ਲਿਆਉਂਦਾ ਹੈ। ਟਰੇਡ-ਆਫ਼ ਸਪਸ਼ਟ ਪ੍ਰਦਰਸ਼ਨ ਗੈਰੰਟੀਜ਼ ਅਤੇ compliance ਗੱਲਬਾਤਾਂ ਨੂੰ ਸੌਖਾ ਕਰਨਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਨਸੋਲੇਸ਼ਨ ਵਿਕਲਪਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸੰਬੰਧਿਤ ਗਾਈਡਾਂ ਨੂੰ ਸਮੀਖਿਆ ਕਰੋ ਜਾਂ ਯੋਜਨਾਵਾਂ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇੱਕ SaaS ਨੂੰ ਜਲਦੀ ਤੌਰ 'ਤੇ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਬਹੁ-ਕਿਰਾਇਦਾਰ ਅਨੁਮਾਨਾਂ (tenant scoping, RLS-friendly schemas, throttling, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਵਰਕਫਲੋਜ਼) ਨੂੰ ਜਲਦੀ ਟੈਸਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਚੈਟ ਤੋਂ ਇੱਕ ਕਾਰਯਰਤ React + Go + PostgreSQL ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ, planning mode ਵਿੱਚ ਦੁਹਰਾਉਣ ਅਤੇ snapshots ਅਤੇ rollback ਨਾਲ ਡਿਪਲੋਇ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ production ਲਈ architecture ਨੂੰ harden ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਵੋ, ਤਾਂ ਸਰੋਤ ਕੋਡ ਨੂੰ export ਕਰੋ।
A multi-tenant database ਉਹ ਹਾਲਤ ਹੈ ਜਿੱਥੇ ਕਈ ਗਾਹਕ (tenants) ਇੱਕੋ ਹੀ ਡੇਟਾਬੇਸ ਹੁਨਰ-ਸੰਰਚਨਾ (ਅਕਸਰ ਇੱਕੋ schema ਸਹਿਤ) ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਡੇਟਾਬੇਸ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਹਰ tenant ਸਿਰਫ਼ ਆਪਣਾ ਡੇਟਾ ਹੀ ਵੇਖ ਸਕੇ। ਮੁੱਖ ਲੋੜ ਇਹ ਹੈ ਕਿ ਹਰ ਰੀਡ ਅਤੇ ਰਾਈਟ ਉੱਤੇ ਸخت tenant ਸਕੋਪਿੰਗ ਹੋਵੇ।
Multi-tenancy ਆਮ ਤੌਰ 'ਤੇ ਚੁਣਨ ਦੇ ਕਾਰਨ:
ਟ੍ਰੇਡ-ਆਫ਼ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਨਸੋਲੇਸ਼ਨ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਖਿਆਲਸ਼ੀਲ guardrails ਖੁਦ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ।
ਆਮ ਮੋਡਲ (ਜੋ ਵੱਧ ਇਨਸੋਲੇਸ਼ਨ ਤੋਂ ਵੱਧ ਸਾਂਝੇਦਾਰੀ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ):
ਤੁਹਾਡੀ ਚੋਣ ਤੁਹਾਡੀ ਇਨਸੋਲੇਸ਼ਨ ਹੱਦ ਅਤੇ ਓਪਰੇਸ਼ਨ ਭਾਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੇਗੀ।
ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਹੁਣ cross-tenant access ਵੱਲ ਵਧਦਾ ਹੈ ਜੋ ਰੋਟੀਨ ਗਲਤੀਆਂ ਕਰਕੇ ਹੋ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਬਾਹਰੀ ਹਮਲੇ। tenant context (ਜਿਵੇਂ tenant_id) ਨੂੰ ਇੱਕ authorization ਲੋੜ ਵਜੋਂ ਟ੍ਰੀਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੇਵਲ ਇੱਕ ਫਿਲਟਰ ਵਜੋਂ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਦੀਆਂ ਹਕੀਕਤਾਂ (concurrency, caching, retries, background jobs) ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਅਕਸਰ ਕਾਰਨ ਜਿਨ੍ਹਾਂ ਕਰਕੇ cross-tenant leaks ਹੁੰਦੇ ਹਨ:
tenant_id ਬਾਈਂਡ ਕਰਦੇ ਹਨਡਿਜ਼ਾਈਨ ਐਸੇ ਬਣਾਓ ਕਿ ਅਨਸਕੋਪਡ ਕਵੇਰੀਆਂ ਚਲਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇ।
Row-level security (RLS) tenant ਚੈੱਕਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ—ਨੀਤੀਆਂ SELECT/UPDATE/DELETE ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਰੋਜ਼ ਵੇਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ ਜੋ current tenant ਨਾਲ ਮੈਚ ਕਰਦੀਆਂ ਹਨ। ਇਹ “ਹਰ ডਿਵੈਲਪਰ ਨੇ WHERE ਲਾਈਨ ਯਾਦ ਰੱਖੀ” ਉੱਤੇ ਨਿਰਭਰਤਾ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਐਪ-ਲੈਅਰ ਸਕੋਪਿੰਗ, least privilege ਅਤੇ ਮਜ਼ਬੂਤ ਟੈਸਟਿੰਗ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ। RLS ਨੂੰ ਇਕ ਵਾਧੂ ਲੌਕ ਵਜੋਂ ਲਵੋ, ਇਕੱਲਾ ਨਾਹ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨੀਵ ਹੈ:
tenant_id ਹੋਣਾtenant_id ਸ਼ਾਮਲ ਕਰਦੇ ਹਨਇਨ-ਟ੍ਰਾਨਸਿਟ ਅਤੇ ਐਟ-ਰੈਸਟ ਦੋਹਾਂ ਲਈ ਇਨਕ੍ਰਿਪਸ਼ਨ ਲਾਭਦਾਇਕ ਹੈ, ਪਰ ਇਹ ਹਰ ਖਤਰੇ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ:
ਹੀਰਿੰਗ ਲਈ envelope encryption ਵਰਗੀ ਰਣਨੀਤੀ ਇੱਕ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਦਿੰਦੈ: ਮਾਸਟਰ ਕੀ per-tenant data keys ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ। tenant ਪਛਾਣ ਨੂੰ ਸੁਰੱਖਿਆ-ਨਿਰਭਰ ਸਮਝੋ: ਕਲਾਇਂਟ ਤੋਂ ਆਏ raw tenant ID ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ; ਇਸਨੂੰ signed tokens ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਚੈੱਕ ਨਾਲ ਬਾਈਂਡ ਕਰੋ।
Noisy neighbor ਉਹ tenant ਹੁੰਦਾ ਹੈ ਜਿਸ ਦੀ search/ਬਲਾਕ workload ਸਾਂਝੇ ਸਰੋਤਾਂ ਨੂੰ ਬੇਹੱਦ ਖਤਮ ਕਰ ਦੇਂਦੀ ਹੈ (CPU, memory, I/O, connections), ਜਿਸ ਨਾਲ ਹੋਰ tenants ਲਈ latency ਵਧ ਜਾਂਦੀ ਹੈ। ਨਿਮਨ ਲਾਗੂ ਕਰਨ ਜੋੜੇ ਕਾਰਜ:
ਮਕਸਦ fairness ਹੈ, ਸਿਰਫ਼ ਕੱਚੀ throughput ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਲਗਾਤਾਰ ਦੇਖਦੇ ਹੋ ਕਿ:
ਤਦੋਂ ਇਨਸੋਲੇਸ਼ਨ ਵਧਾਉਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਹੋਰ ਹਾਈਬਰਿਡ ਵਿਕਲਪਾਂ: ਕੁਝ top-tier tenants ਨੂੰ ਅਲੱਗ ਡੇਟਾਬੇਸ/ਕਲੱਸਟਰ ਵਿੱਚ ਰੱਖੋ, tiered plans (shared vs dedicated), ਜਾਂ heavy tenants ਲਈ analytics/reporting ਨੂੰ ਵੱਖਰੇ stores ਵਿੱਚ ਰੱਖੋ।
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਗਲਤੀਆਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਜਾਣ।