Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Multi Tenancy With Python and Django

10.382 visualizaciones

Publicado el

Multi-Tenancy is a critical component of any Software as a Service (SaaS) application, which enables one application instance to serve multiple organizations, or tenants. This presentation by Scott Crespo covers the basics of multi-tenant architectures, and how to implement multi-tenancy using Python, Django, and the open-source project known as Django Tenant Schemas.

Publicado en: Tecnología
  • Hey I pick up great truck. Saved a lot, thanks. ✱✱✱
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • If we are speaking about saving time and money this site ⇒ ⇐ is going to be the best option!! I personally used lots of times and remain highly satisfied.
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Follow the link, new dating source: ❶❶❶ ❶❶❶
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Dating for everyone is here: ❶❶❶ ❶❶❶
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Multi Tenancy With Python and Django

  1. 1. Multi-Tenancy With Django Scott Crespo Software Engineer Director, Orlando Data Science
  2. 2. 1. Multi-Tenant Architectures 2. Django Tenant Schemas Explained 3. Basic Use + Tips and Tricks
  3. 3. Definition Multi-Tenancy: A software architecture where a single application instance enables multiple organizations (tenants) to view their data. *This is a key component of XaaS (i.e. Something as a Service)
  4. 4. Architectures Multi-tenant architectures can be placed on a continuum Shared Separate
  5. 5. Common Approaches to Multi-Tenancy
  6. 6. Shared Architecutre One Database + One Schema One database instance, and one public schema serve all tenants. Pros - Easy to build if data layer is simple - Every user on same domain (might be desirable) - Only use if a Tenant has exactly one user. Cons - Expensive (Makes lots of calls to db for tenant object)
  7. 7. Isolated Architecture Multiple Databases Each tenant has their own database instance Pros - Most Secure - Easier disaster recovery - Not expensive for compute resources Cons - Difficult to scale - Expensive storage resources - Difficult to share data across tenants
  8. 8. Hybrid Architecture One Database – Multiple Schemas One database instance for all tenants. Each tenant gets a dedicated schema. Shared 'public' schema Dedicated 'tenant' schema
  9. 9. What's a Schema? Acts as a namespace in Postgres Adds an additional layer of organization/isolation to the database (Database → Schema → Table) ex) SELECT * FROM schema_name.table When a schema is not specified in the connection or query – only the 'public' schema is accessed Schemas to be queried can be specified in the app's database connection via 'SEARCH_PATH' parameter
  10. 10. One Database – Multiple Schemas Pros - Scalable - Cheap - Simple - Semi-secure - Sharable Cons - Difficult disaster recovery - Less-secure than dedicated db's
  11. 11. Django Tenant Schemas Implements Multi-Schema Approach Requires PostgreSQL Installation: $ pip install django-tenant-schemas Docs:
  12. 12. Features 1.Tenant-based Subdomains 2.Postgres Support
  13. 13. The Tenant Object Stored on the 'public' schema Contains 2 Critical Fields - domain_url – the tenant's domain ( - schema_name – the schema where the Tenant's isolated data is stored (tenant_jw8j23jp)
  14. 14. Request Routing 1.User makes a request 2.Middleware looks up tenant object on the public schema and returns schema_name Tenant.objects.get(domain=request.domain).schema_name 1.Tenant_Schema's database wrapper adds schema_name to the connection's SEARCH_PATH cursor.execute('SET search_path = public, schema_name') 1.Subsequent Requests include schema_name in the search path
  15. 15. Basic Use Specify TENANT and SHARED apps  Caution! Don't include new tenant registration on tenants' apps Use the tenant_schemas postgres backend Use the tenant schemas middleware
  16. 16. Basic use  Create a tenant app that contains your tenant model (i.e. organization, company, etc).  Use tenant_schema's mixin - domain_url - schema_name from tenant_schemas.models import TenantMixin class Company(TenantMixin) company_name =models.CharField(max_length=255L) about = models.TextField(blank=True) auto_create_schema = True
  17. 17. The app containing your tenant model should remain in the project's root directory. Otherwise tenant_schemas can't find it. |-- apps | |-- | |-- app1 | |-- app2 | |-- app3 |-- Project | |-- | |-- | |-- settings.pyc | |-- | `-- |-- `-- tenant |-- |-- |-- |-- `-- * you could try simlinks as a work-around, but not recommended
  18. 18. Basic Use Command Line & DNS Use tenant_schemas command wrapper for db commands  Use sync_schemas and migrate_schemas  DO NOT use syncdb or migrate Server & DNS - Make sure to use subdomain wildcards
  19. 19. Basic Use Custom Commands Create a 'make_tenants' custom command - Must create a public tenant and a private tenant to complete creation of the database
  20. 20. Custom Command: from lawfirm.models import LawFirm from import NoArgsCommand import os if os.environ['DJANGO_SETTINGS_MODULE'] == 'settings.base': from settings.base import BASE_URL else: from import BASE_URL class Command(NoArgsCommand): def handle_noargs(self,**options): # create your public tenant LawFirm(domain_url=BASE_URL, schema_name='public', firm_name='LawCRM', ).save() #test tenant to verify sub-domain routing LawFirm(domain_url='test.'+BASE_URL, schema_name='test', firm_name='Test Firm', ).save()
  21. 21. Schema Naming Schemes Auto-generate tenant schema names and enforce uniqueness. Prefix with 'tenant_' Append a hash to the end *Schema name must begin with a letter, $, or underscore Example Database: - public - test dev
  22. 22. Modify Search Path on the Fly (this took time to figure out) from django.db import connection connection.set_tenant(tenant) # set_tenant() accepts tenant object, NOT # tenant_name!
  23. 23. Important Decision Tenant Model on Public Schema User Model on Public Schema - Easy - Less Secure - User More Portable Tenant Model on Public Schema User Model on Private Schema - Not so easy - More secure - User Less Portable VS
  24. 24. Thanks! Scott Crespo