Мне тут один молодой товарищ объяснял, что повторно кипятить воду вредно,
мол тяжелая вода там появляется…
Блин, поколение пепси, что-то где-то поверхностно прочитал, или скорее увидел,
и во всё верят.
Моск не хочет подумать — а сколько времени надо воду эту грешную кипятить,
чтобы там что-то вредно-тяжелое появилось…
Была бы вода из крана — там соли, хлорка,… еще можно понять, но когда говорят,
про воду из «поилки», где она практически дистиллированная, да еще и в контексте тяжелой воды…
Но это так, к слову… — мне понравились ваши критерии эффективного манагера.
да при чем тут бум PC?
Они делали лучшее, легендарное серверное железо, лучшие операционки для СЕРВЕРОВ,
и рынок этот никуда не уходил и сейчас не уходит.
Если не ошибаюсь, IBM сама скинула с себя PC часть.
Подскажите, вот была такая известная фирма как
Digital Equipment Corporation, выпускавшая Компьютеры VAX c OpenVMS, Alpha серверы с DEC Alpha c Digital Unix на отличном ядре, легендарную серию мини-ЭВМ PDP… включая PDP11.
Выпускающая кучу софта, включая банковскую систему…
Она от чего загнулась?
Тоже манагеры эффективные доконали?
Ведь казалось, что серьезнее фирмы Digital просто нет, или почти нет, — а вот…
Хорошо написано, но кто не в теме, тому может показаться, что многозадачность как-то связана с прерываниями… В то время как аппаратные прерывания призваны обрабатывать прерывания от оборудования, чтобы не опрашивать «железо» постоянно, оборудование само вызывает прерывание…
Мало отзывов, видимо новое поколение не изучает глубоко железо.
Сразу, наверное жава-быдлокодить учат.
Главная ошибка начинающих — это, что они забывают, что в английском существует
строгий порядок членов в предложении.
Наличие только одного падежа(двух) привело к таким ограничениям.
Нельзя использовать кальку с русского, в котором слова можно мешать в предложении
как угодно.
Понял я, что…
Я понял, что…
Мне хотелось… — I should…
Ему надо… — He…
Это кто сделал?
Кто это сделал?
Нет родовых окончаний и почти никаких тебе уменьшительно-ласкательных :).
В общем там никакой свободы и слава богу, язык учить проще.
--Билайн переходит. Пока не Биллинг. Но это только начало.
Еще раз, сейчас у них биллинг Amdocs, переходят они на Эриксон.
Ни в одну из этих систем другую базу не дадут втыкать.
Какую-то вспомогательную обработку(как-то личный кабинет — это не биллинг) могут повесить на что угодно.
Ну и отлично. IMDB это хорошо, даже в составе Биллинга. Что раньше, если я правильно понял коллег из этого чата, отрицалось намертво. Простите, если я неверно понял.
Все тут говорили, что где надо там они(IMDB ) и используются, но все данные как правило всё равно хранятся в обычных СУБД, — что вызывало у вас… В том же Билайне, если они покупали(не знаю точно) онлайн тарификацию — есть база в памяти, хотя у них древняя версия системы.
Очень интересно, что им там Эриксон наворотит и чем это закончится.
Ну вы конечно мастрер общения…
Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
Речь о биллинге, не?
«переходит на Тарантула» <> «меняет базу на Тарантула»?
Ну давайте скажите что-нибудь про Вангу или про то, что меня дезинформировали или что у вас там еще в арсенале?
Breslavets
В то же время, на обычных СУБД работают очень высоко-нагруженные системы.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
danikin
Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru.
Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете).
кто-то масштабирует базу, кто-то окружает ее IMDB-решениями. Говорить, что одно заведомо лучше чем другое — мне кажется, слишком… эм… серьезное обобщение.
Давайте закруглятся, нормального общения у нас не выходит.
Тут никто не говорил, что IMDB не имеют своей ниши.
В биллинге используют НЕ однy базу(как минимум отдельные базы для звонков — это вроде просто понять?) + IMDB+IMDG для масштабирования на нагрузочной части(тарификация).
ВСЕ данные всё равно как правило хранят в обычных СУБД по множеству причин.
IMDB не поможет если весь биллинг, вся функциональность(контракты, клиенты, платежи, диллеры, проведение ежемесячного биллинга, звонки, роуминг, ...) свалена в одну RDBMS на серьезных объемах, даже на средних придётся с бубном плясать когда какие-то процессы пересекутся…
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
Да не в этом дело, что подходит…
Устал уже говорить, что это давно используется в других системах.
И на место тарантула можно выбрать кучу кандидатов.
Проблема в том, что они уже были выбраны давно в системах о которых шла речь.
Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB.
Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
С вашей стороны это было совсем нескромное обобщение…
И я же еще и обобщаю что-то.
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
Ну да, не просто, но может поэтому другие системы и стоят дороже и рынок другой имеют?
Думаете «водафоны» всё держат в одной базе?
У RDBMS итак проблем с масштабированием хватает, и при таком подходе они усугубляются.
Но повторюсь, для большинства российских операторов системы адекватны и
гораздо удобнее сложных в сопровождении западных систем.
Своеобразности хватает в обоих системах(СБОСС-БИС), например, по каким-то религиозным соображениям в СБОСС вообще не использовались внешние ключи.
Как я понял кто-то из топовых разрабов имел проблемы с блокировками и решил, что проще отказаться от FK, чем разбираться в проблеме.
Причем даже просто попытка поговорить на эту тему вызывала конкретный праведный гнев у одного из них. :)
Видимо крепко декларативная ссылочная целостность кого-то из них огрела.
Нет смысла это обсуждать в этой теме…
Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе.
Это не пренебрежение, просто народ был введен в заблуждение.
Личный кабинет — это личный кабинет, а биллинг — это совсем другая сложность и стоимость — сами почитайте в Сети, с Эриксоном на $1млрд. контракт заключили на 7 лет.
До этого с Амдокс был не хилый контракт.
Причем когда я сказал, что Заказчик не может просто так поменять базу в биллинге/банковской системе, с вашей стороны опять был поток, скажем так, недобросовестной мысли.
И я не знаю чего тут больше, — незнание того как такие системы сопровождаются или просто было желание закидать шапками,
объявив бредом невозможность замены базы заказчиком.
До этого вы рассуждали о Тарантул-обертке именно в контексте биллинга для Билайна на первое время,… цитировать не буду, но речь там шла именно о биллинге, о звонках в IMDB.
В общем не здорово всё это, и надеюсь вы понимаете, что в существующую систему биллинга воткнуть что-то чужеродное, тем более такое своеобразное как Тарантул силами Заказчика невозможно. А поставщику биллингга это вообще никак не нужно — у него итак используются работа в памяти в онлайн-чарчинг системах, и IMDB и IMDG в текущих версиях(т.е. могли предложить обновить систему....).
Совсем другое дело личный кабинет.
Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle.
prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
И ключевое тут по теме —
«Она хранила все в памяти»…
и
«записывала результат в Oracle»…
Также как это делается в других подобных системах.
Спрашивается и чего мы тут буяним? :)
Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.
На винде приложение писали(Visual C++) как основной их тарификатор?
У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
Не знаю делали ли они отдельную базу для prepaid — не думаю.
Хотя для большинства не очень больших операторов их postpaid система удобна и проста. Как и BIS питерский.
М-да… столько букв..., я тут и Ванга, и зуб должен давать… и телепат…
Beeline переходит уже на Tarantool (почитайте новости в Интернете).
Почитал, в новостях есть что-то о использовании Тарантула в личном кабинете.
Это как-бы далеко не биллинг.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Амдокс, кстати, итак использует IMDB с незапамятных времен для тарификации( сейчас IMDB+IMDG чтобы масштабируемость обеспечить), но звонки всё равно хранятся в обычной базе…
А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?
Вопрос ставить надо не о сутках, а о месяцах.
2 месяца, 6ть…
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Плюс есть гос. требования к времени хранения.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.
Бред?
Ну вы жжете.
Базу может поменять разработчик биллинга/банковской системы в какой-то из своих версий и предложить эту версию кастомеру.
И это не простая задача даже при смене полноценных RDBMS с полной поддержкой SQL, всё требует проверки и сертификации.
Даже при смене одной и той же базы на более старшую версию в четвертой цифре (11.2.0.2->11.2.0.4) вопросы будут, а уж если первые менять…
Конечно, Заказчик может поменять поставщика биллинга, но это опять же не просто смена базы.
Тут тема исчерпана похоже, почитаю как снимки делаются.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
danikin
Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru. Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой.
Давным давно был СБОС, без всяких оберток.
Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.
И основная часть кода работает с обычными базами.
Потому что этого достаточно и с обычными базами кодить привычнее.:)
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
danikin
Beeline переходит уже на Tarantool (почитайте новости в Интернете).
Дык вот когда перейдут, тогда и поаплодируем уходу от «ораклов».
Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?
Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.
Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.
Ибо IMDB быстренько лопнет по памяти от такого потока.
Или есть секретный рецепт?
danikin
Сбербанк переводит свой процессинг на in-memory СУБД GridGain
Аналогично, переведет, посмотрим…
Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…
danikin
Уже используют. См. выше. То, что вы не в курсе — не означает, что этого нет.
Вы точнее формулируйте — уже хотят использовать…
Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.
Я бы подобные вопросы ставил не так, что какая-то контора(банк, билайн...) переводит систему на IMDB, а разработчик соответствующего софта переходит на IMDB.
Или еще точнее начинает дополнительно использовать IMDB в какой-то части системы.
Потому что сам банк или сотовая компания ничего не могут сами поменять.
Вот чей биллинг использует сейчас Билайн?
Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
Как это и есть сейчас в подобных проектах.
danikin
Я, вообще, предлагаю вылезли вам из ощущения мира, каким он был 20 лет назад. Он, не поверите, сильно поменялся с точки зрения нагрузок на СУБД и с точки зрения требованиям к latency.
Вылезти?
Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…
Я вот помню также активно вылезали в объектно-ориентированные базы…
Преподнося их как что-то новое на фоне реляционных…
Да так активно пиарили, что казалось уже завтра Oracle нигде не будет. :)
danikin
Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.
Начиная с последовательной записи в редо(Write-ahead logging — капитан очевидность)…
Из статьи я узнал нового только использовании LMS Дерева в одной из версий IMDB.
О том, что база перед стартом грузится в память — это итак понятно было.
Вы собирались писать о обычных СУБД — было бы интересно сравнить
производительность на одинаковых задачах IMDB vs usual RDBMS.
С использолванием кэша по умолчанию, с захешированными данными…
danikin
Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом
.
danikin
и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB.
Есть ощущение, что вы не особо пробовали обычные СУБД, ибо путаетесь в основах их устройства.
Тем не менее по-моему никто и не спорит о том, что IMDB имеет свою область применения.
Под вашу текущую задачу хорошо пошла IMDB — я так понял, что дешево и сердито. И пример хорош тем, что есть много таких задач(даже по объему если смотреть), где действительно нужно присмотреться к IMDB.
В то же время, на обычных СУБД работают очень высоко-нагруженные системы. От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
И поверьте, в этих системах денег особо не считают, надо было бы — использовали бы IMDB, если бы это было возможно(размеры баз, требования к downtime, надежности,...), и если бы это дало преимущества для бизнеса.
Вот этот ваш текст может быть истолкован неверно.
danikin
Механизма компактификации лога транзакций у дисковых СУБД нет
в терминологии IMDB — это чекпоинты в обычных базах.
После чекпоинта для горячего восстановления сбоя экземпляра
нужна только та часть лог-информации, что идет после этого чекпоинта.
Точно также как после снимка в IMDB не нужны старые журналы.
Тут их хранят(обычно на лентах) для возможного восстановления базы.
Сам процесс записи в табличные пространства не должен влиять на отклик в адекватной системе,
а процент попаданий при чтении(where ...) данных в кэш на горячих системах приближается к 100% — читай это IMDB.
danikin
Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
Разные задачи, разные объемы,
Запись в датафайлы будет вестись даже при достаточном количестве памяти.
Старт базы будет быстрым.
Перечитал еще раз, и увидел еще одно заблуждение по поводу обычных СУБД.
Даже не понял сначала с этой терминологией…
Снимки в IMDB — это аналоги чекпоинтов в обычных базах, ну и бакапы есть разных видов.
Память в адекватной системе не может кончится — специальный процесс постоянно следит за этим, выгружая наименее используемые блоки из кэша.
**************************************************************
Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
**********************************************************************
Не надо вам про обычные базы пока статью писать.
Лучше подробнее про IMDB рассказать.
Вот например, можно ли делать кластеры, что делать если потребуется увеличить размер базы.
Как это делается, растет и какие тут тонкости, чем платится и есть ли ограничения?
А как он снимок этот пишет на диск, если в базу запись идет постоянно?
Метки времени есть у страниц?
Не пишет те, у которых метки старше старта снятия снимка?
Или полную копию делает и пишет?
мол тяжелая вода там появляется…
Блин, поколение пепси, что-то где-то поверхностно прочитал, или скорее увидел,
и во всё верят.
Моск не хочет подумать — а сколько времени надо воду эту грешную кипятить,
чтобы там что-то вредно-тяжелое появилось…
Была бы вода из крана — там соли, хлорка,… еще можно понять, но когда говорят,
про воду из «поилки», где она практически дистиллированная, да еще и в контексте тяжелой воды…
Но это так, к слову… — мне понравились ваши критерии эффективного манагера.
Они делали лучшее, легендарное серверное железо, лучшие операционки для СЕРВЕРОВ,
и рынок этот никуда не уходил и сейчас не уходит.
Если не ошибаюсь, IBM сама скинула с себя PC часть.
Digital Equipment Corporation, выпускавшая Компьютеры VAX c OpenVMS, Alpha серверы с DEC Alpha c Digital Unix на отличном ядре, легендарную серию мини-ЭВМ PDP… включая PDP11.
Выпускающая кучу софта, включая банковскую систему…
Она от чего загнулась?
Тоже манагеры эффективные доконали?
Ведь казалось, что серьезнее фирмы Digital просто нет, или почти нет, — а вот…
Мало отзывов, видимо новое поколение не изучает глубоко железо.
Сразу, наверное жава-быдлокодить учат.
На сколько ниже питерско-московских зарплаты?
Краснодар, Воронеж, Ярославль…
строгий порядок членов в предложении.
Наличие только одного падежа(двух) привело к таким ограничениям.
Нельзя использовать кальку с русского, в котором слова можно мешать в предложении
как угодно.
Понял я, что…
Я понял, что…
Мне хотелось… — I should…
Ему надо… — He…
Это кто сделал?
Кто это сделал?
Нет родовых окончаний и почти никаких тебе уменьшительно-ласкательных :).
В общем там никакой свободы и слава богу, язык учить проще.
#36. Случаи, когда транзакция насильно завершается:
#…
#Пользователь издал любую DML или DCL команду.
#…
Еще раз, сейчас у них биллинг Amdocs, переходят они на Эриксон.
Ни в одну из этих систем другую базу не дадут втыкать.
Какую-то вспомогательную обработку(как-то личный кабинет — это не биллинг) могут повесить на что угодно.
Все тут говорили, что где надо там они(IMDB ) и используются, но все данные как правило всё равно хранятся в обычных СУБД, — что вызывало у вас… В том же Билайне, если они покупали(не знаю точно) онлайн тарификацию — есть база в памяти, хотя у них древняя версия системы.
Очень интересно, что им там Эриксон наворотит и чем это закончится.
Ну вы конечно мастрер общения…
Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
Речь о биллинге, не?
«переходит на Тарантула» <> «меняет базу на Тарантула»?
Ну давайте скажите что-нибудь про Вангу или про то, что меня дезинформировали или что у вас там еще в арсенале?
Давайте закруглятся, нормального общения у нас не выходит.
Тут никто не говорил, что IMDB не имеют своей ниши.
В биллинге используют НЕ однy базу(как минимум отдельные базы для звонков — это вроде просто понять?) + IMDB+IMDG для масштабирования на нагрузочной части(тарификация).
ВСЕ данные всё равно как правило хранят в обычных СУБД по множеству причин.
IMDB не поможет если весь биллинг, вся функциональность(контракты, клиенты, платежи, диллеры, проведение ежемесячного биллинга, звонки, роуминг, ...) свалена в одну RDBMS на серьезных объемах, даже на средних придётся с бубном плясать когда какие-то процессы пересекутся…
Да не в этом дело, что подходит…
Устал уже говорить, что это давно используется в других системах.
И на место тарантула можно выбрать кучу кандидатов.
Проблема в том, что они уже были выбраны давно в системах о которых шла речь.
Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
С вашей стороны это было совсем нескромное обобщение…
И я же еще и обобщаю что-то.
Ну да, не просто, но может поэтому другие системы и стоят дороже и рынок другой имеют?
Думаете «водафоны» всё держат в одной базе?
У RDBMS итак проблем с масштабированием хватает, и при таком подходе они усугубляются.
Но повторюсь, для большинства российских операторов системы адекватны и
гораздо удобнее сложных в сопровождении западных систем.
Своеобразности хватает в обоих системах(СБОСС-БИС), например, по каким-то религиозным соображениям в СБОСС вообще не использовались внешние ключи.
Как я понял кто-то из топовых разрабов имел проблемы с блокировками и решил, что проще отказаться от FK, чем разбираться в проблеме.
Причем даже просто попытка поговорить на эту тему вызывала конкретный праведный гнев у одного из них. :)
Видимо крепко декларативная ссылочная целостность кого-то из них огрела.
Нет смысла это обсуждать в этой теме…
И Oracle многим не нравится, только лучше ничего не придумали в стане RDBMS.
40 лет скоро, кстати старичку.
Это не пренебрежение, просто народ был введен в заблуждение.
Личный кабинет — это личный кабинет, а биллинг — это совсем другая сложность и стоимость — сами почитайте в Сети, с Эриксоном на $1млрд. контракт заключили на 7 лет.
До этого с Амдокс был не хилый контракт.
Причем когда я сказал, что Заказчик не может просто так поменять базу в биллинге/банковской системе, с вашей стороны опять был поток, скажем так, недобросовестной мысли.
И я не знаю чего тут больше, — незнание того как такие системы сопровождаются или просто было желание закидать шапками,
объявив бредом невозможность замены базы заказчиком.
До этого вы рассуждали о Тарантул-обертке именно в контексте биллинга для Билайна на первое время,… цитировать не буду, но речь там шла именно о биллинге, о звонках в IMDB.
В общем не здорово всё это, и надеюсь вы понимаете, что в существующую систему биллинга воткнуть что-то чужеродное, тем более такое своеобразное как Тарантул силами Заказчика невозможно. А поставщику биллингга это вообще никак не нужно — у него итак используются работа в памяти в онлайн-чарчинг системах, и IMDB и IMDG в текущих версиях(т.е. могли предложить обновить систему....).
Совсем другое дело личный кабинет.
prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
И ключевое тут по теме —
«Она хранила все в памяти»…
и
«записывала результат в Oracle»…
Также как это делается в других подобных системах.
Спрашивается и чего мы тут буяним? :)
На винде приложение писали(Visual C++) как основной их тарификатор?
У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
Не знаю делали ли они отдельную базу для prepaid — не думаю.
Хотя для большинства не очень больших операторов их postpaid система удобна и проста. Как и BIS питерский.
Почитал, в новостях есть что-то о использовании Тарантула в личном кабинете.
Это как-бы далеко не биллинг.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Амдокс, кстати, итак использует IMDB с незапамятных времен для тарификации( сейчас IMDB+IMDG чтобы масштабируемость обеспечить), но звонки всё равно хранятся в обычной базе…
Вопрос ставить надо не о сутках, а о месяцах.
2 месяца, 6ть…
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Плюс есть гос. требования к времени хранения.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Бред?
Ну вы жжете.
Базу может поменять разработчик биллинга/банковской системы в какой-то из своих версий и предложить эту версию кастомеру.
И это не простая задача даже при смене полноценных RDBMS с полной поддержкой SQL, всё требует проверки и сертификации.
Даже при смене одной и той же базы на более старшую версию в четвертой цифре (11.2.0.2->11.2.0.4) вопросы будут, а уж если первые менять…
Конечно, Заказчик может поменять поставщика биллинга, но это опять же не просто смена базы.
Тут тема исчерпана похоже, почитаю как снимки делаются.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
Давным давно был СБОС, без всяких оберток.
Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.
И основная часть кода работает с обычными базами.
Потому что этого достаточно и с обычными базами кодить привычнее.:)
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
Дык вот когда перейдут, тогда и поаплодируем уходу от «ораклов».
Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?
Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.
Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.
Ибо IMDB быстренько лопнет по памяти от такого потока.
Или есть секретный рецепт?
Аналогично, переведет, посмотрим…
Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…
Вы точнее формулируйте — уже хотят использовать…
Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.
Я бы подобные вопросы ставил не так, что какая-то контора(банк, билайн...) переводит систему на IMDB, а разработчик соответствующего софта переходит на IMDB.
Или еще точнее начинает дополнительно использовать IMDB в какой-то части системы.
Потому что сам банк или сотовая компания ничего не могут сами поменять.
Вот чей биллинг использует сейчас Билайн?
Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
Как это и есть сейчас в подобных проектах.
Вылезти?
Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…
Я вот помню также активно вылезали в объектно-ориентированные базы…
Преподнося их как что-то новое на фоне реляционных…
Да так активно пиарили, что казалось уже завтра Oracle нигде не будет. :)
Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.
Начиная с последовательной записи в редо(Write-ahead logging — капитан очевидность)…
Из статьи я узнал нового только использовании LMS Дерева в одной из версий IMDB.
О том, что база перед стартом грузится в память — это итак понятно было.
Вы собирались писать о обычных СУБД — было бы интересно сравнить
производительность на одинаковых задачах IMDB vs usual RDBMS.
С использолванием кэша по умолчанию, с захешированными данными…
.
Есть ощущение, что вы не особо пробовали обычные СУБД, ибо путаетесь в основах их устройства.
Тем не менее по-моему никто и не спорит о том, что IMDB имеет свою область применения.
Под вашу текущую задачу хорошо пошла IMDB — я так понял, что дешево и сердито. И пример хорош тем, что есть много таких задач(даже по объему если смотреть), где действительно нужно присмотреться к IMDB.
В то же время, на обычных СУБД работают очень высоко-нагруженные системы.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
И поверьте, в этих системах денег особо не считают, надо было бы — использовали бы IMDB, если бы это было возможно(размеры баз, требования к downtime, надежности,...), и если бы это дало преимущества для бизнеса.
Вот этот ваш текст может быть истолкован неверно.
в терминологии IMDB — это чекпоинты в обычных базах.
После чекпоинта для горячего восстановления сбоя экземпляра
нужна только та часть лог-информации, что идет после этого чекпоинта.
Точно также как после снимка в IMDB не нужны старые журналы.
Тут их хранят(обычно на лентах) для возможного восстановления базы.
Сам процесс записи в табличные пространства не должен влиять на отклик в адекватной системе,
а процент попаданий при чтении(where ...) данных в кэш на горячих системах приближается к 100% — читай это IMDB.
Разные задачи, разные объемы,
Запись в датафайлы будет вестись даже при достаточном количестве памяти.
Старт базы будет быстрым.
Даже не понял сначала с этой терминологией…
Снимки в IMDB — это аналоги чекпоинтов в обычных базах, ну и бакапы есть разных видов.
Память в адекватной системе не может кончится — специальный процесс постоянно следит за этим, выгружая наименее используемые блоки из кэша.
**************************************************************
Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
**********************************************************************
Не надо вам про обычные базы пока статью писать.
Лучше подробнее про IMDB рассказать.
Вот например, можно ли делать кластеры, что делать если потребуется увеличить размер базы.
Как это делается, растет и какие тут тонкости, чем платится и есть ли ограничения?
Метки времени есть у страниц?
Не пишет те, у которых метки старше старта снятия снимка?
Или полную копию делает и пишет?
А можно разные диски задать для снапшота и редо?