R&D такой R&D

zabivator — 06.04.2010 Периодически я серьёзно опасаюсь за своё здоровье.
В минуты слабости возникает желание "а пошло оно всё..." и хочешь уйти рисовать формочки или заниматься бизнес-процессами. Там всё просто - вот требования заказчика, вот работа аналитика (либо ты сам - аналитик), вот смета, вот план работ, вот результат.
Заказчик получил работу и счастлив.

Совсем другое дело, когда занимаешься R&D. Чётких планов и сроков получить невозможно почти никогда, менеджеры пьют водку литрами и умножают все оценки сроков на пять, а если они всё-таки срываются - то водку начинают пить вёдрами. Чаще всего все критичные features пускают как optional, иначе придётся продавать почки.

Вот например, чудная тема - разработка СУБД! Казалось бы, предметка известна и изучена уже лет двадцать как, есть базис и реализации - нахера новое СУБД, и что же сложного в их разработке?

Oracle - отличная СУБД. Дорогая аж звездец, но готовая и хорошая.
А теперь представьте Google или Facebook - какие у них данные и нагрузки. Oracle становится дорогим.
Плюс универсальные СУБД могут сливать кастомным решениям - и не важно, SQL в основе или key-value storage.

Появились SSD, появились multicore. Реляционная модель стала ещё более неадекватной - гвоздь в её гроб вбивают кластерные решения, колоночная организация данных, и недавно появиваяся NVIDIA CUDA.
Я знаю как минимум одну коммерческую production СУБД с нереляционным движком. И у меня есть все основания полагать, что SyBase - тоже нереляционный.
Я не знаю как иначе объяснить совпадающие с точностью до константы времена выполнения запросов, которые сливаются на реляционной модели (в частности, которые сливает Oracle и MS SQL).

Но крыша шуршит и скрипит основательно. Чудная вещь - хешовые join! Сколько я ночей с вами не спал!
А если хеш не помещается в память, и join многопроходной (хеш заполняется сколько хватает в памяти, потом остаток, и ещё остаток, пока всё не обработаем)?
А если у нас хешей два, и они дерутся за память?
А если многопроходному джойну требуется сохранить сортированность для вышестоящего merge-join?
А если мы параллельно выполняем join на одном хеше, или на параллельных хешах?

В такие моменты крыша начинает неиллюзорно шуршать, ты пытаешься собрать мысли в кучку, выстраиваешь в голове анимированный мультик "как это всё работает", и иногда хочется побиться головой об стену, чтобы найти наконец-то проклятое решение, которые ЛЯЖЕТ, которое БУДЕТ РАБОТАТЬ, и которое можно сделать ОДНОМУ или ВДВОЁМ-ВТРОЕМ, потому что нету у тебя десяти лет, тысяч разработчиков, и много миллионов для покупки звёзд из мира СУБД, тебе нужно решить задачу здесь и сейчас, за пару месяцев... Чтобы отвоевывать дальше свою нишу.

Иногда я думаю, что психически здоровый человек никогда этим не станет заниматься.
Во-первых, с такими высокими рисками до старости не доживёшь, поседеешь в тридцатник.
Во-вторых, такому человеку потребуется немало тяжелых наркотиков, чтобы свободноно манупилировать шестью-девятью образами одновременно, верифицировать их, выстраивать, комбинировать.
Нужно быть чуть-чуть шизофреником, чтобы таким заниматься.
Неудивительно, что многие хакеры забывают есть и спать, им пофигу как они одеты и что про них думают - их голову и мозг занимает СИСТЕМА, её КОМПОНЕНТЫ, и то КАК ОНО РАБОТАЕТ.
Жена, дети, семья - всё уходит на второй план, и лишь изредка врывается отлаженный механизм моделирования в виде ультиматумов или просьб о помощи.

Не ходите, дети, в R&D. До старости не доживёте.

Оставить комментарий

Популярные посты:

• Ранее
• Архив