Sharding на уровне приложения

Question

Я разрабатываю мультитенантную систему и рассматриваю возможность разделения на арендаторах на уровне приложений вместо базы данных.

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

Фактический осколок содержит как код приложения, так и полные данные для этого арендатора.Этими сегментами будут серверы LNMP (Linux, Nginx, MySQL / MongoDB, PHP).

Процесс маршрутизатора должен действовать как прокси.Он должен иметь возможность запускать некоторый код для определения целевого сегмента для входящего запроса на основе коллекции, хранящейся в некоторых локальных БД или файлах.Чтобы иметь возможность лучше масштабировать это, я рассматриваю возможность того, чтобы сами шарды действовали как маршрутизаторы, чтобы они могли запускать обратный прокси-сервер, который перенаправит запрос соответствующему шарду.Может быть, экземпляр nginx, работающий на шарде, также может выступать в качестве этого обратного прокси.Но как он будет выполнять логику приложения, необходимую для сопоставления запроса с соответствующим шардом.

Буду признателен за любые идеи и предложения по реализации этого маршрутизатора.

Спасибо

Answer 1

Другой вариант - использовать такой продукт, как dbShards. dbShards - это единственный продукт шардинга, который шардит на уровне приложения. Таким образом, вы можете использовать любую СУБД (Postgres, MySQL и т. Д.) И при этом иметь возможность ограждать свою базу данных без необходимости устанавливать какой-либо прокси между ними. Многие другие продукты шардинга полагаются на прокси-сервер для указания транзакций на правильный шард, но dbShards знает, куда идти без необходимости «спрашивать» кого-либо еще.

Отличный продукт. dbshards

Answer 2

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

Что касается разделения на уровне приложений в целом, позвольте мне поделиться собственным опытом:

Версия 1 нашего высокопроизводительного SaaS-продукта рассылается на уровне приложений.Вы обнаружите, что изменение производительности по мере роста будет большой головной болью, если вы будете отвергать решения типа SQL на уровне приложений или вам придется написать значительный инструментарий для автоматизации процесса.

Мы перешли на MongoDB (после рассмотрения нескольких альтернатив, включая Cassandra), в немалой степени из-за всей встроенной поддержки изменения баланса / ребалансировки по мере роста данных.

Если вашему приложению не нужны реляционные возможности MySQL, я бы посоветовал сосредоточитьсяваши усилия на MongoDB (так как вы уже определили это как возможную платформу данных), если вы ожидаете более чем скромный рост данных.Разрешить MongoDB обрабатывать данные.