Оракл купил mysql чтобы залезть в другую лигу. Postgresql во многом копирует oracle, и, хотя вечно в роли догоняющего, является прямым конкурентом на рынке условного enterprise.
/*дальше сугубо мое субъективное мнение поскольку с mssql знаком слабо*/ Mysql же когда-то была "простой базой для сайтов", с тех пор много чего поменялось, но все равно как мне кажется она позиционируется как более простая СУБД без этих вот всяких заморочек.
В PostgreSQL, таблица без индексов и out-of-storage полей - один файл
А как же карта свободного пространства и карта видимости? ;-) 1 таблица всё-таки 3 файла даже если нет TOAST. Хотя карта свободного пространства есть и в оракл (в системных таблицах кажется), так что чтений будет плюс-минус одинаково.
Что касается самостоятельного распределения страниц в едином файле, то тут у СУБД возможностей меньше, чем у файловой системы. Потому что она, в отличии от файловой системы, не имеет понятия, в каких экстентах (непрерывных участках) расположен файл.
Поэтому оракл создает файл нужного размера сразу, чтоб фрагменированность была минимальной. Есть конечно autoextent, но тут уж разработчику решать включать его или добавлять дополнительные файлы к tablespace
С другой стороны ФС совершенно ничего не знает про данные - какой прирост данных будет в файле, с какой интенсивность. А база знает если это ей сказал разработчик или если включен сбор статистики. Вроде ораклоиды призывали отказаться от ерунды вида ручного задания свойств таблиц, мол база умная, сама порешает, но что-то у меня сомнения.
Как-то я себе с трудом представляю операционку, которая в заботе о монолитности файла оставляет дыры в свободных блоках HDD или тем более что-то куда-то двигает. Главная забота операционки - транзакционное поддержание целостности файловой системы.
Дефрагментация файлов на серваке СУБД? Такая себе затея. И так диски база дрючит, а тут еще дополнительная нагрузка.
На самом деле наш спор в нынешнее время сугубо академический. С приходом SSD никто кроме контроллера не знает где физически живет блок и никто кроме контроллера его не подвинет.
Хорошо, если с фулскан пример так себе, то допустим нам надо прочитать 1 строку. В оракле мы прочитаем 1 блок диска - 1 чтение. В постгре в каких-то случаях на придется прочитать данные из 3 файлов - 3 операции чтения.
Как это не влияет? Допустим у нас full scan. Тогда если 1 файл и небольшое число экстентов на таблицу (косвенно зависит от свойств таблицы - сколько места добавлять когда оно кончается), то имеем последовательное чтение. А если записью в таблицу/файл ведает операционка, то получим кучу раскиданных по диску блоков. и полное чтение файла выльется в рандомный доступ к диску, что для HDD сильно медленнее.
Понятно что пример несколько утрирован, но если уж нам по каким-то причинам нужен fullscan (аналитику например делаем), то и так запрос будет не быстрым, а мы его еще дополнительно кратно замедляем.
В постгре и оракл после падения по питанию обычно достаточно запустить базу - она сама восстановится если wal/redolog файлы целые. Но ведь если мы пишем через операционку, она ведь гарантирует что всё честно записано на диск, правда-правда (fsync, и всё такое)? :-)
С файлами обычно приходится возиться когда уж совсем всё пошло не так.
До сих пор страдаем с лимитом подключений кластера
Там еще проблема в том, что они не стали заморачиваться глобальным кэшем для prepared statement, а сделали это на уровне сессии (процесса), сразу выделяя под него место на старте процесса. Мало того что это оверхэд на подготовку запроса, так еще оно и памяти немало ест когда сессий много. Возможно, если у вас так много сессий, поможет уменьшение размера этого кэша (хотя решение довольно спорное, надо смотреть по ситуации)
Зы: но администрирование постгри - это дичь. Там где MsSQL из коробки работает на 100%, постгрю настраивать/подстраивать для тех же результатов (на одной ОС/машине). Но это дело привычки и навыков.
Отчасти это "заслуга" академического прошлого базы, пошедшей от проекта университета Беркли, как написали выше, а отчасти от Unix way. Когда я первый раз узнал, что каждая таблица в PG это 3-5 файлов (Карл!), после оракл где все таблицы можно упаковать в 1 файл и настроить их так, чтоб фрагментация была минимальна, у меня глаза на лоб полезли. Понятно, что сейчас в SSD разница в доступе сильно нивелировалась, но раньше на хардах, это ж какой ад наверное был!
Примерно то же самое с настройками - база из коробки преднастроена так, чтобы запуститься на любом тапке, ни о какой производительности речь совершенно не идет, когда ставят такую цель. И да, много чего надо покрутить в конфиге, чтоб оно нормально заработало
Мне было интересно в неё возюкаться в самом начале - ничего не понятно, НО ВСЁ ТАК ИНТЕРЕСНО. Специально не смотрел/не читал гайдов, чтобы на своем опыте до всего дойти, строил и перестраивал жуткие спагетти в рамках прототипов, костылил все это. Потом немного с чем-то разобрался, понял как надо, перезапустил заново и на каком-то этапе вдруг понял что всё превращается в рутину. Прикинул сколько еще масштабировать всё это и затосковал...
В разработке так же - кому-то нравиться исследовать, кому-то писать идеальный код. Мне и в разработке интересней разбираться с непонятной хренью,10 раз переписывать прототипы/тесты. А потом когда разобрался, сказать "народ, я понял как надо - вот так и так, если что обращайтесь, подскажу, а мне вон с той непонятной хренью надо разбираться".
Нет-нет, вы неправы - все знают, что у каждого ИТ-шника есть хобби. Пусть будет, ммм... скажем выпечка хлеба - я видел тут статью (даже переиздавалась!), и, судя по комментариям, все увлекаются выпечкой хлеба. Тогда надо ехать во Францию - судя по интернету, там все непрерывно едят багеты, успех будет оглушительным!
ЗЫ: Это шутка с отсылкой к одной легендарной статье, а то тут иногда проблемы с детектированием юмора.
Полностью согласен. Тем более что местное сообщество за версту чует, и на дух не переваривает, всё это вот копирайтерство. А сейчас еще и в использовании нейросеток обвинят.
А вот статья про про БС-ку (базовую станцию, комментарий для стороннего читателя), Вам наверно будет интересна - она тоже попала под каток копирайтера, но для связиста там много интересной информации закопанной в словоблудстве. Второй раз даже не рискну оставить ссылку, если сами не найдёте, стучитесь в личку. Кратко - все производители в основном в хард - антенны, усилители, а мы в софт. Риалтаймовую обработку на SDR для кучи подключенных терминалов сделать тяжело, но прототипы в 5G обкатывать можно
Перечитал свою (изначально) статью по ссылке - она не просто пресная и формалистская. Она просто чудовищна языком и пропусками логики повествования, да и просто слов в предложениях. С корректурой вот этого корпоративно-бодрого стиля я не справился от слова совсем.
Сейчас улыбает бодрое "мы". Разрабатывал это я один. Сначала, когда делал кучу синтетических тестов на утечки памяти, допустимые объемы данных передаваемых по DCOM по сети (ну шутка ли, 100 мегабайт в пакете :) помощники были не нужны. Потом долго рефакторил клиент-серверную архитектуру в серверный монолит, по пути пытаясь оптимизировать огромное накопившееся легаси. Потом стали понятны затыки архитектуры и как ее разнести по сервисам (хочешь сделать хорошо - сделай сам (с)). Только после этого стали нужны помощники, но уже и ресурсов нет, да и работа, считай, сделана. Угу, потом еще год допиливал в промышленной эксплуатации.
Так что статья только любителям подробностей странных решений странных систем...
Попробую написать про то, как мы в ситуации когда память есть, а проца и ввода/вывода мало, пытались сделать в рамках базы свой наколеночный in-memory кэш для часто используемых данных а-ля стоимости услуг для тарифного плана.
На первый взгляд там классическое key-value хранилище, но нюансы ТЗ превратили всё это в олимпиадную задачу, над которой бились много лет сменяя подходы с наивных до изощренных, и что из того что не написано в документации превращало в прах наши многочисленные попытки оптимизировать получение данных из простой казалось бы функции, таскающей данные из почти простой таблицы.
Была одна статья, не сочтите за рекламу, сам еле ссылку нашел.
Предыстория: когда-то наша компания решила вести блог на Хабре, и маркетолог попросил нас накидать идей для интересных статей, а потом и сами статьи. Накидать-то легко в таком стиле что выше. Но, я убил, наверное, неделю на редактуру, чтобы все причесать и привести в порядок поток мыслей. Потом статья попала к копирайтеру, который переписал всё более легким языком, заодно сильно сгладив углы. Конечно, советуясь со мной и присылая бесконечные ревизии текста. Фактологические ошибки или неточности формулировок я старался править, но на каком-то этапе понял, что этот бесконечный agile цикл надо завершать, уже сил нет ни вычитывать, ни в надцатый раз объяснять свою корректуру.
В результате получилось, на мой взгляд, довольно пресно и язык немного канцелярский.
Спасибо за ностальгическую статью, всколыхнула мои воспоминания, связанные с телекомом.
Я правда не связист, а разработчик, занимающийся большей частью базами данных (но в то время четкого деления не было, занимались всем, что потребуется)
Казань, двухтысячный год, я год как закончил КАИ, практику проходил в Татэнерго, и туда же устроился работать, т.к. там уже были свои спецы по Oracle, а тут еще присоединилась команда из банка, у которой было чему поучиться. Платили совсем копейки, но уму-разуму учили хорошо. Например, прихожу к человеку с вопросом – вот написал хранимку, а отладить не могу, на третьей итерации цикла отладчик падает вместе с сессией (оракл, кажется, был 7 версии, там все было грустно). Мне сразу вопрос – зачем тебе отладчик, главный отладчик — это голова, где у тебя программа с такой ошибкой может упасть? Ну вот наверно тут и тут… При каких условиях? Ну наверно если так… Вот и вставь туда вывод этих значений, посмотри, что ты туда приходишь и какие там данные… Отладчики давно уже работают как надо, но зачем, и так примерно понятно при какой ошибке что где могло пойти не так, максимум вывести отладочные данные.
Потом команда уходит из Татэнерго и там становится кисло. Параллельно общаюсь с друзьями, которые еще студенты, но работают в первом GSM операторе Татарстана «Сантел». В то время у нас есть DAMPS оператор Татинком и какой-то малораспространенный CDMA. На их фоне Сантел выглядит как гаражный стартап – наняли студентов, они пилят самописный биллинг. И вот я друзьям рассказываю тонкости Оракл, они мне про интересные проектные решения типа трехзвенки (тогда все двузвенку пилили). И, когда из Татэнерго уходит последний человек у которого имело смысл учиться, положил заявление на стол, пошел в телеком, благо занимался примерно тем же – разрабатывал биллинговую систему для теплоэнергетиков (ага, в однеху, начинал еще студентом в качестве диплома и тянул разработку 2 года, понятно что было маленько выгорание :).
Поначалу платили хоть и в 2 раза больше, чем на предыдущем месте, но ничего фантастического, плюс работы было очень сильно больше – отдыхать в субботу скорее исключение, чем правило. Биллинг уже более-менее работал, но первый год мы его яростно дорабатывали под новые идеи маркетологов и появляющиеся на ходу требования. Потом абонентов стало больше, серверное железо тянуло все это с большим трудом, доходило до того что 24 часа CDR-ок (тарификационных записей с коммутатора) обсчитывались 23 часа – чуть просядем и перестанем успевать тарифицировать, и мы около года оптимизировали тарификацию, попутно служебкми закидывая начальство, что нужно новое железо и хорошо бы резервное еще (ага, самый дорогой по тарифам оператор работал без резерва и бакапа). Потом рассыпался RAID-массив, казалось что все, можно лавочку закрывать, 2 недели спец из Москвы колупал диски массива в бинарном редакторе, тарификация стояла. Когда подняли массив еще месяц, наверное, нагоняли. Наконец пришел новый сервер, в котором было куда больше ядер чем в прежнем, выдохнули ненадолго. Но абонентская база перла как ненормальная. С одной стороны хорошо – первое время за каждые 10 тысяч абонов премию давали, с другой непрерывное повышение нагрузки (а с удешевлением тарифов абоны еще и траффика генерировали все больше) И выяснилось что теперь мы упираемся не в процессор, а уже в диски – запущенные параллельно тарификаторы упираются в горячие блоки индексов - перестраивали их с новыми параметрами, на больших таблицах процесс долгий и (в той версии) требовавший эксклюзивной блокировки таблицы, что лочило работу системы. Дальше выяснилось, что мы далеко не все изначально партиционировали, что надо было. Систему надолго останавливать нельзя, а расчетное время работ на создать новую версию таблицы около полусуток. Создавали новую версию таблицы не останавливая систему и потихоньку переливали архивные данные, создавали все индексы, потом стопали систему, переименовывали старую/новую таблицы и по-быстрому доливали свежие данные.
Дальше маленького (не очень), но гордого оператора выкупает красный федеральный (тогда еще без яйцеобразного логотипа), и поскольку у него гора региональных операторов с зоопарком биллингов, начинает консолидацию их в один свой. Все доработки замораживаются, т.к. мы внедряем новые фичи быстрее, чем они успевают запилить их у себя, несколько лет ведут разработку, мы неторопливо готовим скрипты выгрузки для их биллинга и, поскольку нам скучно, параллельно разрабатываем и внедряем новую версию биллинга уже для местного городского проводного/интернетного оператора, а потом и для оператора ТВ. Потом начинается оптимизация и мы уходим в небольшую компанию, которая продолжает развивать и поддерживать новые версии для этих операторов, а красные федералы от техподдержки отказываются и тащат всою версию сами, т.к. всех смигрить так и не смогли. Ирония в том, что по прошествии годов команда разработки у красных многократно сменилась и утеряла компетенции по поддержки этого по нынешним временам махрового легаси. Так что мы опять выполняем функцию поддержки этой самой старой версии системы, творчески доработанной многими поколениями команды красных. Около 90% ошибок связаны с этими доработками, и это отдельный скил разобраться в чужом странном коде, который ты видишь первый раз – отрефакторить что он делает, что разрабы имели ввиду, что пошло не так и как это исправить корректировкой данных или кода.
Оракл купил mysql чтобы залезть в другую лигу. Postgresql во многом копирует oracle, и, хотя вечно в роли догоняющего, является прямым конкурентом на рынке условного enterprise.
/*дальше сугубо мое субъективное мнение поскольку с mssql знаком слабо*/ Mysql же когда-то была "простой базой для сайтов", с тех пор много чего поменялось, но все равно как мне кажется она позиционируется как более простая СУБД без этих вот всяких заморочек.
1 файл создается сразу нужного размера (условно "пустой") и в дальнейшем если нет опции autoextend не ресайзится
Согласен. Диалог носит скорее академический характер с целью разобрать тонкости баз/хранилищ :-)
А как же карта свободного пространства и карта видимости? ;-) 1 таблица всё-таки 3 файла даже если нет TOAST. Хотя карта свободного пространства есть и в оракл (в системных таблицах кажется), так что чтений будет плюс-минус одинаково.
Поэтому оракл создает файл нужного размера сразу, чтоб фрагменированность была минимальной. Есть конечно autoextent, но тут уж разработчику решать включать его или добавлять дополнительные файлы к tablespace
С другой стороны ФС совершенно ничего не знает про данные - какой прирост данных будет в файле, с какой интенсивность. А база знает если это ей сказал разработчик или если включен сбор статистики. Вроде ораклоиды призывали отказаться от ерунды вида ручного задания свойств таблиц, мол база умная, сама порешает, но что-то у меня сомнения.
Как-то я себе с трудом представляю операционку, которая в заботе о монолитности файла оставляет дыры в свободных блоках HDD или тем более что-то куда-то двигает. Главная забота операционки - транзакционное поддержание целостности файловой системы.
Дефрагментация файлов на серваке СУБД? Такая себе затея. И так диски база дрючит, а тут еще дополнительная нагрузка.
На самом деле наш спор в нынешнее время сугубо академический. С приходом SSD никто кроме контроллера не знает где физически живет блок и никто кроме контроллера его не подвинет.
Хорошо, если с фулскан пример так себе, то допустим нам надо прочитать 1 строку. В оракле мы прочитаем 1 блок диска - 1 чтение. В постгре в каких-то случаях на придется прочитать данные из 3 файлов - 3 операции чтения.
Как это не влияет? Допустим у нас full scan. Тогда если 1 файл и небольшое число экстентов на таблицу (косвенно зависит от свойств таблицы - сколько места добавлять когда оно кончается), то имеем последовательное чтение. А если записью в таблицу/файл ведает операционка, то получим кучу раскиданных по диску блоков. и полное чтение файла выльется в рандомный доступ к диску, что для HDD сильно медленнее.
Понятно что пример несколько утрирован, но если уж нам по каким-то причинам нужен fullscan (аналитику например делаем), то и так запрос будет не быстрым, а мы его еще дополнительно кратно замедляем.
В постгре и оракл после падения по питанию обычно достаточно запустить базу - она сама восстановится если wal/redolog файлы целые. Но ведь если мы пишем через операционку, она ведь гарантирует что всё честно записано на диск, правда-правда (fsync, и всё такое)? :-)
С файлами обычно приходится возиться когда уж совсем всё пошло не так.
Там еще проблема в том, что они не стали заморачиваться глобальным кэшем для prepared statement, а сделали это на уровне сессии (процесса), сразу выделяя под него место на старте процесса. Мало того что это оверхэд на подготовку запроса, так еще оно и памяти немало ест когда сессий много. Возможно, если у вас так много сессий, поможет уменьшение размера этого кэша (хотя решение довольно спорное, надо смотреть по ситуации)
Отчасти это "заслуга" академического прошлого базы, пошедшей от проекта университета Беркли, как написали выше, а отчасти от Unix way. Когда я первый раз узнал, что каждая таблица в PG это 3-5 файлов (Карл!), после оракл где все таблицы можно упаковать в 1 файл и настроить их так, чтоб фрагментация была минимальна, у меня глаза на лоб полезли. Понятно, что сейчас в SSD разница в доступе сильно нивелировалась, но раньше на хардах, это ж какой ад наверное был!
Примерно то же самое с настройками - база из коробки преднастроена так, чтобы запуститься на любом тапке, ни о какой производительности речь совершенно не идет, когда ставят такую цель. И да, много чего надо покрутить в конфиге, чтоб оно нормально заработало
Мне было интересно в неё возюкаться в самом начале - ничего не понятно, НО ВСЁ ТАК ИНТЕРЕСНО. Специально не смотрел/не читал гайдов, чтобы на своем опыте до всего дойти, строил и перестраивал жуткие спагетти в рамках прототипов, костылил все это. Потом немного с чем-то разобрался, понял как надо, перезапустил заново и на каком-то этапе вдруг понял что всё превращается в рутину. Прикинул сколько еще масштабировать всё это и затосковал...
В разработке так же - кому-то нравиться исследовать, кому-то писать идеальный код. Мне и в разработке интересней разбираться с непонятной хренью,10 раз переписывать прототипы/тесты. А потом когда разобрался, сказать "народ, я понял как надо - вот так и так, если что обращайтесь, подскажу, а мне вон с той непонятной хренью надо разбираться".
(Ворчливо) Какое-такое спагетти? Это прототип! :)
Нет-нет, вы неправы - все знают, что у каждого ИТ-шника есть хобби. Пусть будет, ммм... скажем выпечка хлеба - я видел тут статью (даже переиздавалась!), и, судя по комментариям, все увлекаются выпечкой хлеба. Тогда надо ехать во Францию - судя по интернету, там все непрерывно едят багеты, успех будет оглушительным!
ЗЫ: Это шутка с отсылкой к одной легендарной статье, а то тут иногда проблемы с детектированием юмора.
Полностью согласен. Тем более что местное сообщество за версту чует, и на дух не переваривает, всё это вот копирайтерство. А сейчас еще и в использовании нейросеток обвинят.
А вот статья про про БС-ку (базовую станцию, комментарий для стороннего читателя), Вам наверно будет интересна - она тоже попала под каток копирайтера, но для связиста там много интересной информации закопанной в словоблудстве. Второй раз даже не рискну оставить ссылку, если сами не найдёте, стучитесь в личку. Кратко - все производители в основном в хард - антенны, усилители, а мы в софт. Риалтаймовую обработку на SDR для кучи подключенных терминалов сделать тяжело, но прототипы в 5G обкатывать можно
Перечитал свою (изначально) статью по ссылке - она не просто пресная и формалистская. Она просто чудовищна языком и пропусками логики повествования, да и просто слов в предложениях. С корректурой вот этого корпоративно-бодрого стиля я не справился от слова совсем.
Сейчас улыбает бодрое "мы". Разрабатывал это я один. Сначала, когда делал кучу синтетических тестов на утечки памяти, допустимые объемы данных передаваемых по DCOM по сети (ну шутка ли, 100 мегабайт в пакете :) помощники были не нужны. Потом долго рефакторил клиент-серверную архитектуру в серверный монолит, по пути пытаясь оптимизировать огромное накопившееся легаси. Потом стали понятны затыки архитектуры и как ее разнести по сервисам (хочешь сделать хорошо - сделай сам (с)). Только после этого стали нужны помощники, но уже и ресурсов нет, да и работа, считай, сделана. Угу, потом еще год допиливал в промышленной эксплуатации.
Так что статья только любителям подробностей странных решений странных систем...
Попробую написать про то, как мы в ситуации когда память есть, а проца и ввода/вывода мало, пытались сделать в рамках базы свой наколеночный in-memory кэш для часто используемых данных а-ля стоимости услуг для тарифного плана.
На первый взгляд там классическое key-value хранилище, но нюансы ТЗ превратили всё это в олимпиадную задачу, над которой бились много лет сменяя подходы с наивных до изощренных, и что из того что не написано в документации превращало в прах наши многочисленные попытки оптимизировать получение данных из простой казалось бы функции, таскающей данные из почти простой таблицы.
Была одна статья, не сочтите за рекламу, сам еле ссылку нашел.
Предыстория: когда-то наша компания решила вести блог на Хабре, и маркетолог попросил нас накидать идей для интересных статей, а потом и сами статьи. Накидать-то легко в таком стиле что выше. Но, я убил, наверное, неделю на редактуру, чтобы все причесать и привести в порядок поток мыслей. Потом статья попала к копирайтеру, который переписал всё более легким языком, заодно сильно сгладив углы. Конечно, советуясь со мной и присылая бесконечные ревизии текста. Фактологические ошибки или неточности формулировок я старался править, но на каком-то этапе понял, что этот бесконечный agile цикл надо завершать, уже сил нет ни вычитывать, ни в надцатый раз объяснять свою корректуру.
В результате получилось, на мой взгляд, довольно пресно и язык немного канцелярский.
Вот собственно сама статья: Система массовой печати в биллинге, или красивые решения скучных задач (ч.1) / Хабр (habr.com)
Еще раз, ни разу ни реклама, и на мой взгляд подача откровенно слабая и сумбурная
Спасибо за ностальгическую статью, всколыхнула мои воспоминания, связанные с телекомом.
Я правда не связист, а разработчик, занимающийся большей частью базами данных (но в то время четкого деления не было, занимались всем, что потребуется)
Казань, двухтысячный год, я год как закончил КАИ, практику проходил в Татэнерго, и туда же устроился работать, т.к. там уже были свои спецы по Oracle, а тут еще присоединилась команда из банка, у которой было чему поучиться. Платили совсем копейки, но уму-разуму учили хорошо. Например, прихожу к человеку с вопросом – вот написал хранимку, а отладить не могу, на третьей итерации цикла отладчик падает вместе с сессией (оракл, кажется, был 7 версии, там все было грустно). Мне сразу вопрос – зачем тебе отладчик, главный отладчик — это голова, где у тебя программа с такой ошибкой может упасть? Ну вот наверно тут и тут… При каких условиях? Ну наверно если так… Вот и вставь туда вывод этих значений, посмотри, что ты туда приходишь и какие там данные… Отладчики давно уже работают как надо, но зачем, и так примерно понятно при какой ошибке что где могло пойти не так, максимум вывести отладочные данные.
Потом команда уходит из Татэнерго и там становится кисло. Параллельно общаюсь с друзьями, которые еще студенты, но работают в первом GSM операторе Татарстана «Сантел». В то время у нас есть DAMPS оператор Татинком и какой-то малораспространенный CDMA. На их фоне Сантел выглядит как гаражный стартап – наняли студентов, они пилят самописный биллинг. И вот я друзьям рассказываю тонкости Оракл, они мне про интересные проектные решения типа трехзвенки (тогда все двузвенку пилили). И, когда из Татэнерго уходит последний человек у которого имело смысл учиться, положил заявление на стол, пошел в телеком, благо занимался примерно тем же – разрабатывал биллинговую систему для теплоэнергетиков (ага, в однеху, начинал еще студентом в качестве диплома и тянул разработку 2 года, понятно что было маленько выгорание :).
Поначалу платили хоть и в 2 раза больше, чем на предыдущем месте, но ничего фантастического, плюс работы было очень сильно больше – отдыхать в субботу скорее исключение, чем правило. Биллинг уже более-менее работал, но первый год мы его яростно дорабатывали под новые идеи маркетологов и появляющиеся на ходу требования. Потом абонентов стало больше, серверное железо тянуло все это с большим трудом, доходило до того что 24 часа CDR-ок (тарификационных записей с коммутатора) обсчитывались 23 часа – чуть просядем и перестанем успевать тарифицировать, и мы около года оптимизировали тарификацию, попутно служебкми закидывая начальство, что нужно новое железо и хорошо бы резервное еще (ага, самый дорогой по тарифам оператор работал без резерва и бакапа). Потом рассыпался RAID-массив, казалось что все, можно лавочку закрывать, 2 недели спец из Москвы колупал диски массива в бинарном редакторе, тарификация стояла. Когда подняли массив еще месяц, наверное, нагоняли. Наконец пришел новый сервер, в котором было куда больше ядер чем в прежнем, выдохнули ненадолго. Но абонентская база перла как ненормальная. С одной стороны хорошо – первое время за каждые 10 тысяч абонов премию давали, с другой непрерывное повышение нагрузки (а с удешевлением тарифов абоны еще и траффика генерировали все больше) И выяснилось что теперь мы упираемся не в процессор, а уже в диски – запущенные параллельно тарификаторы упираются в горячие блоки индексов - перестраивали их с новыми параметрами, на больших таблицах процесс долгий и (в той версии) требовавший эксклюзивной блокировки таблицы, что лочило работу системы. Дальше выяснилось, что мы далеко не все изначально партиционировали, что надо было. Систему надолго останавливать нельзя, а расчетное время работ на создать новую версию таблицы около полусуток. Создавали новую версию таблицы не останавливая систему и потихоньку переливали архивные данные, создавали все индексы, потом стопали систему, переименовывали старую/новую таблицы и по-быстрому доливали свежие данные.
Дальше маленького (не очень), но гордого оператора выкупает красный федеральный (тогда еще без яйцеобразного логотипа), и поскольку у него гора региональных операторов с зоопарком биллингов, начинает консолидацию их в один свой. Все доработки замораживаются, т.к. мы внедряем новые фичи быстрее, чем они успевают запилить их у себя, несколько лет ведут разработку, мы неторопливо готовим скрипты выгрузки для их биллинга и, поскольку нам скучно, параллельно разрабатываем и внедряем новую версию биллинга уже для местного городского проводного/интернетного оператора, а потом и для оператора ТВ. Потом начинается оптимизация и мы уходим в небольшую компанию, которая продолжает развивать и поддерживать новые версии для этих операторов, а красные федералы от техподдержки отказываются и тащат всою версию сами, т.к. всех смигрить так и не смогли. Ирония в том, что по прошествии годов команда разработки у красных многократно сменилась и утеряла компетенции по поддержки этого по нынешним временам махрового легаси. Так что мы опять выполняем функцию поддержки этой самой старой версии системы, творчески доработанной многими поколениями команды красных. Около 90% ошибок связаны с этими доработками, и это отдельный скил разобраться в чужом странном коде, который ты видишь первый раз – отрефакторить что он делает, что разрабы имели ввиду, что пошло не так и как это исправить корректировкой данных или кода.
Ух, Остапа понесло, извините за стену текста.
Не взлетит, мысли инвестора в пассивный доход: "А зачем такие процессы автоматизировать? Я и сам в будке посижу,
помну сиськипомаммографирую" :))))