На 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 строк сократилось с двух часов до трёх минут.

Не любите симбиоз IBM DB2 и мягкой, жёлтой, твоей? Вы просто не пробовали, тем более что попробовать можно бесплатно и у DB2 даже специальный режим работы для неё есть. Другое дело, что для жёлтенькой программы даже суперсовременного, но одного ядра и одного запущенного процессора на сервере маловато. Но мы же не сдаёмся?

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

Засада первая: «бесплатный» DB2 не жуёт больше двух гигабайтов памяти. Достаём лицуху, которая уже жуёт 32 гига, скармливаем, настойчиво заставляем её использовать не более 16, а не «авто», как по умолчанию. База залетала, но всё равно, маловато одного серверного процесса на всех будет! Бежим к своим суппортерам: да, хотим серверную лицуху нашей жёлтой, нет, с ума не сошли, да, знаем ваши цены, знаем, что вы скоро ценник ещё задерёте. Купили, воткнули, прочитали, что сетевые интерфейсы и количество памяти уменьшать нельзя, иначе активация слетит. Втольковываем, что если на сервер вошла Марьиванна, то запусти ты, умная железяка, ещё один процесс серверный, и пусть он её и обслуживает, а если зайдёт ещё Ольпетровна (которая одной кнопкой «Сделай мне хорошо» выставляет очень большое количество счетов), то и ещё один. В общем, не стесняйся, ядер у процессора много, гипертрединг выключен, дабы не смущать, больше четырёх человек — запускай ещё один. Возможностей встроенного контроллера хватает, RAID 10 на восьми дисках, состояние системы контролируется фирменными же тулзами с Service Pack DVD, если что — тут же админам письмо. Суппорт вендора привезёт запчасть максимум на третий день: железки-то заранее предупреждают, что плохо им, вежливые все, брендовые. А тут ещё и бэкапы можно делать, не выгоняя всех из программы, и их целостность потом в фоне проверить, не запуская жёлтенькую… Красота, все счастливы, Марьиванны довольны: им не надо думать, какую пакость админ в следующий раз подложит, они «свои» деньги вложили и видят отдачу.

Резюме: жизнь налаживается, если знаешь как. Другой вопрос — это ж ковыряться надо, а фирменные «жёлтые» админовские курсы в этом вопросе мало помогают. Плавали, знаем…

В то время как другие, пытаясь увидеть инфу S.M.A.R.T. с дисков в рейде, бегают по сайтам вендоров контроллера и дисков, выцарапывают где-то SNMP MIB от производителя матери, чтобы следить за датчиками, потом собирают это всё в кучу скриптами, чтобы Nagios вовремя или хотя бы уже постфактум что-то пискнул… Не будем ломать им кайф.

У нас есть партнёр. У партнёра есть база, в которую можно заносить данные через специального клиента (с локальной базой) или через веб-интерфейс. Это порождает кучу проблем, но… «отлито из бронзы, руками не трогать». Записи, сделанные через клиента, нумеруются с единицы, а через веб-интерфейс — с шестидесяти. Те, кто плотно работает с этой системой, уже привыкли и научились отслеживать проблемы, вызванные «шестидесятыми» записями. Существуют и несколько автоматических отчётов и рассылок на тему «подозрительные шестидесятые».

В прошлый понедельник один не очень внимательный товарищ отправил по офису письмо с заголовком: «Список проводок из шестидесятых, которые вызовут проблему с налоговой». Это письмо увидел главбосс и поинтересовался: а с чего это вдруг у нас в базе есть проводки из 60-х, если наша контора была организована только в 2002-м?

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

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

Логика заказчика: «Я хотел, чтобы товары попали именно в эту группу, так как именно её я и обновлял».

Логика системы: поскольку группа теперь не в корне, то нужно перенести её из корня. Группа становится подгруппой внутри несуществующей себя.

Похоже, у Уробороса всё-таки получилось себя съесть!

Собрал в свободное время небольшую коллекцию приколов со своей работы.

Задание — добавить пункт: «Нужна ли вам рассылка?». Три варианта ответов: «да», «нет», «совсем не нужна». Оказалось, различие между последними двумя в дополнительных типах уведомлений.

* * *

— Почему база висит? SELECT … FROM … Чей это запрос может быть?

— Это, наверно, Лена.

— Я её прибью! Вернее, процесс её прибью.

* * *

Приняли нового человека. Ну вот как так можно написать:

$month_id = array(1, 2, 3, … 12);

$month_name = array('Январь', 'Февраль', …);

Да-да, потом идёт foreach($month_id as $n) и обращение к $month_name[$n-1].

* * *

В середине выполнения программы:

$_POST = array(…);

Вызвали функцию, возвращаемся — и программа уже не знает, кто она и что хотела сделать.

* * *

> SELECT DISTINCT gender FROM clients;

Found rows: 150

В том числе «8912», «Зао"Урал», «хозяйка», «юр.лицо».

* * *

Номер недели в году. Этого я вообще не ожидал:

> SELECT DISTINCT publish_week FROM table;

Found rows: 88

Сентябрь. Компания решает внедрить у себя CRM-систему.

Октябрь. Обсуждение ТЗ, договор, оплата.

Ноябрь. Установка системы, настройка базы под компанию, ввод начальных данных.

Декабрь. Обучение пользователей, настройка интеграции с другими программами, прогонка тестов и кейсов, пробная работа. Система готова, запускаем с начала года.

Первый день нового года. Ничего не работает. Местный сисадмин где-то в Таиландах вне зоны доступа. Внедренцы (реально умеющие работать только по мануалам) выясняют, что сервера работают, но что-то с базой SQL: у неё какой-то странный статус, но что с этим делать, они не знают. Окей, подключаюсь удалённо через Ammyy (внедрение в другом городе), смотрю. Пути к базе ведут не в стандартный каталог, а на отсутствующий в системе диск. Закрадываются странные сомнения. Опрашиваю, насколько возможно, нет ли где-то в серверной отключённого внешнего диска, флешки…

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

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

Увиденное повергло меня в шок. Транзакции, триггеры, процедуры, составные индексы, встроенный язык программирования — вот чего там нет. Мощнейшая БД используется как простое хранилище. Эту бы программу да на MongoDB, ибо большего не надо, хотя даже Mongo будет многовато при таком обращении с данными.

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

Много байтов здесь пролито об известной жёлтой программе. Сейчас я поведаю прохладную историю про их сервер под линукс.

Под линём шайтан-программа работает под PostgreSQL, любезно пропатченной самой конторой. Волшебно! Есть RPM, DEB, SRC. Хорошо, думаю, мужики поработали. Поставил, быстренько настроил — полетело! Наивный маленький админёнок. Postgre при установке DEB x64 стал ругаться на то, что он скомпилён без использования формата дат в 64-разрядном виде, а у меня (внезапно, откуда бы им взяться в Debian 7 x64) они есть. Вздохнул, скачал исходники официальной Postgre с патчами, сконфигурил с поддержкой этого самого формата, накатил патчи, компилю. А дальше всё как из широко известного в узких кругах произведения:

— Ошибка! Попытка деления на букву О!

Доморощенные программеры забыли объявить класс. Я далёк от программерства и ничего сложнее bash-скрипта написать не могу, посему пошёл курить форумы. Оказалось, что этой проблеме уже n + 1 лет, и до сих пор никто даже не почесался её исправить. Хорошо, правлю указанные файлы, компилю, ставлю.

/etc/init.d/postgresql start. «No such a file or directory», — молвит мне Дебиан. Эм, простите, что? Лезу в каталог и не нахожу абсолютно ничего похожего на скрипт запуска. Прифигеваю, пишу этот самый скрипт и прописываю его в автозагрузку. Причём я точно знаю, что постгрешка из репозитория имеет этот самый скрипт. Запуск показал, что дефолтных конфигов тоже не завезли. Нахожу дефолтные конфиги, правлю их — вроде взлетает. Ставлю сам сервак. Он даже поставился из бинарников! Вот это прогресс, вот это инновации! Запускаю скрипт настройки сервера — и снова:

— Ошибка! Попытка деления на букву О!

Угу, в скрипте пропущены кавычки. Ради смеха иду читать древность сей ошибки — и что бы вы думали? Да, ей ровно столько же лет, n + 1. Запускаю скрипт снова. Он говорит, что я не поставил такие-то зависимости. Эм, да? Вроде ставил, склероз замучил? Нет, Aptitude уверяет меня, что с головой у меня всё в порядке. Ага, шайтан-программа под линукс не понимает линуксового разделителя в виде двоеточия в пути к библиотекам! Делаем сотни симлинков, указываем ему одну директорию. Ох, неужели, он взлетел! Дальнейшие пытки расписывать не буду — это уже чисто мои косяки.

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