@Kirill-Gorelov
С ума с IT

Почему не используют NoSql решения на каждого пользователя?

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

К примеру у нас есть сервис электронной почты или к примеру чат. Как все делают когда не умещаются данные на одном сервере? Применяют горизонтальное масштабирование.

Что если запросов очень много? Добавляют балансировщик.

А что если данных в БД полно? Делают репликацию. И вот тут вопрос.

Почему для эл.почты или для чата не поднимать мини БД типа SqlLite на КАЖДОГО пользователя? Ведь это избавит от репликации, как мне кажется. И в перспективе может даже избавить от кеша, ведь мы читаем из одной БД, а там данных на одного пользователя не больше миллиона значений. Сужу по своим наблюдениям.

Единственный недостаток, как мне кажется это - скорость чтений. Т.к. SqlLite далеко не самая быстрая БД. Так же можно добавить отсутствие некоторых типов данных.

Конечно же такое решение не подойдет для всех сервисов, но к примеру в почте, это вполне приемлимо, как мне кажется.
  • Вопрос задан
  • 305 просмотров
Решения вопроса 4
Sanasol
@Sanasol
нельзя просто так взять и загуглить ошибку
Ежемесячно почтой пользуются более 27 миллионов пользователей.

вот яндекс например (это только те кто пользуется, а сколько зарегистрировано за 20 лет неизвестно)

А теперь представьте: придумали новую функцию и надо накатить миграцию в базе данных.
Добавить столбец или создать таблицу там какую-нибудь очень нужную.
Это надо 27 миллионов раз накатить миграцию.
Очень эффективно получится? Деплоить по одному апдейту в месяц или вроде того)

А если в принципе надо переехать куда-нибудь и перенести данные, тоже собирать в кучу как-то 27 миллионов разных баз. Или даже сделать бекап например.

Про всякие аналитики, статистики и т.п. можно вообще не думать, неизвестно как можно будет подключиться к такому количеству баз чтобы сделать какую-то общую статистику.

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

а там данных на одного пользователя не больше миллиона значений

от балды цифра, а если у меня 2 миллиона? А если 3? Каждый раз всё переделывать когда появляется пользователь который выходит на ваши рамки?
А когда один пользователь перестанет влезать на один сервер?
А что если 10 пользователей занимают диск целого сервака, а нагрузки при этом никакой не создают - сервер простаивать будет просто так?

Ну в общем можно много чего еще такого придумать.
Это не поддерживаемо, не масштабируемо, неудобно ни с какой стороны.
Если бы было по другому так бы все делали.
Ответ написан
@mayton2019
Bigdata Engineer
Я думаю что твоя идея не лишена смысла. Можно на каждого пользователя поднимать экземпляр БД.
Что здесь хорошо изоляция и безопасность. Что здесь плохо обилие linux-процессов на каждого пользователя. Например если у тебя чат на 10 000 человек - то поднять столько-же процессов на одном хосте сложнее. Любые операционки имеют какой-то минимальный футпринт памяти и ресурсов ОС на процесс. И переключение. Планировщик будет бегать между 10 тыщ процессов обслуживая их события. Что еще может быть плохо. Администрирование этого грида приложений. Бэкап проще делать имея 1 сущность процесса и 1 лог ошибок. А что делать с 10 тыщами логов. Отвественый девопс должен как-то просмотреть все логи? Или уже начать писать автоматизацию бэкапов. Кажется пустяк - но ты сядь и просто попробуй сам это сделать. Или мониторинг. Как проверить что все 10 тыщ не содержат в логах ошибок?

Вообще маппинг между приложениями и БД всегда идет сложным образом. Обычно m : n. И очень редко удается сделать 1:1 или как-то по другому.
Ответ написан
Sanes
@Sanes
Это имеет смысл для отчуждаемых приложений или у которых недолгий срок жизни.
Например какой-нибудь SAAS. Магазинчик или блог. По сути хостинг.
Мне попадался CRM сервис, у которого под каждого пользователя своя БД. Но админ у них был чудак и делал бекап всех БД в один файл.
Ответ написан
@Vitsliputsli
У вас здесь 2 вопроса:
1) какую СУБД использовать, это полностью зависит от данных и как к ним планируется обращаться.
2) вы прям сразу хотите запилить шардирование, это вполне возможно на любой СУБД.

В шардировании основная проблема это когда нужно получить данные из многих шардов. Сперва проблема выбрать критерий шардирования, вы вроде бы его выбрали и у вас все легко делится по пользователям. Но остается момент формирования статистики и аналитики: вам нужно будет обращаться ко всем шардам, забирать из них данные и делать map-reduce. Очевидно, что ваше ПО должно позволять параллельно формировать запросы и обрабатывать их. А вот, миграции - это не проблема, наоборот чем меньше шарды, тем проще их делать.
Разумеется, у вас должна быть отлаженная полностью автоматизированная система деплоя, которая позволит накатывать те же миграции параллельно на множество шардов. Вам нужно будет создать систему map-reduce, а здесь уже интереснее, если вы будете оперировать малым кол-вом данных, то нет проблем, в противном случае вам придется подымать отдельную аналитическую СУБД и загружать в нее данные. Таскать по сети миллионы строк между разными машинами будет не весело.
И еще момент, не обязательно создавать на каждого пользователя отдельный шард, вы можете объединять их по какой-либо формуле, тогда не обязательно заводить миллионы шардов. Либо все же сделать миллионы шардов, но располгать скажем на 1 машине 1000 шардов, и вы сможете если понадобится изменять эту цифру.

Как все делают когда не умещаются данные на одном сервере? Применяют горизонтальное масштабирование.
Что если запросов очень много? Добавляют балансировщик.
А что если данных в БД полно? Делают репликацию. И вот тут вопрос.

Нет проблем уместить много данных на одном сервере (есть, конечно, BigData но это совсем про другое), проблема в том что при увеличении кол-ва данных в БД начинается деградация производительности СУБД, и примерно к 1млрд строк она проседает очень сильно (если кончено у вас строка это не 5 integer, а скорость ответа вы считаете в миллисекундах, а не в секундах). И в этом случае мы делим данные на разные СУБД, т.е. шардируемся.
Если очень много запросов чтение, то нет проблем поставить нужное кол-во слейвов и делить нагрузку между ними, т.е. реплицировать master.

Ну и, шардирование не такая простая вещь как кажется. Не стоит прям на старте ее впиливать, а вот подготовить данные для возможного деления на шарды стоит.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
10 авг. 2022, в 03:31
7000 руб./за проект
10 авг. 2022, в 03:28
40000 руб./за проект
10 авг. 2022, в 02:55
50000 руб./за проект