1) Выбор MongoDB был сделан в 2010 году, когда выбор NoSQL-решений был ограничен. С тех пор желания поменять ее не возникало: работает быстро, взаимодействовать удобно. У нее есть проблемы с надежностью — несколько раз за несколько лет эксплуатации на сотне клиентов боевая БД повреждалась или внезапно разрушалась. Но поскольку первичные данные в Mongo не хранятся, то ее БД можно быстро пересоздать с нуля из основной базы.
2) Совершенно верно, что таблица сессий должна состоять из двух частей — актуальной и архивной. Примерно так и было, только тогда перенос данных из актуальной таблицы в архивную не был автоматизирован (это довольно редкая операция) и запускался вручную по сигналу с мониторинга. Однажды сигнал не поступил и все пошло вразнос.
3) 36 млн строк — это, конечно, немного для телеметрии или мониторинга. Но с нашей таблицей сессий есть отличия — сессии не только добавляются, но и обновляются в течение своего срока жизни, а этот срок может достигать, например, месяца. И выборки/индексы/гистограммы бесконечно оптимизировать невозможно, нужны были архитектурные решения. Поэтому по итогам разбора полетов мы таки сделали автоматическую архивацию, чтобы не было человеческого фактора, а позже вообще убрали авторизационные запросы к таблице сессий, переделав механизмы работы с кэшем.
Большие суммы по взаиморасчетам между брокерами не возят в чемоданах через границу. Их гоняют между юрлицами по безналу, подмешивая их в реальные денежные потоки.
А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )
Битые реду-логи оракл не применяет. Мониторим отставание текущего номера SCN на резервной базе от SCN основной. Если оно становится слишком большим — выдаем алерт, принимаем меры.
В hard содержится вся бизнес-логика аутентификации, авторизации и аккаунтинга. Плюс он взаимодействует с БД профилей и данных по аккаунтингу. FreeRADIUS в этой схеме используется в «тупом» варианте, фактически для того, чтобы декодировать бинарный протокол RADIUS в текстовый формат и наоборот.
Модуль FR делать не стали, потому что нужно было программировать на C, а делать это очень не хотелось. Использовали rlm_perl.
Практически все крупные как раз сидят на серийных биллингах. Почему? Потому что а) умеют считать деньги, б) умеют считать время, в) у них нет запросов на экзотические фичи, потому что им нужно тупо зарабатывать деньги акционерам, а не устраивать шапито.
Сейчас развитие как раз идет в сторону коробочных продуктов. Ну, насколько понятие «коробка» вообще для энтерпрайза применимо. Скорее это фреймворки-конструкторы, которые изначально содержат возможности для кастомизации.
Что касается конкретно биллинговых систем, то все «допиливание» даже простеньких биллингов обычно заключается в разработке фич, которые там либо не предусмотрены изначально (те же возможности CRM или планирование выездных работ) и должны делаться отдельной специализированной системой, либо в использовании базовых возможностей биллинга, например, для построения более сложного тарифного плана.
Самый главный момент — разработчики сейчас стали слишком дорогими. Содержать их ради своего уникального продукта экономически невыгодно. А разработать с нуля свое решение займет минимум год. За это время та крайне нужная фича, ради которой все затевалось, может стать уже неактуальной.
2) Совершенно верно, что таблица сессий должна состоять из двух частей — актуальной и архивной. Примерно так и было, только тогда перенос данных из актуальной таблицы в архивную не был автоматизирован (это довольно редкая операция) и запускался вручную по сигналу с мониторинга. Однажды сигнал не поступил и все пошло вразнос.
3) 36 млн строк — это, конечно, немного для телеметрии или мониторинга. Но с нашей таблицей сессий есть отличия — сессии не только добавляются, но и обновляются в течение своего срока жизни, а этот срок может достигать, например, месяца. И выборки/индексы/гистограммы бесконечно оптимизировать невозможно, нужны были архитектурные решения. Поэтому по итогам разбора полетов мы таки сделали автоматическую архивацию, чтобы не было человеческого фактора, а позже вообще убрали авторизационные запросы к таблице сессий, переделав механизмы работы с кэшем.
RAC более требователен к железу. Нужна хорошая корзина с резервированием.
RAC дороже в администрировании.
Поэтому RAC нужно использовать только там, где без него не обойтись никак. Для всего остального есть мастеркард, то есть копирование redo-логов.
Битые реду-логи оракл не применяет. Мониторим отставание текущего номера SCN на резервной базе от SCN основной. Если оно становится слишком большим — выдаем алерт, принимаем меры.
Очереди для AAA используются внешние, ActiveMQ. Очереди AQ применяются внутри ядра, но об этом, опять же, в другой раз.
AAA использует собственную БД на MongoDB, в нее реплицируются данные из провиженинга. В момент инициализации сессии обращение в ядро не происходит.
Задавайте вопросы про отказоустойчивость :).
Модуль FR делать не стали, потому что нужно было программировать на C, а делать это очень не хотелось. Использовали rlm_perl.
Что касается конкретно биллинговых систем, то все «допиливание» даже простеньких биллингов обычно заключается в разработке фич, которые там либо не предусмотрены изначально (те же возможности CRM или планирование выездных работ) и должны делаться отдельной специализированной системой, либо в использовании базовых возможностей биллинга, например, для построения более сложного тарифного плана.
Самый главный момент — разработчики сейчас стали слишком дорогими. Содержать их ради своего уникального продукта экономически невыгодно. А разработать с нуля свое решение займет минимум год. За это время та крайне нужная фича, ради которой все затевалось, может стать уже неактуальной.