![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapov(заказной пост для ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
en_vision) Допустим, ваш оператор делает биллинг (готовит ежемесячные счета) в течении 5-10 дней? Почему так долго? Казалось бы, делов-то - "select sum(rated_amount) from rated_calls group by contract_id", и вперед - печатать счета. Давайте попробуем разобраться, где же порылась собака.
Допустим, у компании-оператора два миллиона абонентов, которым надо выставить счета. Каждый из этих абонентов за день в среднем совершает 10 тарифицируемых событий (исходящие звонки, SMS, ...) и еще столько же нетарифицируемых (входящие звонки, SMS, ...).
За месяц получаем: 2*10^6 * 20 * 30 = 12 * 10^8 (1 млрд 200 млн). Это количество записей, прошедших через rating.
Что делает процесс биллинга в простейшем случае? Для каждого из 2-х млн абонентов он смотрит, какие контракты принадлежат каждому абоненту, выбирает звонки, сделанные контрактами, суммирует их, добавляет все необходимые ежемесячные абонплаты, и начисляет сверху налоги. По окончании расчета полученные данные засовываются в красивую печатную форму (например, в виде PostScript).
Тут все желающие уже могут провести пару простых экспериментов. Например, взять любую базу данных, засунуть в нее миллиард-другой записей и попробовать выполнить select, вынесеный мной в первые строчки поста. Результаты отмасштабировать в предположении, что у оператора процессоры будут СуперМощные, а памяти будет Дофигищща.
Все? Нет, не все. Стрижка только начата. Это мы построили самый простой биллинг, практически - сферический биллинг в вакууме.
Давайте добавим в картину мира услуги, плата за которые зависит от месячной активности абонента. Например, "абонент платит за сервис фиксированную сумму в день, но только в дни, когда он пользовался этой услугой" или "сумма ежемесячной абонплаты зависит от кол-ва дней, в течении которых контракт был активен". Чтобы рассчитывать такие суммы, нам придется делать детальный анализ таблицы событий в разрезе дней. Допустим, что такие услуги популярны, и нам надо делать это для бОльшей части абонентской базы.[1]
Давайте также добавим в картину мира так популярные нынче "бесплатные" (или входящие в абонплату) минуты/SMS-ы/MMS-ы и т.п. В терминах нашей модели это означает, что для каждого контракта существует некое кол-во минут N, и определенные (не все) звонки суммарной продолжительностью не более N должны быть исключены из счета. Учтем, что, как правило, N бесплатных минут не будут исчерпаны при помощи целого числа звонков - будет какой-то звонок, который попадет "на границу" и его придется порезать на две части - платную и бесплатную. И это тоже делает биллинг.[2]
Давайте еще учтем смену тарифных моделей. Если у абонента была модель A (X_1 грн в месяц, Y_1 "бесплатных" минут) и он 20-го числа поменял ее на модель B (X_2 грн в месяц, Y_2 бесплатных минут), то с абонента надо снять X_1*(20/30) грн и дать ему Y_1*(20/30) минут в рамках модели А, а в рамках модели B снять X_2*(10/30) грн и дать ему Y_2*(10/30) минут - пропорционально времени, которое он провел в каждой тарифной модели. Да, попутно надо не забыть пересчитать все абонплаты, которые зависят от месячной активности.[3]
Как, все еще помещаемся в пару часов? Сомневаюсь.
Погодите, но кроме счетов для абонента есть еще бухгалтерия. Надо показать, какие звонки абонента "закрывают" те или иные его платежи. Другими словами, если абонент заплатил два раза по 100 грн, а наговорил на 200 грн, то биллинг должен для каждого звонка указать, к какому платежу он "отнесен" - к первому или второму. И так для всех звонков всех абонентов.[4]
Теперь посчитаем налоги и все цифры для налоговых накладных (это, правда, можно делать только для абонентов-юрлиц).
В принципе, дальше уже можно не продолжать, думаю, что и так все должно быть понятно. Если кто-то сможет втиснуть это все в рамки нескольких часов - ему прямая дорога писать и продавать биллинговые системы. Можно миллионы будет на этом деле заработать.
На реплики "так это ж можно распараллелить на 100 серверов!" я, наверное, реагировать не буду, уж извините :)
PS
Предваряя отдельный рассказ про Intelligent Network, NextGenerationOSS, конвергентные, hot, almost-hot и другие "быстрые" решения, хочу закинуть такую "удочку": в системе, которая Сразу после события подбивает достоверный и окончательный баланс абонента, и абонент не может уйти в минус, невозможна нормальная реализация услуг, описаных в пунктах [1],[2],[3],[4].
А реализовывать такие услуги отделу маркетинга хочется. Вот и получается, что либо модные услуги, контракт и длинный биллинг, либо без модных услуг, препейд и невозможность биллинга, как такового.
UPD: тем не менее, многие все-таки решили написать мне о том, как прекрасно параллелится биллинг и, в частности, как прекрасно разделяется для этого на части база данных. Коллеги! Я сам придерживаюсь мнения, что среди биллингописателей множество идиотов. Множество - но не все. Подумайте о том, почему такое, казалось бы, тривиальное решение не было реализовано на практике кем-то из major players. А еще подумайте о том, что биллинг - он раз в месяц, а все остальные 27 дней с этой базой и этой таблицей тоже что-то происходит. Причем очень активно происходит, практически без перерыва. И разделение базы на части для этих процессов .... ээээ ... ну, скажем, не самое лучшее решение.
en_vision) Допустим, ваш оператор делает биллинг (готовит ежемесячные счета) в течении 5-10 дней? Почему так долго? Казалось бы, делов-то - "select sum(rated_amount) from rated_calls group by contract_id", и вперед - печатать счета. Давайте попробуем разобраться, где же порылась собака. Допустим, у компании-оператора два миллиона абонентов, которым надо выставить счета. Каждый из этих абонентов за день в среднем совершает 10 тарифицируемых событий (исходящие звонки, SMS, ...) и еще столько же нетарифицируемых (входящие звонки, SMS, ...).
За месяц получаем: 2*10^6 * 20 * 30 = 12 * 10^8 (1 млрд 200 млн). Это количество записей, прошедших через rating.
Что делает процесс биллинга в простейшем случае? Для каждого из 2-х млн абонентов он смотрит, какие контракты принадлежат каждому абоненту, выбирает звонки, сделанные контрактами, суммирует их, добавляет все необходимые ежемесячные абонплаты, и начисляет сверху налоги. По окончании расчета полученные данные засовываются в красивую печатную форму (например, в виде PostScript).
Тут все желающие уже могут провести пару простых экспериментов. Например, взять любую базу данных, засунуть в нее миллиард-другой записей и попробовать выполнить select, вынесеный мной в первые строчки поста. Результаты отмасштабировать в предположении, что у оператора процессоры будут СуперМощные, а памяти будет Дофигищща.
Все? Нет, не все. Стрижка только начата. Это мы построили самый простой биллинг, практически - сферический биллинг в вакууме.
Давайте добавим в картину мира услуги, плата за которые зависит от месячной активности абонента. Например, "абонент платит за сервис фиксированную сумму в день, но только в дни, когда он пользовался этой услугой" или "сумма ежемесячной абонплаты зависит от кол-ва дней, в течении которых контракт был активен". Чтобы рассчитывать такие суммы, нам придется делать детальный анализ таблицы событий в разрезе дней. Допустим, что такие услуги популярны, и нам надо делать это для бОльшей части абонентской базы.[1]
Давайте также добавим в картину мира так популярные нынче "бесплатные" (или входящие в абонплату) минуты/SMS-ы/MMS-ы и т.п. В терминах нашей модели это означает, что для каждого контракта существует некое кол-во минут N, и определенные (не все) звонки суммарной продолжительностью не более N должны быть исключены из счета. Учтем, что, как правило, N бесплатных минут не будут исчерпаны при помощи целого числа звонков - будет какой-то звонок, который попадет "на границу" и его придется порезать на две части - платную и бесплатную. И это тоже делает биллинг.[2]
Давайте еще учтем смену тарифных моделей. Если у абонента была модель A (X_1 грн в месяц, Y_1 "бесплатных" минут) и он 20-го числа поменял ее на модель B (X_2 грн в месяц, Y_2 бесплатных минут), то с абонента надо снять X_1*(20/30) грн и дать ему Y_1*(20/30) минут в рамках модели А, а в рамках модели B снять X_2*(10/30) грн и дать ему Y_2*(10/30) минут - пропорционально времени, которое он провел в каждой тарифной модели. Да, попутно надо не забыть пересчитать все абонплаты, которые зависят от месячной активности.[3]
Как, все еще помещаемся в пару часов? Сомневаюсь.
Погодите, но кроме счетов для абонента есть еще бухгалтерия. Надо показать, какие звонки абонента "закрывают" те или иные его платежи. Другими словами, если абонент заплатил два раза по 100 грн, а наговорил на 200 грн, то биллинг должен для каждого звонка указать, к какому платежу он "отнесен" - к первому или второму. И так для всех звонков всех абонентов.[4]
Теперь посчитаем налоги и все цифры для налоговых накладных (это, правда, можно делать только для абонентов-юрлиц).
В принципе, дальше уже можно не продолжать, думаю, что и так все должно быть понятно. Если кто-то сможет втиснуть это все в рамки нескольких часов - ему прямая дорога писать и продавать биллинговые системы. Можно миллионы будет на этом деле заработать.
На реплики "так это ж можно распараллелить на 100 серверов!" я, наверное, реагировать не буду, уж извините :)
PS
Предваряя отдельный рассказ про Intelligent Network, NextGenerationOSS, конвергентные, hot, almost-hot и другие "быстрые" решения, хочу закинуть такую "удочку": в системе, которая Сразу после события подбивает достоверный и окончательный баланс абонента, и абонент не может уйти в минус, невозможна нормальная реализация услуг, описаных в пунктах [1],[2],[3],[4].
А реализовывать такие услуги отделу маркетинга хочется. Вот и получается, что либо модные услуги, контракт и длинный биллинг, либо без модных услуг, препейд и невозможность биллинга, как такового.
UPD: тем не менее, многие все-таки решили написать мне о том, как прекрасно параллелится биллинг и, в частности, как прекрасно разделяется для этого на части база данных. Коллеги! Я сам придерживаюсь мнения, что среди биллингописателей множество идиотов. Множество - но не все. Подумайте о том, почему такое, казалось бы, тривиальное решение не было реализовано на практике кем-то из major players. А еще подумайте о том, что биллинг - он раз в месяц, а все остальные 27 дней с этой базой и этой таблицей тоже что-то происходит. Причем очень активно происходит, практически без перерыва. И разделение базы на части для этих процессов .... ээээ ... ну, скажем, не самое лучшее решение.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-11-20 02:57 pm (UTC)Так что (as for me), ключевой фактор в объяснении "отделу маркетинга .." непрерывно ".. хочется" - и невозможность заводить под каждый чих оптимизационные фишки. :)
(no subject)
Date: 2006-11-20 03:09 pm (UTC)1)Ну, допустим мы распараллелили подсчет - что мы будем делать с базой?
2)Допустим, мы распараллелили базу (Oracle partitioning? или как? порежем базу на куски?). Что у нас получается с процессами, которые наполняют/модифицируют эту базу в течении месяца? :)
Доводим эту мысль до экстрима - каждый абонент в одтельной базе на отдельном компе :) Ведь нужна же будет центральная сущность, которая помнит, на каком компе хранится какой абонент, nest pas? :) И ведь этой сущности прийдется роутить через себя все запросы. И ведь такая организация хранения данных похерит производительность запросов вида "select sum(...) from all_contracts" ...
(no subject)
Date: 2006-11-20 03:21 pm (UTC)Так же пилить, а че с ней еще делать : )
> Ведь нужна же будет центральная сущность, которая помнит, на каком компе хранится какой абонент, nest pas?
Не совсем. Как уже замечалось, расчет абонентов (групп абонентов) слабо коррелирует друг с другом. Централизованая сущность нужна для создания суммарных отчетов управленческого и финансового учета, технического (например, оценка трафика) анализа и т.п. Т.е. для внутренних операций, которые более-менее прогнозируемы. Маршрутизация от id абонента - суть слабозатратная операция по сравнению с выгодой параллелизации. В случае же обобщающих запросов можно производить промежуточную агрегацию по нодам кластера со сведением в некой единой точке (некий служебный сервер баз данных для внутреннего пользования). Подозреваю, что в том же Оракле есть подобные решения, если нет - хороший повод их туда добавить... : )
(no subject)
Date: 2006-11-20 10:09 pm (UTC)Напоминаю - на собственно биллинге свет клином не сошелся. Процесс билинга - раз в месяц. Что будем делать с базой потом - склеивать обратно? А перед биллингом - опять пилить? Или как?
(Рассказ о том, как ускоряется биллинг в вакууме - скипнут)
(no subject)
Date: 2006-11-21 09:55 am (UTC)Слеивать, разумеется, надо не базу, а результаты распределенного по кластеру запроса. Вполне реализуемо.
(no subject)
Date: 2006-11-22 07:47 am (UTC)(no subject)
Date: 2006-11-22 07:50 am (UTC)(no subject)
Date: 2006-11-20 03:24 pm (UTC)И ведь этой сущности прийдется роутить через себя все запросы.
Это не проблема, imho: если у вас 10 млн абонентов и 256 машин, то на простой табличный mapping ID абонента -> # машины уйдёт 10 мегабайт памяти.
И ведь такая организация хранения данных похерит производительность запросов вида "select sum(...) from all_contracts" ...
Если результаты выбираются аддитивно, то map@reduce вполне работает - запрос раздаётся всем машинам, потом результат аггрегируется обратно.
(no subject)
Date: 2006-11-20 10:15 pm (UTC)Я (наивно?) верю, что биллинг, построенный на BigTable (или как там называется творение гугла?) может бить рекорды скорости. Все равно надо строить и мерять, а то на пальцах сложно понять, что веселее - map/reduce или index range scan.
Но - пускай. Пусть он будет супер-быстр. Только вот жить этому биллингу первое время прийдется в вакууме, т.к. все-все-все прочие системы привыкли, что к биллингу можно ходить с помощью SQL, как правило - по OCI. И это - та причина, по которой биллинга на БигТейбл не будет еще очень долго.
(no subject)
Date: 2006-11-20 10:55 pm (UTC)>И это - та причина, по которой биллинга на БигТейбл не будет еще очень долго
(посмотрел по веткам) Не очень хорошо логика аргументации у Вас построена: Вы начали с "у нас такие задачи что ужас-ужас и никому их не решить", а съехали на классификацию чужих идей "конями в абсолютном вакууме". Тогда так и пишите: работаем с Ж., через Ж., латать приходится на ходу, на серьёзные переструктуровки времени/ресурсов нет/нет_смысла/не_дадут - посему абоненты - ешьте что даём, извините уж. :)В общем понятно, не надо было мне лезть в рассуждения о распараллеливании - у всех свои задачи (специализированные) и ресурсы (ограниченные). На этом предлагаю закончить.
(no subject)
Date: 2006-11-20 11:14 pm (UTC)По моему локальному опыту, это будет нормально работать только в случае Oracle (stand-by copy), и в оракле оно работает с 9-ой версии - т.е. сравнительно недавно (в масштабах существования телекома вообще). Т.е. куча не древних вобщем-то систем работает на восьмерке и этого удовольствия лишена.
Теперь про агрументацию. Я по-прежнему настаиваю, что задачи ужас-ужас какие. Но не в том смысле, что каждая отдельная - ужас-ужас какая, вовсе нет. По отдельности они выглядят manageable и где-то даже белыми и пушистыми.
Вот необходимость решать кучу подобных задач параллельно/синхронно с приемлимым качеством - вот это уже ужас-ужас.
Именно поэтому я говорю, что выдернуть из этого "веника" один прутик под названием "биллинг" и соптимзировать его вусмерть - дело реальное и возможно даже нехитрое. Но вот результат потом обратно в "веник" as is не засунешь. И "веник" весь целиком не оптимизируешь так, чтобы все стало быстрее на порядок. Примерно таким же образом нельзя ускорить до невиданных пределов _всю_ работу с базой, построив в ней индексы по всем полям и всем их комбинациям - выборки ускорятся (и то не всегда/не все), вставки и удаления "просядут".
В результате и получается: работаем с кучей компромиссов, постоянно идя на компромиссы, латать действительно приходится на ходу, ... ну и все такое прочее, прямо по тексту.
Вот. Надеюсь, что мои аргументы стали понятнее. Если фраза про коня задела - извини, не хотел.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:опечатался
Date: 2006-11-20 03:26 pm (UTC)(no subject)
Date: 2006-11-20 03:35 pm (UTC)(no subject)
Date: 2006-11-20 10:16 pm (UTC)(no subject)
Date: 2006-11-20 04:18 pm (UTC)(no subject)
Date: 2006-11-20 10:19 pm (UTC)Далее, я могу сходу назвать с пяток _разных_ идентификаторов абонета. Биллинг пользуется одним, базовая сеть - другими, всякий CRM - третьими. Где-то на стыке систем эти идентификаторы сопоставляются-преобразовываются.
По какому из них будем делить и где-как будем хранить индексы, позволяющие легко транслировать одни ID в другие?
(no subject)
Date: 2006-11-20 11:15 pm (UTC)По множественные id - мы же о биллинге? "Биллинг пользуется одним". :)
Преобразуются они - аппаратные в биллинговые - на входе, видимо - сразу после разбора и нормализации свалившихся из "хардвера" файлов. Индексы хранятся в БД, очевидно. :) И, собственно, наличие этой фазы никак не связано с партиционированием или другим решением проблемы масштабирования.
В любом случае в рамках биллинга мы работаем в терминах одной системы идентификации абонента. Кстати - на самом деле, реально один б-м известный мне волею случая биллинг ОПСОСА рубит не по идентификатору абонента, а по другому, более "крупному" идентификатору, но это детали.
В общем - так делают, вполне успешно и не так уж редко. Бесспорно, свои неприятности есть и тут, но - где их нет...
(no subject)
Date: 2006-11-22 01:41 pm (UTC)Точно никак не связано? А если нам надо найти запись не по тому ID, по которому мы порезали базу на partition-ы? Кто быстро нам расскажет, в какой из кусков базы лезть за соответствующими записями?
(впрочем, мне кажется, что дальше начинается спор о вкусах и гадания на кофейной гуще)
В там же стиле я могу сказать, что волею случая с десяток виденных мною биллингов не имели распределенной базы. Три из них (Oracle-based) имели явно прописанные рекомендации против использования partitioning.
:)
(no subject)
From:(no subject)
From:(no subject)
Date: 2006-11-20 04:28 pm (UTC)(no subject)
Date: 2006-11-20 10:19 pm (UTC)Про курицу-яйцо я уже вроде вспомнил, а сертификация - это да, это сильный аргумент.
(no subject)
Date: 2006-11-20 06:21 pm (UTC)А вот в наших пенатах по-моему все, что ни попадя сперва делают на оракле ...
(no subject)
Date: 2006-11-20 10:20 pm (UTC)Версии к третьей-четвертой - глядишь, уже можно жить :)
(no subject)
Date: 2006-11-21 07:39 am (UTC)(no subject)
Date: 2006-11-22 07:32 am (UTC)(no subject)
Date: 2006-11-21 07:42 am (UTC)(no subject)
From: