Comments 4
С чем связан выбор MongoDB?
Какой то непонятный подход. Одна и та же таблица выступает как хранилище и транзакционная таблица.
А надо просто иметь 2 таблицы. Одна, маленькая, для авторизации с актульными последними данными и архивная.
А надо просто иметь 2 таблицы. Одна, маленькая, для авторизации с актульными последними данными и архивная.
Думаю, тут надо оптимизировать логическую структуру базы данных (в смысле правильного выбора чисто сущностных понятий), эффективно её администрировать (строить индексы, статистику и т.д.) и писать эффективные запросы. При том, что сессии абонентов в реальном времени только добавляются, любой человек, хранящий в базе данных телеметрию, скажет вам, что 36 млн строк – это ни о чём.
1) Выбор MongoDB был сделан в 2010 году, когда выбор NoSQL-решений был ограничен. С тех пор желания поменять ее не возникало: работает быстро, взаимодействовать удобно. У нее есть проблемы с надежностью — несколько раз за несколько лет эксплуатации на сотне клиентов боевая БД повреждалась или внезапно разрушалась. Но поскольку первичные данные в Mongo не хранятся, то ее БД можно быстро пересоздать с нуля из основной базы.
2) Совершенно верно, что таблица сессий должна состоять из двух частей — актуальной и архивной. Примерно так и было, только тогда перенос данных из актуальной таблицы в архивную не был автоматизирован (это довольно редкая операция) и запускался вручную по сигналу с мониторинга. Однажды сигнал не поступил и все пошло вразнос.
3) 36 млн строк — это, конечно, немного для телеметрии или мониторинга. Но с нашей таблицей сессий есть отличия — сессии не только добавляются, но и обновляются в течение своего срока жизни, а этот срок может достигать, например, месяца. И выборки/индексы/гистограммы бесконечно оптимизировать невозможно, нужны были архитектурные решения. Поэтому по итогам разбора полетов мы таки сделали автоматическую архивацию, чтобы не было человеческого фактора, а позже вообще убрали авторизационные запросы к таблице сессий, переделав механизмы работы с кэшем.
2) Совершенно верно, что таблица сессий должна состоять из двух частей — актуальной и архивной. Примерно так и было, только тогда перенос данных из актуальной таблицы в архивную не был автоматизирован (это довольно редкая операция) и запускался вручную по сигналу с мониторинга. Однажды сигнал не поступил и все пошло вразнос.
3) 36 млн строк — это, конечно, немного для телеметрии или мониторинга. Но с нашей таблицей сессий есть отличия — сессии не только добавляются, но и обновляются в течение своего срока жизни, а этот срок может достигать, например, месяца. И выборки/индексы/гистограммы бесконечно оптимизировать невозможно, нужны были архитектурные решения. Поэтому по итогам разбора полетов мы таки сделали автоматическую архивацию, чтобы не было человеческого фактора, а позже вообще убрали авторизационные запросы к таблице сессий, переделав механизмы работы с кэшем.
Sign up to leave a comment.
DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных