Похоже тут дело вкуса. В любом случае имена явно записываются в начале класса. Если в дело не вступает наследование, и если файл не слишком большой, то вроде бы не должно быть проблем.
Повторная заливка данных не приводит к отказам в обслуживании уже работающих абонентов, а лишь добавляет задержку для активации существующих. Просто первого числа люди не хотят ждать, когда их включит и звонят с требованием включить услугу, что понятно. Сделать выгрузку из биллинга, скажу честно, суперпросто, потому что данные там хранятся в том виде, в котором они должны оказаться в базе радиуса. Но делать это в момент факапа довольно рискованное занятие. Сам инцидент продлился несколько часов, в течение которых были задержки во включении оплативших абонентов, в остальном все работало, поэтому подвергать риску работающих абонентов все же не стоило. Конечно, если бы сценарий был отработан заранее, то… но здесь мы уже ходим по кругу.
Вряд ли. ActiveMQ выбрана не по причине какой-то особенной любви к ней, а потому что она из коробки работает с ораклом. И производительность ее как брокера гораздо выше, чем у оркала, то есть она не является узким местом. Вопрос подтверждения сообщений — это вопрос используемого протокола, в данном случае это был STOMP. Он, прямо скажем, примитивен, но работает. Даже потеря сообщений не такая большая проблема — всегда можно отправить все их заново, на это всегда был расчет, как на крайний случай, но беда, как уже было сказано, не приходит одна.
О том и речь. В оракле есть инкрементальный рефреш по коммиту, но то в оракле. И там есть серьезные ограничения на возможность именно инкрементального обновления.
Боюсь, мы не сможем тут вас удивить. В статье действительно хорошо изложена суть подхода, поэтому мы ее и выбрали. Ее удобно, например, кидать новичкам. В остальном, как мне кажется, тонкостям можно научиться только на своем опыте.
В постгресе сейчас нет инкрементального обновления мат. представлений, недавно только завезли конкурентное.
В статье прямо говорится, что инструмент требует взвешенного подхода. Например, у нас денормализация работает вопреки вашим предостережениям.
Переходить можно с чего угодно, на что угодно. Не нужно быть адептом технологий, нужно знать инструменты. Но в вашей идее есть доля правды: разработчики на RoR зачастую оказываются в ловушке фреймворка, поэтому выход за пределы им «наносит» большую пользу.
Ну все перерасчеты и прочее — больше организационный вопрос. А что касается скорости, то это секунды после восстановления связи, там очереди сообщений.
Там все хитро. AAA-сервер может пустить абонента по старым данным. Как только соединение с основной БД восстановится, то в момент загрузки сессий будет сгенерирована команда на терминацию запрещенной сессии. Даже если сессия по какой-то причине загрузилась из-за гонки, то периодическое задание прибьет ее.
Посмотрите на стрелочки между ядром и БД харда, у них там двусторонний обмен. Если очередь отвалится, то ничего страшного, как поднимут, так и хорошо, ее просто нужно мониторить. Своего состояния у нее не много, в любой момент можно отправить данные заново, даже если она все потеряет.
Общались, знаем. Но смотрите в чем проблема. Вы долго и упорно вкладывали в разработку решения, которое вас полностью устраивает. Но со временем к продукту начинают предъявляться новые требования, а команды к тому времени может уже и не быть. Либо все это выходит не так уж дешево. И вот вы думаете о том, чтобы перейти на коробочное решение, но уже поздно. Ваша система настолько хорошо написана и так хорошо отрабатывает ваши бизнес-процессы, что ни одно коробочное решение вас не устраивает. И простого выхода нету, это реально тупик. Либо вам придется всерьез занимать непрофильным направлением, либо ломать все/почти все бизнес процессы.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
У нас же за МКАДом жизнь не заканчивается. Зачастую история была такова, что в глубинке нашелся программист-самородок, которого взяли на работу, он написал (предположительно) отличное решение, которое решило задачи на тот момент, а потом началось всякое-разное с байками про паяльник.
В статье прямо говорится, что инструмент требует взвешенного подхода. Например, у нас денормализация работает вопреки вашим предостережениям.
У нас же за МКАДом жизнь не заканчивается. Зачастую история была такова, что в глубинке нашелся программист-самородок, которого взяли на работу, он написал (предположительно) отличное решение, которое решило задачи на тот момент, а потом началось всякое-разное с байками про паяльник.