Нужно сделать SaaS сервис. Приложение досталось готовое, но на одного пользователя (MySQL). В принципе его можно доработать на несколько пользователей, поэтому стоит выбор:
1 - использовать одно базу
2 - использовать отдельную базу для каждого пользователя
Разделять по таблицам не вижу возможным, потому что это много работы и проще приложение с нуля написать.
Основная проблема это то что база разрастется.
Для первого варианта можно использовать шардинг партицирование
Второй вариант нравится больше потому что если будут проблемы с какой-то базой остальные пользователи смогут спокойно продолжать работать.
Кто-то пишет о возможных проблемах с обновлением базы для всех пользователей (10 000 пользователей = 10 000 баз), но я не вижу проблем написать скрипт для этого, да и мониторинг в принципе можно автоматизировать.
К тому же нужно добавлять подписку и биллинг.
Для первого варианта нужно дорабатывать приложение (также сделать клиентский аккаунт и аккаунт админа).
Для второго варианта приложение придется изменить только для определения какую базу/адрес использовать .
например адрес name1.domain.com будет использовать базу name1, а name2.domain.com будет использовать базу name2 на другом сервере.
Адрес серверов баз а паролей хранить в sqlite (что-бы не зависеть от mysql).
И для второго варианта писать отдельную админ панель где клиент будет оплачивать подписку и т.п. и где администратор может управлять этими клиентами и базами. Обновлять данные sqlite базы (sqlite позволяет работать с несколькими подключениями).
Поделитесь пожалуйста своим опытом кто с подобными задачами сталкивался и как решал?
Пользователь будет и читать и писАть в базу. База будет использоваться пользователем целиком и полностью поэтому ничего жирного в попытке обеспечения бесперебойной работы для пользователя не вижу.
Я не говорил что у меня проблемы с переделыванием приложения в многопользовательское. Я как раз пытаюсь выбрать оптимальное решение что-бы не потратить зря время сейчас и не жалеть об этом потом.
Потому и спрашиваю, возможно был у кого-то опыт и выскажется относительно 1 пользователь = 1 база.
Александр: Пря сейчас вы подрезали функционал сервиса и довольно серьезно. Когда у одного пользователя несколько инстансев (магазинов?) не редкая. И ему было бы удобно посмотреть сводную информацию.
Sanes: Да бог с ним, это решаемо в рамках 1000-10000 баз. Да, надо будет посидеть и подумать, как составить такой запрос. Да, он будет медленный шо пипец, но сводную информацию можно закэшировать после запроса или делать её по расписанию. По факту, нет и 100 пользователей, о чем я написал ниже. Функционал и масштабируемость - дело решаемое когда сервис работает. А делать сейчас - время тратить в пустую.
Идите по пути наименьшего сопротивления. Сначала используйте отдельную базу для каждого пользователя. А когда будут те самые 10000, тогда и будете думать о оптимизации. Я не силен в базе, даже сказал бы слаб. Но что-то мне кажется, что когда баз станет 1000 - уже будет подтормаживать. Ведь выбрать базу из 1000/10000 - не запись из одной таблицы. <- лишь мысли в слух.
Да и не вижу какой-то проблемы во время оптимизации и переноса. 10000 баз слить скриптом в одну при оптимизации - вопрос минуты.
Александр: Вы сейчас придумываете находу возможные варианты будущего, не имея базу пользователей даже и из 100 человек. И не говорите о том, сколько в базе таблиц/тип таблиц и какого они размера. Одно дело когда разговор о таблицах по 35млн и другое по 1000.
Если у вас список таблиц из 1000 штук и вы при подключении открываете одну базу, то Mysql как минимум должен найти её в этом списке. Я предполагаю, что индексов на базы данные просто тупо нету. И при большом количестве, большая часть времени выгрузки данных будет уходить не на запросы поиска в таблицах, а поиск самой базы в длинном списке.
Александр: Не надо утрировать. Все что вы пишите бред. Речь идет не о масштабировании базы с с таблицами где прибавка по 100к в час идет с плюсом каждый день, а о прибавках пользователей. Вы много сервисов знаете, где хотя бы по 10000 пользователей в день прилетает?
Зато миллионы сервисов не открыты, потому что при создании потратили деньги и время на преждевременную оптимизацию...
Так сходу лично мне ближе вариант "один пользователь - одна база".
Как минимум это не вызовет вопросом "почему у меня ID заказа/товара увеличивается не на 1 а произвольно".
Вариант "однако одна база на всех пользователей" может вызвать вопросы с масштабированием в будущем.
Есть компромиссный вариант - одна база на N пользователей - решает вопрос с количеством БД и масштабированием.
Ссылки по теме: https://habrahabr.ru/post/110979/ https://habrahabr.ru/company/microsoft/blog/145027/ SaaS: одна БД на клиента, или общая база данных?
Средний
