Разработка 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 фреймворке.

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

Story Mapping: мощный инструмент в арсенале разработчиков

Эта статья снова родилась просто из повседневной практики. Признаться, Story Map для проектов мы начали строить не так давно, до этого мы обходились просто написанием общих концептов. Однако после внедрения Story Mapping мы сразу получили массу плюсов от этой практики. А плюсы эти появляются еще до того, как начинается непосредственно разработка проекта. В общем, сегодня расскажу о том, как мы это делаем и что в итоге получаем.

Проектирование высоконагруженных приложений. Часть 4. Отложенная обработка данных.

В предыдущих статьях мы рассмотрели основные способы оптимизации и масштабирования frontend-ов, backend-ов и баз данных. Этих начальных знаний уже достаточно для того, чтобы у вас в голове сложилось понимание того, как проектируются и работают распределенные системы, которым приходится обрабатывать огромное количество задач.

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

Проектирование высоконагруженных приложений. Часть 3. База данных.

В предыдущей статье мы рассмотрели frontend и backend, разобрали возможные способы их оптимизации и масштабирования. В этой статье мы будем говорить о базах данных, очень важном звене в нагруженных системах. Попробуем разобраться, какие существуют подходы к масштабированию базы данных. Сразу скажу, что это, пожалуй, самая сложная тема.

Проектирование высоконагруженных приложений. Часть 2. Frontend и Backend.

В первой статье мы вспомнили все основные определения и понятия, чтобы дальше разговаривать на одном языке и понимать друг друга. Мы остановились на трехзвенной архитектуре и поняли, что каждое звено должно иметь свою зону ответственности: frontend делает первичную обработку запроса (возможно сразу отвечает клиенту), backend делает основные вычисления и обрабатывает данные, полученные от третьего звена, — хранилища.

Теперь давайте подробнее обсудим Frontend и Backend с точки зрения масштабирования и оптимизации.

Проектирование высоконагруженных приложений. Часть 1. Начало.

Основным направлением деятельности нашей компании является создание интернет-проектов, потенциально рассчитанных на средние и высокие нагрузки. Такие проекты требуют иногда совершенно другого подхода к проектированию архитектуры в отличие от типичных корпоративных приложений. Нам приходится изучать много материалов по теме highload.

Этой публикацией я хочу начать серию небольших статей, в которых раскрою основные темы, необходимые для понимания устройства систем, рассчитанных на работу под высокими нагрузками. Эти статьи являются компиляцией нашего опыта, полученного при работе над сложными проектами, а также опыта наших коллег и материалов с конференций Highload++. 

Начну с самого начала.

Принцип устойчивых зависимостей (Stable Dependencies Principle)

Всем привет!
Сегодня я расскажу о принципе устойчивых зависимостей, знание которого просто необходимо для грамотного проектирования и распределения ответственностей и зависимостей между компонентами системы.