Базы данных

Не любите симбиоз 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 уверяет меня, что с головой у меня всё в порядке. Ага, шайтан-программа под линукс не понимает линуксового разделителя в виде двоеточия в пути к библиотекам! Делаем сотни симлинков, указываем ему одну директорию. Ох, неужели, он взлетел! Дальнейшие пытки расписывать не буду — это уже чисто мои косяки.

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

Отправил знакомым почтой подарки к Новому году, они мне тоже. Казалось бы, при чём тут IT? Но мы ведь живём в век продвинутых технологий! Конечно же, обменялись через интернет ID отправлений, чтоб время от времени отслеживать их путь на сайте Почты России. В прошлом году такая тактика сыграла неплохо, но в этом…

Одна бандероль через неделю после отправки оказалась в сортировочном центре другого города, аж за 1500+ километров. Быстро, не спорю, вот только не туда… Вторая, что ещё интереснее, отправлена уже неделю назад и два месяца назад получена адресатом — за такую скорость могли бы и Нобелевскую вручить. Жаль, опять доставлена не по тому адресу.

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

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

Люблю издеваться над аутсорсерами.

Просят у меня дамп базы — не вопрос. Готов батник, где дамп пакуется в 500 файлов и с помощью консольной утили blat.exe уезжает на какой-нибудь Гмейл. Кушайте, мне не жалко!

А, ну да: каждый файл — отдельным письмом. Ну, я же не виноват, что они постоянно забывают свою учётку для доступа…