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

Question

[Кирилл Горелов]

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

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

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

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

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

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

Конечно же такое решение не подойдет для всех сервисов, но к примеру в почте, это вполне приемлимо, как мне кажется.

Comments

[shurshur]

Причём тут упоминание NoSQL применительно к реляционной sqlite?

Иногда делают очень специфические решения для необычных задач. Например, Internet Archive хранит данные в виде архивов на диске - никакой базы.

Или вот если вспомнить почту, то dovecot хранит каждый ящик отдельно от других. Ещё бывают почтовики, у которых mailbox (все письма одним файлом длинной портянкой) или maildir (письма отдельными файлами с timestamp в имени).

Но в целом это неудобно для больших масштабируемых решений.

Answer 1

[Александр Аксентьев]

Ежемесячно почтой пользуются более 27 миллионов пользователей.

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

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

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

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

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

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

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

Ну в общем можно много чего еще такого придумать.
Это не поддерживаемо, не масштабируемо, неудобно ни с какой стороны.
Если бы было по другому так бы все делали.

Comments

[Кирилл Горелов]

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

[Александр Аксентьев]

Кирилл Горелов, я где-то один раз сталкивался в Saas системе с таким подходом.
Но там еще и сам код клонировался для каждого.

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

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

Такой подход x10 затрат на поддержку, даже мелочи превращаются в ад)

[Vitsliputsli]

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

Answer 2

[mayton2019]

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

Вообще маппинг между приложениями и БД всегда идет сложным образом. Обычно m : n. И очень редко удается сделать 1:1 или как-то по другому.

Comments

[Виктор П.]

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

[mayton2019]

Виктор П., это решает только проблему агрегации логов. Объем ошибок к анализу остается по прежнему большим.

Answer 3

[Sanes]

Это имеет смысл для отчуждаемых приложений или у которых недолгий срок жизни.
Например какой-нибудь SAAS. Магазинчик или блог. По сути хостинг.
Мне попадался CRM сервис, у которого под каждого пользователя своя БД. Но админ у них был чудак и делал бекап всех БД в один файл.

Comments

[mayton2019]

Мне кажется чтобы рассмотреть идею с разных сторон - надо просто пойти ad absurdum. Тоесть пускай вообще всё будет так как хочет автор. Для каждого пользователя своя база и свой Апач и свой домен и так далее. Может тут Kubernetes будет полезен. И как раз бесконечный параллелизм ведь у нас ничего не связано и можно резать этот грид как колбасу по хостам. И далее - посмотреть к чему это всё приводит.

Answer 4

[Vitsliputsli]

У вас здесь 2 вопроса:
1) какую СУБД использовать, это полностью зависит от данных и как к ним планируется обращаться.
2) вы прям сразу хотите запилить шардирование, это вполне возможно на любой СУБД.

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

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

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

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