Структура сервиса SaaS: монолитный или распределенный

[scorpion-ds]

Сервис типа SaaS, очень краткое описание функционала:

"Левая часть":
Каждый клиент сервиса, загружает туда прайсы товаров, от различных поставщиков. Количество товаров в прайсе может достигать 10000 и таких прайсов у клиента может быть много.

После определенной обработки, все обнаруженные товары в прайсах размещаются в таблице БД.

"Правая часть":
У клиента есть свой каталог товаров, который к примеру выгружается из его магазина.

"Связывание":
Клиент привязывает к товарам своего каталога товары поставщика.

"Выход":
На выходе, есть каталог магазина со связанными ценами от поставщиков (есть различные правила формирования наценки на цена поставщиков), эти данные отправляются обратно в магазин клиента.

Техническая часть:

• Symfony 3;
• MySQL, MongoDB (только для хранение не обработанных прайсов)

Рассматриваю два варианта реализации сервиса:

• Монолитный - вся система строится на одной БД (кроме временного хранение прайсов в MongoDB).
• Раздельный - под каждого клиента разворачивается своя копия приложения, со своей БД, также есть "биллинг сервис", который ведет учет клиентов и обеспечивает развертывание копий системы под новых клиентов.

Выбор:
Монолитный вариант очевидно проще реализовать, но есть опасение, что БД очень быстро разрастется, множество клиентов у каждого десятки тысяч товаров.
Возможно, стоит использовать другую БД, которая позволит не бояться разрастания?

Раздельный, сложней в реализации и поддержке (обновление всех копий системы).


Может, есть еще какие-то подходы к реализации?

Сроки очень сжатые, первая версия, может быть без рабочего SaaS, но с рабочим основным приложением до конца лета (2-3 бекенд разработчика, 1 фронтенд), потому ошибок с выбором пути быть не должно.

 

[Adelf]

Монолитный + быть готовым к кластеризации(шардингу).

 

[scorpion-ds]

Монолитный

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

 

[MiksIr]

Возьми PostgreSQL, и строй частичные индексы ) Но в общем Adelf прав, начинать нужно с простого, особо когда "Сроки очень сжатые"

 

[c0dex]

Напомнило http://bash.im/quote/208514

 

[AnrDaemon]

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

Анипофикк?
Двигай услугу в сторону отказа от загрузки прайсов, чтобы клиенты просто друг на друга линковались.
API, все дела.

 

[hell0w0rd]

А мне кажется мелкие сервисы - огонь в такой ситуации. У тебя будет 25 различных форматов входных данных, их все удобнее писать отдельно друг от друга. Еще 1 сервис - принимает уже в твоей структуре данные. Биллинг отдельно, фронтенд отдельно. Это дольше, но выгоднее в долгой перспективе.

 

[grigori]

Раньше каждый блог был hiload, а сейчас каждый каталог - SAAS.
На самом деле, пофиг как делать. Проблемы будут в обоих случаях, это я по своим проектам говорю, решал в обоих вариантах.
у @Adelf просто склонность к монолитной архитектуре, надо делать поправку - даже там, где явно надо разделять, он все-равно делает одно приложение

Миллион записей каталога - это не слишком много для MySQL, если запросы затюнены. Структура получается EAV - запросы на пару экранов, куча join-ов.

Другой вариант - шардинг каталогов по разным таблицам. То есть в отдельной таблице хранится каталог произвольной структуры, в другой таблице описывается структура, и общая таблица с названиями таблиц каталога. Денормализация, по сути.
Хорошо тем, что тюнить надо будет позже. Плохо тем, что ORM на такое совсем не рассчитаны, и много запросов придется писать ручками. Ну и бороться с мусорными таблицами и кучей других проблем, необходимостью прописывать индивидуальные индексы по каждой табличке и т.п. Зато есть бонусы - легко реализовать версионность и дифференциальное обновление, например.

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

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

 

[WMix]

Да брось ты, 100 клиентов это первый миллион записей, 1000 это всего 10ка. вытянет ... Чую что клиентов там много меньше.. На край прослойку базу/таблицу на чтение и там уже делить на клиентов.. Как раз монгу туда лучше всего. Дальше базу нужно покрепче выбирать.

 

[Adelf]

у @Adelf просто склонность к монолитной архитектуре

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

 

[scorpion-ds]

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

Во мнения разделились так:
- Самое кардинальное предложение, это использовать в качестве БД MSSQL или Oracle, по утверждениям, автора идеи, запросы будут работать быстрей. Я не согласен с этим утверждением и предложил, что, если мы все же будем использовать такие серьезные СУБД, то использовать их на полную, то есть не через всякие Symfony, а использовать все их возможности, к примеру, если не ошибаюсь, то у Oracle есть и возможности для разработки UI или хотя бы через REST с ним общаться, но вся логика должна быть на нем.

- Использовать монолитную систему, но к БД применить партицирование, если честно, то я раньше такого никогда не делал, так что своего мнения пока нет.

- Использовать монолитное приложение на PHP, а БД переключать налету, то есть приложение одно с какой-то общей частью БД, но для каждого клиента есть и своя БД.


Больше беспокойство вызывает скорость работы системы, сейчас мне даны такие установки:
10000 клиентов;
500 прайсов;
10000 позиций в каждом прайсе;
Итого: 10000*500*10000 = 50000000000 записей.

Сейчас договорились, что делаем базовую модель данных, забиваем ее тестовыми данными и тестим, что выйдет по запросам.

 

[флоппик]

- Самое кардинальное предложение, это использовать в качестве БД MSSQL или Oracle, по утверждениям, автора идеи, запросы будут работать быстрей. Я не согласен с этим утверждением и предложил, что, если мы все же будем использовать такие серьезные СУБД, то использовать их на полную, то есть не через всякие Symfony, а использовать все их возможности, к примеру, если не ошибаюсь, то у Oracle есть и возможности для разработки UI или хотя бы через REST с ним общаться, но вся логика должна быть на нем.

- Использовать монолитную систему, но к БД применить партицирование, если честно, то я раньше такого никогда не делал, так что своего мнения пока нет.

- Использовать монолитное приложение на PHP, а БД переключать налету, то есть приложение одно с какой-то общей частью БД, но для каждого клиента есть и своя БД.

Слон, Заяц и Осёл решили строить мост,
Но оказалось, что вопрос не прост
И многое для всех троих неясно…
«Поставить нужно мост, — твердил упрямый Слон, —
На каменных быках, закованных в бетон!»
«Нет! — Заяц возражал. — Быки? Бетон? Ужасно!
Мост должен лёгким быть! Всё, что легко, — прекрасно!»
«Послушайте, друзья! — седой Осёл изрёк. —
Нам следует сперва решить единогласно,
Как будем строить? Вдоль иль поперёк?»

 

[Adelf]

но вся логика должна быть на нем

неправильная мысль и вообще, не вздумайте

но для каждого клиента есть и своя БД.

А вы готовы саппортить 10 тысяч БД?

У вас нет пока никаких реальных данных. И, похоже, клиентов 10к тоже нет. Тебе кстати был бы весьма полезен мастер-класс Димы Бородина. Я разок послушал. Он хорошо обьясняет основы шардинга. Думаю, у тебя вопросы бы быстро отпали.

 

[Breeze]

использовать в качестве БД MSSQL или Oracle, по утверждениям, автора идеи, запросы будут работать быстрей

Дада, они всё сами сделают и напрягаться не надо, там libastral.so из коробки.
Автор идеи наверняка сертифицированный DBA?

Заодно посчитайте объёмы этих 50млрд записей вместе с индексами и сопутствующими данными, СХД для этого и как будут делаться бэкапы.
Ведь система по ТЗ должна иметь несколько девяток на доступность.

 

[scorpion-ds]

неправильная мысль и вообще, не вздумайте

Почему? Мне друг показывал результаты его экспериментов, он к свой БД создавал UI на Java (я так понял возможности их коробки), вроде работало, но деталей я не знаюю

Дада, они всё сами сделают и напрягаться не надо, там libastral.so из коробки.
Автор идеи наверняка сертифицированный DBA?

Как бы там ни было, я спорить не могу так как в крайний раз пересекался с ней когда делал курсовую работу, 10 лет назад. Я только интуитивно не верю, что для запросов может быть какой-то реальный прирост производительности, могу допустить только, если использовать ее все возможности триггеры, функции, процедуры и т.п., тогда возможно.

У вас нет пока никаких реальных данных. И, похоже, клиентов 10к тоже нет. Тебе кстати был бы весьма полезен мастер-класс Димы Бородина. Я разок послушал. Он хорошо обьясняет основы шардинга. Думаю, у тебя вопросы бы быстро отпали.

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

 

[Adelf]

Почему? Мне друг показывал результаты его экспериментов, он к свой БД создавал UI на Java (я так понял возможности их коробки), вроде работало, но деталей я не знаюю

цитировал я другое. Не делайте логику на PL/SQL. Этот подход уже давно должен умереть.

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

я думаю, у тебя плохая интуиция ) триггеры производительность не поднимут.
Есть мнение, что юзать вам надо бесплатную СУБД, чтобы легко, при желании, ставить ее на сколько угодно большом количестве серверов. Ваша главная проблема не хитрые запросы, а потенциально большой объем данных.

 

[Breeze]

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

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

а вот партиционирование наоборот несильно подходит, так как нас интересуют не недавно добавленные данные

Партиционирование это не только даты, но и категории, например, или возраст =) Шардинг и партиционирование считай синергитичные вещи.

 

[hell0w0rd]

Да вы пляшите от задачи. Вот есть у вас задача "У клиента есть свой каталог товаров, который к примеру выгружается из его магазина." - сюда так и просится отдельный сервис. Дальше, очевидно, идет сервис, который имеет свою структуру данных, к которой предыдущие сервисы приводят результат работы.
"На выходе, есть каталог магазина со связанными ценами от поставщиков (есть различные правила формирования наценки на цена поставщиков), эти данные отправляются обратно в магазин клиента." - работает с REST-API сервиса, который имеет вашу структуру данных.

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

 

[Adelf]

@hell0w0rd, мы об одном. ты о другом

 

[WMix]

@scorpion-ds, 50000000000 это очень, очень, очень много (при одном байте на запись это 50ТБ). так что форум совсем не правильное место для пойска решения.
немного смущают сроки, там бюджентая часть будет дольше решаться