Разработка SaaS на Django и Python. Часть 2. Шардинг базы данных (multi-tenant)

В предыдущей статье мы затронули тему размещения аккаунтов на отдельных поддоменах, а так же способ реализации публичного API в обычном приложении Django (с учетом того, что серверная сторона уже реализована в виде WebAPI для SPA-приложения).

Сегодня мы поговорим о шардинге баз данных и о том, как его можно применять при разработке SaaS продуктов. Частично о шардинге мы уже рассказывали ранее в серии статей о проектировании высоконагруженных веб-приложений: База данных. Рекомендую обратиться к этому материалу, т.к. тема оптимизации работы с БД достаточно сложная.

Сегодня речь пойдет по большей части о практике. Мы наглядно покажем (с примерами кода), как можно реализовать шардинг базы данных в SaaS проекте на Django, Python и PostgreSQL/MySQL.

Разработка SaaS на Django и Python. Часть 1. Поддомены и публичный API

Вдохновившись интересными решениями на последних наших проектах, я решил описать то, как можно реализовать три типичные составляющие SaaS проекта на Django и Python.

Материал будет разбит на две части, в которых мы рассмотрим следующие темы.

1. Размещение каждого аккаунта на отдельном поддомене; 
2. Простой и быстрый способ выделить публичный API вашего сервиса; 
3. Размещение данных каждого аккаунта в отдельных базах данных.

Сегодня речь пойдет о первых двух пунктах. Рассказ о размещении аккаунтов в разных базах данных заслуживает отдельной статьи.

На сервере мы часто используем Django и Python, Celery и Redis для реализации распределенной очереди задач, а в качестве СУБД PostgreSQL или MySQL. Клиентская сторона обычно реализуется на AngularJS, ReactJS или другом MVVM/MVC фреймворке.

Исходя из этого, далее по тексту я буду предполагать, что на вашем проекте используется подобный технологический стек, хотя это не принципиально.