Латера Софтвер corporate blog
Comments 4
+3
Какой то непонятный подход. Одна и та же таблица выступает как хранилище и транзакционная таблица.

А надо просто иметь 2 таблицы. Одна, маленькая, для авторизации с актульными последними данными и архивная.
+2
Думаю, тут надо оптимизировать логическую структуру базы данных (в смысле правильного выбора чисто сущностных понятий), эффективно её администрировать (строить индексы, статистику и т.д.) и писать эффективные запросы. При том, что сессии абонентов в реальном времени только добавляются, любой человек, хранящий в базе данных телеметрию, скажет вам, что 36 млн строк – это ни о чём.
0
1) Выбор MongoDB был сделан в 2010 году, когда выбор NoSQL-решений был ограничен. С тех пор желания поменять ее не возникало: работает быстро, взаимодействовать удобно. У нее есть проблемы с надежностью — несколько раз за несколько лет эксплуатации на сотне клиентов боевая БД повреждалась или внезапно разрушалась. Но поскольку первичные данные в Mongo не хранятся, то ее БД можно быстро пересоздать с нуля из основной базы.

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

3) 36 млн строк — это, конечно, немного для телеметрии или мониторинга. Но с нашей таблицей сессий есть отличия — сессии не только добавляются, но и обновляются в течение своего срока жизни, а этот срок может достигать, например, месяца. И выборки/индексы/гистограммы бесконечно оптимизировать невозможно, нужны были архитектурные решения. Поэтому по итогам разбора полетов мы таки сделали автоматическую архивацию, чтобы не было человеческого фактора, а позже вообще убрали авторизационные запросы к таблице сессий, переделав механизмы работы с кэшем.
Only those users with full accounts are able to leave comments., please.