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.

Sharing data in a multitenant architecture

434 visualizaciones

Publicado el

Multitenant architectures provide great opportunities for scaling, but most solutions do not provide a way to share data between accounts. In this talk, we will introduce core concepts of multitenancy and explore a data model that allows two clients to share subsets of data instantly using a Laravel application and MySQL database.

Publicado en: Datos y análisis
  • Sé el primero en comentar

Sharing data in a multitenant architecture

  2. 2. About Dan Fey Grew up in northern NJ Back-end engineer at Crowdskout in DC Work on API and data layers in PHP using Laravel Work with MySQL, Mongo, and Elasticsearch
  3. 3. Crowdskout Data collection, analytics, and outreach SaaS platform Collects, normalizes, and matches data for customers Provides tools for segmenting audiences, building dynamic charting, and acting on segments
  4. 4. In this talk Foundations of Multitenancy Data sharing with Multitenancy Laravel/MySQL application demonstrating data sharing with Multitenancy
  5. 5. Multitenant CRM/Contact List Build a scalable, self-serve CRM application View profiles/contacts Allow customers to share subsets of profiles Customers have multiple users that can view their data
  6. 6. Multitenancy Sharing resources among multiple tenants (i.e. accounts/customers/users) Can save on infrastructure, development, maintenance Great for scaling Three general forms: separate databases, separate schema, shared schema.
  7. 7. No Multitenancy
  8. 8. Separate Databases Separate database servers per tenant Application shared Can extend/change database/schema per tenant Adding tenants requires infrastructure Each tenant has isolated database resources
  9. 9. Separate Databases
  10. 10. Separate Schemas Same database server, different schemas per tenant Application shared Can extend/change schema per tenant, but not database type/configuration Less resource isolation Adding tenants may require operations/migrations
  11. 11. Separate Schemas
  12. 12. Shared Schema Shared application, database server, and schema for all tenants Harder to extend/change schema or database per tenant Harder to isolate resources Adding tenants requires minimal changes
  13. 13. Shared Schema
  14. 14. Shared Schema Shape Food Plant Tenant
  15. 15. Sharing With Multitenancy Multiple tenants share subsets of data Sharing configurable and non permanent Tenants share changes to data
  16. 16. Sharing With Multitenancy Shape Food Plant Tenant
  17. 17. Multitenant CRM/Contact List Build a scalable, self-serve CRM application View profiles/contacts Allow customers to share subsets of profiles Customers have multiple users that can view their data
  18. 18. Demo 1 Create Customer table and model Create Profile, Name, Email tables and models Populate Users, Customers, and Profiles Login to app 48d18621
  19. 19. Migrations
  20. 20. Models
  21. 21. Controller
  22. 22. Pivoting Customers with Users user_id name 1 Dan 2 Bob 3 Amy customer_id user_id Google 5 1 Dan Apple 6 1 Dan Apple 6 2 Bob Google 5 3 Amy customer_id name 5 Google 6 Apple
  23. 23. Demo 2 Add customer_user pivot table and model Add belongs to many relationships php artisan db:seed --class=CustomerUserSeeder
  24. 24. Migration customers customer_user users
  25. 25. Sources Data Model profile_id first last source_id 1 Kenyon Harris 2 2 Bette Kemmer 1 3 Oscar Gorczany 1 profile_id email source_id 1 1 1 2 2 1 3 1 source_id name 1 Imported 2 Web Form
  26. 26. Pivoting Customers with Sources customer_id source_id Apple 6 1 Apple Imported Apple 6 3 Public Data Google 5 3 Public Data customer_id name 5 Google 6 Apple source_id name 1 Apple Imported 2 Google Forms 3 Public Data
  27. 27. Demo 3 Add sources table, add source_id to profile data tables Adding query scopes for access control Show access filtering Show adding/removing access fd0eafa
  28. 28. Constraining sources
  29. 29. customer_user
  30. 30. Advantages of Sources Data Model Instantly share/remove large subsets of data Updates to data points shared between customers Data sources are isolated for change/cleaning/ deleting Granular to row level Model is scalable
  31. 31. Issues with Sources Data Model Duplicate data Requires matching Application code can get complex
  32. 32. Code tweaks for scalability Cache requests to high use tables and queries users sources client_users client_sources Add scrolling support with LIMIT and OFFSET Use Query Builder instead of Eloquent or even raw queries when necessary
  33. 33. Caching example
  34. 34. Extending - additional profile tables Examples: date of birth, gender, phone numbers Add new table with new fields including profile id and source id Add new info to the views to display Also works with activities like emailings, phone calls, or page views
  35. 35. Additional profile tables date_of_births prf_profiles_id int date_of_birth datetime source_id int phones prf_profiles_id int phone_number string source_id int genders prf_profiles_id int gender enum('male', 'female', 'other') source_id int phone_calls prf_profiles_id int customer_id int contact_datetime datetime phone_number string source_id int
  36. 36. QUESTIONS Get slides and leave feedback:
  37. 37. Extending - add user permissioning Examples: some users can only see names, not email addresses Add new table for permissions, and a pivot table for user_permissions Check permissions before querying data to limit access to certain tables
  38. 38. User Permissions user_id permission_id George 6 1 View Emails George 6 2 View Names Dan 5 2 View Names user_id name 5 Dan 6 George permission_id name 1 View Emails 2 View Names
  39. 39. Extending - adding search capabilities Examples: search for profiles by name, email, etc. Possible on smaller scales, but full-text search is difficult to scale with MySQL Elasticsearch is great for this, but adds complexity Data must be replicated into Elasticsearch and kept in-sync Does not use SQL for querying