Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB. У вас есть безусловно опыт тут. Странно, что вы его обобщаете на все и вся. Но это ваше дело :-)
prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
И ключевое тут по теме —
«Она хранила все в памяти»…
и
«записывала результат в Oracle»…
Также как это делается в других подобных системах.
Спрашивается и чего мы тут буяним? :)
Есть такая способность у многих людей, начинать спорить по одному вопросу, потом не закрыв первый переходить ко второму, потом приписывать другой стороне спора несуществующие аргументы и открывать по ним третий спор.
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
На винде приложение писали(Visual C++) как основной их тарификатор?
Да. Кажется, callcharge.exe назывался
У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
Не знаю делали ли они отдельную базу для prepaid — не думаю.
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Не все сразу
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Разве нельзя исторические данные, на которые почти нет нагрузки, хранить в RDBMS? Можно. Одно другому-то не мешает.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе. Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle. Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
Что я и делаю. Готов слушать любой троллинг, наезды и неадекват, лишь бы за этой щелухой хотя бы иногда проглядывало драгоценое зерно истины и знаний :-)
1. Потому что хэш быстрее дерева на точечных лукапах и тест у нас точечного лукапа (на range лукапах, разумеется, надо брать дерево, ибо хэш их не умеет). В IMDB Tarantool есть хэш индекс (https://tarantool.org/doc/singlehtml.html). В RDBMS Postgres тоже есть хэш индекс (https://www.postgresql.org/docs/9.1/static/indexes-types.html).
2. Внешние сложения — чтобы оптимизатор прошел цикл, без свертки всего сразу. Умножение внутри — чтобы обеспечить какой-никакой рандом. Реальный рандом сам бы вносил в вычисления большую погрешность, т.к. выполняется не быстро.
Справедливое замечание. Принимаю. Проверили конкретную программу с -O2 и даже с -O1 — примерно также как с -O3. Однако, все равно остаюсь фанатом -O3. На моей практике всегда, если падало с -O3, то после даже нескольких дней копаний, чертыханий и ругани про себя на кривую реализацию gcc, всегда находил конкретный баг. Хотя, честно скажу, руки постоянно тянулись вернуть все в -O2. Возможно, я не натыкался на реальные баги в gcc, связанные с -O3.
В статье все написано. Если кликните на эту ссылку, то все увидите. Это Amazon t2.micro.
Именно таким способом мы существенно сократили количество системных вызовов в Tarantool. По ссылке можно подробней прочитать о том, как наша система работает и справляется с миллионом транзакций в секунду на одном ядре.
Клиент внутри себя параллельно (паралллельно, потому что у клиента много потоков внутри) формирует запросы и далее запихивает их в один сокет одним пакетом. Они приезжают на сервер. Сервер считывает пакет за один сискол.
Угу. А еще давнее (еще до СБОСа) биллингов не было, и компьютеров не было.
Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.
Прям ВСЯ и у ВСЕХ во ВСЕХ кейсах? Зуб даете?
И основная часть кода работает с обычными базами.
Потому что этого достаточно и с обычными базами кодить привычнее.:)
Да. Работает — не трожь.
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
IMDB тоже имеют. Но рынок консервативный, спору нет.
Да.
Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?
А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?
Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.
Вас дезинформировали. Делают по разному.
Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.
По началу Билайн так и будет делать. А потом задастся вопросом — а зачем мне основная база-то?
Ибо IMDB быстренько лопнет по памяти от такого потока.
Вам вангой надо работать.
Или есть секретный рецепт?
Будем секреты по чуть-чуть выдавать. Не все сразу.
Аналогично, переведет, посмотрим…
Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…
Сделают так, как это будет эффективней Самоцели заменять Оракл на что-то еще — ни у кого нет. Есть экономика и развитие бизнеса.
Вы точнее формулируйте — уже хотят использовать…
Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.
Ну точно ванга.
Потому что сам банк или сотовая компания ничего не могут сами поменять.
Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.
Вот чей биллинг использует сейчас Билайн?
Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
Как это и есть сейчас в подобных проектах.
Пока Tarantool будет оберткой, потом репликой, а там посмотрим.
Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…
Прям таки ВЕЗДЕ? Я завидую вашей осводомленности обо ВСЕМ и обо ВСЕХ.
В IMDB рандомной записи, действительно, нет (и в частности в Memtx в Tarantool). В конкретно Vinyl ее тоже нет. Поэтому она тянет нагрузку на запись больше чем InnoDB от MySQL, например. Бенчи скоро покажем. Сам по себе Vinyl основан на LSM и фейсбучном RocksDB. Бенчи RocksDB вот тут: http://smalldatum.blogspot.ru/2016/01/rocksdb-vs-innodb-via-linkbench.html
Другой акцент, который я дела, что даже если все сидит в кэшах, то IMDB все равно быстрее RDBMS, просто потому что она заточена под быть всегда in-memory.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Про функционал я вообще в статье ни разу не говорил. Функционала у RDBMS больше чем у IMDB. И это одно из преимуществ RDBMS. Я тут только про производительность.
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
Вот именно. Я уж лучше переживу неадекватный троллинг, но дам людям новые знания.
Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.
Видимо, вы умеете читать мысли и знаете то, _что_я_считаю_новым_. Ок. Убеждать вас в обратном не вижу смысла, потому что вы лучше меня знаете, что я считаю, и что я не считаю :-)
Из статьи я узнал нового только использовании LMS Дерева в одной из версий IMDB.
Ну хотя бы в чем-то получили профит. Я рад.
Вы собирались писать о обычных СУБД — было бы интересно сравнить
производительность на одинаковых задачах IMDB vs usual RDBMS.
С использолванием кэша по умолчанию, с захешированными данными…
Уже писал выше, что напишу. И уже писал выше, что IMDB по моему опыту быстрее в десятки раз даже в этом случае. Не верите — проверьте, ну или ждите статьи.
Есть ощущение, что вы не особо пробовали обычные СУБД, ибо путаетесь в основах их устройства.
Не буду спорить с вашим ощущением. У меня тоже есть ощущение, что вы не пробовали обычные СУБД на нагрузках под 1000 транзакций в СЕКУНДУ и никогда не упирались в их потолок. Но я лучше оставлю его при себе.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru. Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете). Сбербанк переводит свой процессинг на in-memory СУБД GridGain — почитайте тоже новости в Интернете. Я, вообще, предлагаю вылезли вам из ощущения мира, каким он был 20 лет назад. Он, не поверите, сильно поменялся с точки зрения нагрузок на СУБД и с точки зрения требованиям к latency.
И поверьте, в этих системах денег особо не считают, надо было бы — использовали бы IMDB, если бы это было возможно(размеры баз, требования к downtime, надежности,...), и если бы это дало преимущества для бизнеса.
Уже используют. См. выше. То, что вы не в курсе — не означает, что этого нет.
в терминологии IMDB — это чекпоинты в обычных базах.
После чекпоинта для горячего восстановления сбоя экземпляра
нужна только та часть лог-информации, что идет после этого чекпоинта.
Точно также как после снимка в IMDB не нужны старые журналы.
Тут их хранят(обычно на лентах) для возможного восстановления базы.
Сам процесс записи в табличные пространства не должен влиять на отклик в адекватной системе,
а процент попаданий при чтении(where ...) данных в кэш на горячих системах приближается к 100% — читай это IMDB.
Вот, пожалуй, единственное утверждение, с которым не хочется спорить. Все верно сказали :-)
Запись в датафайлы будет вестись даже при достаточном количестве памяти.
Старт базы будет быстрым.
Если бы вы использовали обычные СУБД на тех нагрузках, где IMDB вообще даже не начинают напрягаться (10К+ запросов в секунду), то вы бы поняли, что они начинают трещать по швам. И старт у них медленных, ибо нагрузка на холодную базу в 10K+ запросов в секунду убивает ее в щи.
Надеюсь, у вас хватит уверенности в себе пообщаться со мной и вы не будете скрываться :-)
«Любую структуру можно расположить в непрерывно выделенном участке памяти» — ответа на вопрос как это сделать так и не поступило. Возможно, если выйдете на связь, расскажите. Пока звучит голословненько.
«Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?» — не понял вашего вопроса, простите. Сформулируйте, плиз, по другому.
«Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) » — какую магию, вы о чем?
«говорите и сравнивайте только с аналогичными фичами «данных в памяти».» — вы хотите, чтобы я в этой статье вместо того, что написал сравнил бы Tarantool с другими in-memory по их функциям? Мой ответ вам такой — менять эту статью на другую не буду. Эта статья конкретно про специфику IMDB в общем, а не про сравнение различных IMDB между собой. Сравнение Tarantool частично с Redis есть тут: https://habrahabr.ru/company/mailru/blog/317150/. Кроме того есть другое сравнение Tarantool с Redis вот тут https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc#.yk5wxwdpx (написал внешний к Tarantool человек, там мой только перевод, ссылка на оригинал в тексте)
А я в третий раз спрашиваю — КАК? Наша конкретная структура не линейно лежит в памяти. У вас есть более умная структура? Расскажите, как она устроена. Мой скайп danikin2. Если у вас цель не самопиариться на хабре, а получить ответы на ваши вопросы, то стучитесь мне в скайп — все расскажу, ну или свой скайп оставьте — я вам постучусь.
У Tarantool есть два движка — memtx (движок по умолчанию — in-memory) и vinyl (дополнительный, не in-memory движок, т.е. он не хранит все данные в памяти и предназначен для use cases, когда все данные в память не влезают).
Вы считаете, что Vinyl — это in-memory движок? Ну ок, продолжайте считать дальше. И на основании этого заблуждения стройте какие-угодно теории. Стройте, не буду вам мешать. Если вам это доставляет удовольствие :-)
Ну все ок, я научился уже угадывать, что люди спрашивают. Просто иногда лучше явно спросить, что имели в виду, чтобы человек после уже ответа на вопрос не сказал бы, что «а я имел в виду совсем другое».
Отличный способ. Меняется одно значение в базе данных и копируется минимум 2Мб (или какой размер страницы вы выбрали?). А на практике — еще больше. Допустим, если у вас дерево и надо его перебалансировать и сделать несколько записей в рандомные куски памяти, то, глядишь, и десяток мегабайт скопируйте. И так на каждое обновление значения в базе (а их может быть и сто тысяч в секунду). Отличное решение.
Есть такая способность у многих людей, начинать спорить по одному вопросу, потом не закрыв первый переходить ко второму, потом приписывать другой стороне спора несуществующие аргументы и открывать по ним третий спор.
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
Да. Кажется, callcharge.exe назывался
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
Не все сразу
Разве нельзя исторические данные, на которые почти нет нагрузки, хранить в RDBMS? Можно. Одно другому-то не мешает.
Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе. Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle. Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.
Что я и делаю. Готов слушать любой троллинг, наезды и неадекват, лишь бы за этой щелухой хотя бы иногда проглядывало драгоценое зерно истины и знаний :-)
1. Потому что хэш быстрее дерева на точечных лукапах и тест у нас точечного лукапа (на range лукапах, разумеется, надо брать дерево, ибо хэш их не умеет). В IMDB Tarantool есть хэш индекс (https://tarantool.org/doc/singlehtml.html). В RDBMS Postgres тоже есть хэш индекс (https://www.postgresql.org/docs/9.1/static/indexes-types.html).
2. Внешние сложения — чтобы оптимизатор прошел цикл, без свертки всего сразу. Умножение внутри — чтобы обеспечить какой-никакой рандом. Реальный рандом сам бы вносил в вычисления большую погрешность, т.к. выполняется не быстро.
Угу. А еще давнее (еще до СБОСа) биллингов не было, и компьютеров не было.
Прям ВСЯ и у ВСЕХ во ВСЕХ кейсах? Зуб даете?
Да. Работает — не трожь.
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
IMDB тоже имеют. Но рынок консервативный, спору нет.
Да.
А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?
Вас дезинформировали. Делают по разному.
По началу Билайн так и будет делать. А потом задастся вопросом — а зачем мне основная база-то?
Вам вангой надо работать.
Будем секреты по чуть-чуть выдавать. Не все сразу.
Сделают так, как это будет эффективней Самоцели заменять Оракл на что-то еще — ни у кого нет. Есть экономика и развитие бизнеса.
Ну точно ванга.
Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.
Пока Tarantool будет оберткой, потом репликой, а там посмотрим.
Прям таки ВЕЗДЕ? Я завидую вашей осводомленности обо ВСЕМ и обо ВСЕХ.
Другой акцент, который я дела, что даже если все сидит в кэшах, то IMDB все равно быстрее RDBMS, просто потому что она заточена под быть всегда in-memory.
Про функционал я вообще в статье ни разу не говорил. Функционала у RDBMS больше чем у IMDB. И это одно из преимуществ RDBMS. Я тут только про производительность.
Вот именно. Я уж лучше переживу неадекватный троллинг, но дам людям новые знания.
Видимо, вы умеете читать мысли и знаете то, _что_я_считаю_новым_. Ок. Убеждать вас в обратном не вижу смысла, потому что вы лучше меня знаете, что я считаю, и что я не считаю :-)
Ну хотя бы в чем-то получили профит. Я рад.
Уже писал выше, что напишу. И уже писал выше, что IMDB по моему опыту быстрее в десятки раз даже в этом случае. Не верите — проверьте, ну или ждите статьи.
Не буду спорить с вашим ощущением. У меня тоже есть ощущение, что вы не пробовали обычные СУБД на нагрузках под 1000 транзакций в СЕКУНДУ и никогда не упирались в их потолок. Но я лучше оставлю его при себе.
Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru. Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете). Сбербанк переводит свой процессинг на in-memory СУБД GridGain — почитайте тоже новости в Интернете. Я, вообще, предлагаю вылезли вам из ощущения мира, каким он был 20 лет назад. Он, не поверите, сильно поменялся с точки зрения нагрузок на СУБД и с точки зрения требованиям к latency.
Уже используют. См. выше. То, что вы не в курсе — не означает, что этого нет.
Вот, пожалуй, единственное утверждение, с которым не хочется спорить. Все верно сказали :-)
Если бы вы использовали обычные СУБД на тех нагрузках, где IMDB вообще даже не начинают напрягаться (10К+ запросов в секунду), то вы бы поняли, что они начинают трещать по швам. И старт у них медленных, ибо нагрузка на холодную базу в 10K+ запросов в секунду убивает ее в щи.
Надеюсь, у вас хватит уверенности в себе пообщаться со мной и вы не будете скрываться :-)
«Любую структуру можно расположить в непрерывно выделенном участке памяти» — ответа на вопрос как это сделать так и не поступило. Возможно, если выйдете на связь, расскажите. Пока звучит голословненько.
«Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) » — какую магию, вы о чем?
«говорите и сравнивайте только с аналогичными фичами «данных в памяти».» — вы хотите, чтобы я в этой статье вместо того, что написал сравнил бы Tarantool с другими in-memory по их функциям? Мой ответ вам такой — менять эту статью на другую не буду. Эта статья конкретно про специфику IMDB в общем, а не про сравнение различных IMDB между собой. Сравнение Tarantool частично с Redis есть тут: https://habrahabr.ru/company/mailru/blog/317150/. Кроме того есть другое сравнение Tarantool с Redis вот тут https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc#.yk5wxwdpx (написал внешний к Tarantool человек, там мой только перевод, ссылка на оригинал в тексте)
Вы считаете, что Vinyl — это in-memory движок? Ну ок, продолжайте считать дальше. И на основании этого заблуждения стройте какие-угодно теории. Стройте, не буду вам мешать. Если вам это доставляет удовольствие :-)