Базы данных

Пословицу «Семь бед — один ресет» я услышал, когда был ещё мало разбирающимся в компьютерах подростком. Она стала для меня своего рода аксиомой, ведь во времена Windows ME, XP без сервис-паков и Vista (особенно когда она была ещё только «Лонгхорном») тормоза и зависания и так не слишком сильной машинки легче всего решались именно нажатием на эту волшебную кнопку, а потеря данных обычно сводилась к 15–20 минутам несохранённой игры.

Чуть позже, когда я уже собирал и разбирал компьютер на время, а установка системы стала простым и понятным процессом, к панацеям была с лёгкой руки записана полная переустановка ОС. Ведь если запорол что-то кривыми драйверами или удалил какой-то «неоправданно большой» файл с такого маленького раздела С:, то вместо того, чтобы долго искать решение проблемы (а Гугл тогда ещё не был таким всезнающим, как сегодня), можно было за час по накатанной процедуре полностью переустановить систему. Опять-таки, потеря данных тогда была минимальной, ведь всегда был раздел D:, на котором хранилось «самое важное».

Уже когда я был начинающим айтишником, мне быстро и доходчиво объяснили, что необоснованный ресет компьютера в бухгалтерии может закончиться истерикой и выговором со штрафом, а система, полеченная от знакомой болячки через Safe Mode, а не переустановкой, экономит очень много времени и усилий по восстановлению очень древнего и уже не поддерживаемого, но такого необходимого софта. Именно тогда я раз и навсегда решил, что радикальные методы — это не наше и использовать их можно только в самом крайнем случае.

Сейчас я работаю в компании, которая пишет очень специфический софт для очень специфических клиентов с базой данных на основе PostgreSQL. Так как и софт и клиенты специфические, то в каждую конкретную БД могут вноситься точечные изменения по просьбе клиента. Все изменения документируются и учитываются в последующих патчах. Я работаю в команде, отвечающей за установку и обновления, а также решение внезапных проблем, но у каждого региона есть команда техников, которые должны решать мелкие проблемы самостоятельно и передавать нам то, что решить уже не в состоянии.

Это всё была присказка, а сказка начинается скорее как анекдот.

Итак, встретились как-то раз индус и русский. Индус должен был тестировать новую версию софта перед обновлением, а русский по мере возможности помогать. Звонят они как-то и говорят: так и так, есть проблема, программа не поднимается, выдаёт кучу ошибок, всю голову уже сломали, но понять ничего не можем.

Так как эту конкретную систему ставил и базово проверял я сам, то сразу почуял неладное. Лезу в систему — правда не поднимается, в логах полная истерика, ошибок столько, что читать сложно, но через какое-то время понимаю, что всё сводится к чтению данных из БД. Лезу в БД, первым делом проверяю версию и наличие хоть каких-то данных. Версия правильная, записи существуют, тогда почему же оно не работает? На всякий случай проверяю, когда установлена БД. Так, что значит три дня назад? Я ж систему на проверку уже две недели как передал!

Спрашиваю у русского, что делали с системой. Он говорит, что ничего особенного не делали, всё по инструкциям. На прямой вопрос отвечает: да, три дня назад восстанавливал базу по просьбе индуса, потому что были проблемы.

Спрашиваю индуса, что делал. Говорит, что начал тестировать систему, но некоторые конфигурации через клиент у него «по-старому» не вносились, поэтому он их сделал напрямую через БД. Ясно, через клиент срабатывала «защита от дурака», но так как текст ошибки читать недосуг, то этот самый дурак кривые параметры запихал в БД напрямую, потому что там такой защиты нет.

Идём опять к русскому — сначала DROP DATABASE, потом CREATE DATABASE по новой схеме и затем pg_restore на всякий случай с флагом -c, чтобы быстрее. Откуда бэкап взял? Ну так вот же он. Фух, теперь всё ясно: бэкап брался с живой системы, со старой версии БД. Естественно, на новую схему восстановился он криво, а логи читать — это не для нас, система-то тестовая все равно.

Ладно, восстанавливаем старую базу со старой схемой, патчим до новой версии, проверяем систему. Два имейла — и волшебные пендели и индусу, и русскому обеспечены. Чёрт, как так рабочий день закончился? Я ж сегодня ничего не успел… Ясно, опять из дома на выходных работать.

Ребят, честное слово, пословица «Семь раз отмерь, один раз отрежь» намного умнее. Лучше сначала инструкции перечитайте или спросите. Радикальные методы — это не наше, правда-правда.

По работе потребовалось вспомнить SQL-транзакции. Вечером пришёл в магазин за продуктами домой. Там случилась полукомичная ситуация, когда человек с наполненной корзинкой передо мной вдруг не обнаружил денег в огромном кошельке и побежал домой, наказав кассиру беречь продукты. Но на кассе после этого потребовалось делать обнуление. «Странно, — подумал я. — Нет бы просто откатить транзакцию и сделать так, чтоб завершалась успешно она только по оплате! Тогда не придётся делать лишних телодвижений по сторнированию». Кассиру, конечно, этого объяснять не стал, терпеливо подождал, пока девушка с помощью старшей коллеги не разобралась с терминалом.

Но, дорогие коллеги, разработчики ПО для касс — задумайтесь.

Вскоре после окончания вуза устроился я в информационно-аналитическую контору. Начальство озадачилось внедрением системы сбора и обработки информации, призванной увеличить производительность труда и расширить спектр выходной продукции. От системы требовалось обеспечить сбор информации из интернета, электронных и печатных документов, осуществить их классификацию, кластеризацию и тегирование, отобразить результаты работы в веб-интерфейсе с возможностью выгрузки результатов в файлы.

Разработку и внедрение системы поручили фирме-подрядчику, начальство которой было хорошо знакомо с моим руководством. Два года длилась эпопея с разработкой и установкой программно-аппаратного комплекса. В день приёмки присутствовало высокое начальство с обеих сторон и несколько специалистов со стороны заказчика, осуществлявших тестовую эксплуатацию. Специалисты отказывались подписывать что-либо, утверждали, что система сырая и недоработанная, начальство подрядчика божилось устранить все нарекания в ходе эксплуатации, начальство заказчика ругалось на специалистов, обвиняло их в ребячестве и грозило лишениями премий за срыв приёмки, в результате чего система со скрипом была принята.

Как вы уже, наверное, догадались, после сдачи проекта никакие недостатки устранены не были, представители подрядчика имитировали бурную деятельность: приезжали, слушали жалобы, кивали головами, обещали всё исправить, но ничего не делали. Начальство заказчика ругалось на своих специалистов, почему до сих пор не видно результатов от внедрения новой дорогой системы, специалисты бегали все в мыле и пытались хоть что-то наладить.

Понемногу страсти улеглись, про систему почти забыли, перейдя на самописные костыли, но аппаратно-программный комплекс продолжал «работать» вхолостую, ведь деньги уже уплачены, а техника и ПО на гарантии — сносить ничего нельзя. И решил я как-то ради интереса поглядеть, ради чего был весь этот сыр-бор и почему это всё не используется.

В общем, заканчиваю с затянувшимся вступлением и перехожу непосредственно к описанию этого чудо-комплекса.

Комплекс состоял приблизительно из десятка серверов, каждый из которых был заточен под решение конкретной задачи: один сервер БД, один сервер управления поисковыми роботами, один сервер, собственно, этих роботов, один сервер обработки, один сервер распознавания текста, один сервер веб-интерфейса и ещё разные серверы. Все машины на момент установки уже устарели на два-три года, не отличались большой мощностью, имели оперативную память от 8 до 12 ГБ, что выглядело немного странно, учитывая наличие двух процессоров Xeon в каждом. При грамотном использовании ресурсов весь этот комплекс, в принципе, обладал бы очень неплохой вычислительной мощностью. Однако логика разработчиков, видимо, была проста: одна задача — один сервер, и неважно, что часть задач выполняется последовательно, и большую часть времени половина серверов простаивает, а вторая половина трудится на 5–10% мощности. Сервер распознавания текста вообще не использовался: Файнридер был на каждой клиентской машине.

Программная часть вообще заслуживает целого тома описаний багов и недоработок. Остановлюсь на самых ярких из них.

Подсистема сбора состоит из диспетчера и роботов. Роботы, как я уже говорил, находятся на одном сервере, диспетчер на другом, общаются они друг с другом при помощи таблички в базе данных, развёрнутой на сервере диспетчера. В диспетчере создаются новые задания на загрузку и кладутся в табличку, откуда потом их берут роботы. При этом обратной связи от роботов к диспетчеру не существует, то есть в случае сбоя узнать об этом можно, только зайдя непосредственно на сервер роботов или в следующем месяце, когда в статистике загрузок пойдут нули.

Данные для отображения в веб-интерфейсе диспетчера хранятся в отдельных таблицах БД. При любом действии в интерфейсе вызывается каскад T-SQL-запросов, который вносит изменения в основную базу, пересчитывает таблицы для отображения и потом запрашивает данные. В процессе работы размер таблиц растёт, время выполнения запросов увеличивается, и оператор, слишком быстро нажав пару кнопок, легко и непринуждённо может вызвать блокировку БД, приводящую к падению диспетчера и веб-интерфейса.

Сами роботы тоже гениальны в своей недоработанности. Задания на загрузку представляют собой ссылку на сайт и набор регулярных выражений для разбора страниц, при этом задания, вбитые при сдаче в эксплуатацию, настолько кривы, что перестают работать, если в блоке текста появится перенос строки вида <br>. На соответствующем сервере крутится несколько инстансов процесса, каждый инстанс независимо друг от друга периодически проверяет таблицу заданий и берёт себе задание, чьё время подошло по графику, при этом ставя таймстемп о последнем выполнении, чтобы другие роботы не пошли его выполнять по новой. Если в процессе загрузки сайта происходит таймаут или какой иной сбой, робот выкидывает эксепшн и уходит в лучший мир, никого об этом не оповестив, и в результате остаётся на один процесс меньше. Если до следующего по графику выполнения сайт по-прежнему недоступен, то же повторяется со следующим роботом, и так до тех пор, пока не кончатся роботы.

Но даже если все сайты работают стабильно, роботы умрут через два-три дня, потому что они не умеют удалять из памяти ненужные больше данные и с каждым запуском отъедают всё больше и больше памяти, что в итоге приводит к их массовому самоубийству через сообщение «системе не хватает ресурсов».

Ах да, забыл сказать: на сервере диспетчера установлена 32-битная Windows XP. Это при двухпроцессорной-то архитектуре и 12 гигах памяти.

Допустим, что данные собраны успешно и легли в соответствующие таблицы MS SQL, далее их надо передать в подсистему обработки. Что тут сложного, спросите вы? А сложно то, что подсистема обработки — это крайне устаревшая проприетарная система с поисковым движком в ядре, работающая на PostgreSQL. То есть данные нужно экспортировать из одной базы в другую. Как же это рациональнее всего сделать? Конечно, сделать передачу по расписанию, которая, дабы днём не снижать производительность сервера обработки, будет каждый день в 00:00 перекидывать накопленный массив данных. Что мы получаем в итоге? Система обработки пыхтит ночь напролёт, индексируя и анализируя полученный одномоментно массив данных, пользователи получают результаты с задержкой в один день, зато сервер обработки днём совершенно разгружен и готов к выполнению работы. Вот только какой?

Далее встаёт проблема классифицировать входной поток и раскидать его по рубрикам. Соответственно, систему надо обучить, по каким критериям проводить эту классификацию. Машинное обучение, обучающая выборка, статистика часто упоминаемых слов и выражений, методы обработки естественного языка? Нет, не слышали. Вместо этого оператору предоставляется уникальная возможность полностью вручную создать классификаторы, используя для этого встроенный редактор поисковых запросов с использованием операторов И, ИЛИ, НЕ; как бонус — задать допустимое расстояние между словами.

Опять же, допустим, что всё получилось и работает нормально. Пользователь зашёл на веб-интерфейс программы обработки, отобрал нужные ему документы и хочет их себе сохранить для дальнейшей работы. Не тут-то было! Экспорт осуществляется в формате либо XML, либо XLS, при этом в экспорте не учитывается информация о рубриках, тексты лишаются намёков на форматирование, получить документ в оригинальном виде просто невозможно, хотя в базе он есть…

В общем, весь этот комплекс можно было довести до ума, обвешав по самое не балуй костылями, игнорировать большинство косячных встроенных функций, забирать данные из баз напрямую сторонними средствами, но весь этот зоопарк потребовал бы колоссальных усилий на поддержание в работоспособном виде и изменение каких-либо параметров. И что мы имеем в итоге? Дорогущая система стоимостью в несколько миллионов, развёрнутая на морально устаревшем в момент приобретения железе, разнородное ПО, скреплённое ржавыми гвоздями и неспособное работать в комплексе более пары дней, один уволившийся программист, психанувший после долгих попыток заставить всё это работать, — и ни одного дня использования этой системы по назначению вплоть до дня официального окончания поддержки, когда выжившие специалисты со скупыми мужскими слезами радости наконец удалили весь этот кошмар и развернули на серверах аналогичное самописное ПО с использованием опенсорса, возможно, тоже в чём-то глючное и несовершенное, но так хорошо справлявшееся с поставленными задачами, ютясь на обычных рабочих станциях, используемых вместо серверов!

А что начальство? А начальство уже заказало той же фирме разработку и внедрение новой системы на смену безвременно скончавшейся. Только, чувствую, в этот раз приёмка не состоится, если только не уволят всех несогласных…

Занимаюсь поддержкой и доработкой модуля CRM биллинговой системы. По функциональности очень жирный модуль: около 200 визуальных форм, по сути, одно из основных рабочих мест биллинговой системы.

Разработка начиналась около 15 лет назад на средстве разработки, столь популярном тогда на территории экс-СССР, названном в честь древнегреческого города. Тогда это был передовой край IT — визуальное средство позволяло быстро и качественно рисовать пользовательский интерфейс. А архитектура этого средства позволяла дорабатывать стандартные компоненты и классы, разрабатывать свои собственные или использовать сторонние, что повышало качество и привлекательность создаваемого программного продукта.

В отличии от маститых конкурентов, имевших тяжкий груз наследия старого кода, разрабатывали уже трёхзвенную архитектуру, чем немало гордились. Вот, мол, у них надо драйвера базы ставить (драйвера Оracle поставить и настроить — это довольно муторно, если рабочих мест за сотню с лишним), кому-то ещё фреймворк для работы клиента, а у нас тонкий клиент: создал ярлык на экзешник с файл-сервера, и уже всё работает. Конкуренты апеллировали, что клиентские места надо создавать в средствах разработки, которые заточены для работы с БД и прям со структуры базы сами рисуют пользовательский интерфейс (страшный и кривой, зато возиться не надо), а не на вашем комбайне, на котором только утилитки десктопные строгать.

Прошло пяток лет, и тонким клиентом стал считаться веб-браузер. В те годы они, конечно, мало что умели и годились для ввода пары строчек в простейшей форме редактирования или отображения не слишком большой таблицы (какие сортировки/фильтрации/группировки — забудьте!). Конкуренты, вышедшие на рынок после нас, потешались над нами за отсталость технологий, мы над ними — за убогость интерфейса.

И вот развитие веб-технологий позволяет нарисовать интерфейс, неотличимый от нативного, а средства разработки позволяют нарисовать его комфортно. Вот только браузер с открытой почтой, новостным сайтом и этой страничкой ест оперативы столько же, сколько сервер приложений с полутысячей активных пользователей, и в пять раз больше клиента, в котором загружен список под сотню тысяч записей (раз клиент хочет себя мучить такими списками, то проще сделать, чем спорить).

Да, у нас разрабатываются небольшие специализированные рабочие места на веб-технологиях (зачастую с бо́льшими трудозатратами, чем потребовались бы для реализации того же на древнем, но удобном средстве разработки), но переписывать огромный продукт, понимая при этом, что это не только потребует совсем других ресурсов и от сервера приложений, и от клиентских мест, но ещё и ограничит функциональность… Мы это время лучше потратим на развитие системы, а я своё свободное рабочее время — на изучение фич новой версии БД, название которой некоторым образом ассоциируется с описанной средой разработки. Всё-таки основная моя специализация — разработка БД.

К чему это я? Да все к тому же баяну, повторяемому тут на каждой странице: холивар вечен и повторяется на каждом витке развития технологий. А каждой технологии своё место и своё применение.

Я не айтишник: не сисадмин, не программист, не инженер. Я занимаюсь наружной рекламой — вывески и всё такое. К компу я и близко не подходил уже года два, но во время о́но довелось мне работать скромным наборщиком объявлений в известной в нашем городе редакции.

Там был IT-отдел, имевший три самописные БД для разных изданий, отдельную БД под клиентов и никак не связанную с ними БД (1С? Не, не слышали) для бухов. Естественно, стыковалось всё это добро такими окольными путями, что и представить сложно.

Для начала меня жутко задолбало отсутствие табуляции в форме набора объявления — на каждое следующее поле приходилось тыкать мышью. Попросил айтишных бойцов сделать. Через неделю получил искомое и научил весь отдел наборщиков пользоваться табом. Потом меня достало то, что наиболее часто встречающиеся слова приходилось вбивать полностью. Была придумана система автозамены сокращений на полные слова, причём автозамена срабатывала на пробел — не надо было жать какие-то комбинации клавиш. Снова поход к айтишникам, удивлённые лица (парень, ты откуда такой умник свалился?!), через неделю реализовано. Опять обучил отдел, включая начальницу, повесил список сокращений на стенку. Всем стало хорошо, а через месяц выяснилось, что производительность отдела набора выросла втрое.

Потом был корпоратив, на котором я перезнакомился с нашими менеджерами по продажам, нажрался и узнал много нового и нелестного об их работе. Снова пошёл к айтишникам. Действия менеджера по продаже в случае возникновения нового клиента: открыть базу, залогиниться, нажать кнопку «Новый клиент», вбить в окошечко ФИО, нажать «Далее», вбить телефон в следующее окошечко и так до бесконечности. Потом перекинуть эту инфу бухам в корпоративный чат: пусть они тоже мазохизмом занимаются.

У меня началась война с айтишниками: какого ты, всего лишь наборщик, лезешь к менеджерам, стоящим на две ступеньки выше в иерархии компании? Война продолжалась месяц и закончилась коллективным заявлением менеджеров об апгрейде баз данных.

Решением отца всея издательства я буквально поселился в отделе кодеров, по-прежнему получая жалкую зарплату наборщика, забыв вообще про объявления.

Итогом стало: объединение всех трёх БД изданий в одну и связка с бухами, интеграция клиентской БД в остальные базы, кардинальный рестайлинг интерфейса под менеджеров, бухов, наборщиков и дизайнеров, несколько скриптов, автоматом прикручивающих обработанные в Фотошопе фото к объявлениям, и множество других фишек, включая замену железа на более мощное и кучу всего другого.

Я просто сидел в отделе, пялясь в мониторы с сотнями строчек кода и ничего в этом не понимая, приставая с вопросами: «Как это будет выглядеть?» Новые сборки БД компилировались ежедневно по десятку раз. Я буквально задолбал айтишников.

Наконец был достигнут приемлемый результат. Спустя два месяца мне случайно попался на глаза финотчёт: доходы компании увеличились более чем в два раза. Я по-прежнему получал зарплату наборщика.

Я уволился, заявив, что сделал для компании больше, чем кто бы то ни было (а разве нет?), и попал в чёрный список работодателей. А через две недели меня разыскал начальник IT-отдела, вручил тысячу долларов и ящик пива со словами:

— Хорошо, что ты не айтишник!

Мораль сей басни такова: не стесняйтесь требовать чего-то у айтишников, если понимаете, что вам нужно для того, чтобы работать с большей эффективностью. Если ваши требования логичны и практичны, вам пойдут навстречу.

Уж сколько раз твердили миру: если вы не понимаете, почему программа написана именно так — возможно, проблема не в разработчике, а в том, что именно вы не понимаете, почему программа написана так.

Вот свежий пример: база данных сети магазинов с отделами. И начинается: хорошие и плохие преподаватели, нормальная форма, ненормальная форма, а почему не отдельная таблица, а почему не отдельные поля…

А вы точно разобрались, что именно должна хранить эта БД и как с ней работает софт?

Если вам преимущественно нужно делать выборку по одному отделу, потом по другому отделу, потом по третьему — логично, что тут удобнее список отделов и связка этого списка с таблицей, скажем, магазинов: это сокращает объём выборок. Наверняка именно так вас учили.

Если вам нужно делать одну большую выборку по магазинам и получить списки отделов в них, то удобнее забить отделы прямо в одну плоскую таблицу, чем вести ещё отдельно таблицу отделов и таблицу связок: это элементарно лишние операции поиска в тех таблицах. Вы же не делаете таблицу имён, таблицу фамилий и таблицу отчеств со всеми связками, а просто пишете: «Иванов Иван Иванович». И найти потом всех «Ивановых» тоже несложно будет, верно?

Почему не сделать отдельные поля? Да хотя бы потому, что добавить в строку ещё два отдела — задача элементарная, а вот добавить два новых поля, по две новых переменных для работы с ними во все функции и в интерфейс — это уже доработка ПО с потенциальным внесением новых глюков и багов, отладкой, тестированием, бюджетами и внедрением.

А вот если бы вам надо было хранить и получать организационную структуру магазинов — это могла бы быть вообще иерархия вложенных объектов в NoSQL-базе, от банальной LDAP до модной нынче MongoDB.

Всё зависит от того, какая задача стояла перед создателями базы.

Но вы не хотите вникать в какую-то там задачу. Вы же дипломированные специалисты, прослушавшие курсы лекций по нормализации, и бумажка об окончании есть, наверное. Вы знаете, как правильно, как неправильно, у вас огромный опыт в написании лабораторных, рефератов и сдаче зачётов.

Вот только вы, сами того не замечая, уподобляетесь тёткам — выпускницам «компьютерных курсов», которые раз и навсегда твёрдо запомнили: чтобы скопировать документ с диска на флешку, надо открыть его в Ворде и «сохранить как». Заодно вы убедитесь, что это именно тот документ, который нужно, и точно не ярлык, поэтому именно такой способ будет единственно верным, а все эти «перетаскивания файлов» или, ещё хуже, «синие панельки с текстом» — ересь и скверна, так делать нельзя, потому что это неправильно!

В доказательство тётка тоже может предъявить сертификат о прохождении курсов: у тебя, глупый админ, такого нет! И попробуй оспорь…

На IT happens было: «Преподавательница реляционных баз данных, при мне объяснявшая студенту, что таблица, распечатанная им непосредственно из Access, ну никоим образом не находится в первой нормальной форме».

Не буду спорить, насколько плоха преподавательница. Но разве таблица из СУБД может быть не в 1NF? Оказывается, может. И я это видел в живом проекте.

Большая американская сеть магазинов одежды. В магазинах есть отделы (три наименования). Любитель нормализации сделал бы список отделов и таблицу-связку. Пофигист обошёлся бы тремя полями: has_kids, has_plus, has_shoes. Эти сделали набор отделов строчкой: «Kids, Plus, Shoes».

Я работала в муниципальном учреждении, была Oracle DBA и вообще кем угодно, если это как-то отдалённо связано с компьютером (например, выбирала электронные весы).

В апреле нам разнесли уведомления о том, что с июня обрезают зарплату, поэтому я принялась усиленно искать другое место. Нашла, написала заявление об увольнении и принялась за поиски кого-нибудь вместо себя.

Зарегистрировала наше учреждение на всем известном сайте поиска работы, разместила вакансию «Администратор базы данных», где среди обязательных пунктов указала всего три: знание SQL, любого языка программирования и наличие средне-специального или высшего образования.

Первым откликнувшимся соискателем была девушка, к резюме которой было приложено фото, где она делает губки уточкой. Резюме называлось «Менеджер», среди ключевых навыков было указано «уверенный пользователь ПК». Образование — экономическое и соответствующий опыт работы. Это было даже забавно. Поначалу.

Затем появился следующий отклик. Девушка, которая до этого работала в стоматологии администратором на ресепшне, решила, что она легко сможет быть и администратором базы данных (ресепшн, база данных — какая разница?). С уверенными знания Excel, PowerPoint и образованием инженера-энергетика.

Потом было ещё несколько откликов таких же администраторов, менеджеров, мерчендайзеров, секретарей. Шутка стала какой-то бородатой и несмешной.

Среди всего этого разнообразия было только три более-менее адекватных отклика: от пенсионерки — программиста на 1С, от девушки с неоконченным высшим и юноши с запросом по зарплате втрое большим, чем было указано в нашей вакансии. Юноша даже приходил собеседоваться, но количество обязанностей с уровнем зарплаты никак не скоррелировало, и он отказался.

Между тем в дело вступила тяжёлая артиллерия. Наша специалистка по кадрам дала объявление в газету: «Требуется технический специалист». Нам стали звонить начинающие слесари и электрики. За одного юношу позвонила мама и слёзно просила прособеседовать сыночку. Деточке было 19, он окончил техникум и на мой вопрос о том, что он, собственно, знает и умеет, он ответил: «Word и Excel!»

В общем, я уже неделю работаю в другом месте, а замену мне так и не нашли. А я сделала для себя вывод: если нужен компьютерщик любой направленности — вакансию надо называть «программист». А 95% населения… ну, вы в курсе, да?

Я предпочитаю начинать решение проблем в программах с вопроса «а где я ошибся?», так как мой опыт показывает, что в большинстве случаев ошибка именно моя. Но иногда…

Случилось мне заниматься разработкой программного комплекса, один из компонентов которого вертелся в MySQL. При этом всю логику взаимодействия с БД я по возможности перенёс в хранимые процедуры внутри БД. Возникла необходимость оптимизации одной из хранимых процедур, которая при попытке всунуть в БД жалкие 10К строк зависала на два часа. Нужно было найти узкое место этой процедуры. Поиск «бутылочного горлышка» довольно прост: засекаем, сколько миллисекунд уходит на каждый шаг, смотрим, где проблема…

Проблема нашлась гораздо раньше: СУБД категорически отказалась выдавать нам информацию о миллисекундах. Даже под пытками. И даже с Гуглом. При этом информации в интернете было на удивление мало; у меня даже закралось страшное подозрение, которое со временем окрепло, что народ свои базы вообще не оптимизирует. В конце концов Гугл раскололся и выдал ссылку на точное описание проблемы… в багрепорте разработчиков. Читая добросовестное описание проблемы, я испытывал невероятное умиление: моя ситуация один в один! Сейчас дочитаю до ответа разрабов, пойму, где я дурак, всё сделаю как надо… Ответ разрабов был как ушат холодной воды: «Да. Такая проблема существует. MySQL не умеет возвращать миллисекунды».

Не было информации о том, что ведутся работы по устранению проблемы. Ни слово о том, что в версиях с xx.x.xx проблема решена. Просто признание, что жопа есть.

Произнеся приличествующие случаю слова скорби и смирения, я стал думать, как быть в данной ситуации.

На помощь мне пришёл метод Монте-Карло. В моём случае вероятность изменения значения секунды во время атомарной операции была пропорциональна количеству миллисекунд, на эту операцию затрачиваемых. Тут-то и пригодился ввод из 10К строк.

Не могу сказать, что найденное решение уникально. Но в процессе этой разработки я приобрёл полезный опыт, являющийся синтезом двух крылатых фраз: «жизнь — сука, никому нельзя верить» и «на хитрую задницу найдется хвост с винтом».

Кстати, в результате оптимизации я довольно много узнал о внутренней логике MySQL, встроенных в него инструментах отладки и оптимизации и всерьёз зауважал его разработчиков. Временные таблицы, индексы, JOIN вместо вложенных SELECT — и время внесения 10K строк сократилось с двух часов до трёх минут.