Книга: Дефрагментация мозга. Софтостроение изнутри

Архитектура сокрытия проблем

Архитектура сокрытия проблем

В 2008 году крупный разработчик ERP-системы для розничной торговли оказался в числе наших клиентов. Что же хотела компания с 25-летней историей, двумя сотнями сотрудников и множеством клиентов в Европе и Северной Америке, среди которых такие бренды, как Naf Naf, Vieux Campers, Tally Weijl, Guess, от небольшой программистской фирмы, вчерашнего «стартапа»?

Новая версия системы «по всем правилам архитектуры», подобно каменному цветку, не выходила. Сроки затягивались, приёмки переносились, инвесторы нервничали. Не знаю, кому пришла в голову идея, но фирма решила попробовать в деле так называемую «программную фабрику» (software factory). То есть генерировать немалую часть кода и компонентов системы из мета-описаний. Предшествующие внутренние попытки домен-ориентированной разработки на базе. NET, NHibernate и всевозможных лучших практик не приносили результата.

Проведённый Марком, нашим консультантом, уже самый первый аудит во время командировки в Монпелье принёс очень интересную информацию к размышлению. Предыдущая версия была реализована в классической клиент-серверной технологии в среде Microsoft. То есть SQL Server, «толстый клиент» или веб-клиент под ASP.Net с разделяемой на уровне сборок логикой. Все работало прекрасно до некоторого времени. А время, поскольку клиенты крупные, подошло быстро, за несколько лет. База данных разрослась, время отклика как интерактивной работы, так и пакетов увеличилось, производительность продолжала понемногу деградировать. Например, обработка консолидациирезультатов торговли за сутки стала превышать эти самые сутки.

Программисты даром времени не теряли и упомянутую консолидацию переписывали три раза. Сначала на SQL, но с курсорами, получив ещё худший результат. Потом попытались избавиться от курсоров, но всё равно не смогли достигнуть требуемой производительности. Потом в команде каким-то образом появились специалисты, сказавшие: «Это не объектный подход!» Они переписали всю обработку на C#, окончательно похоронив производительность модуля.

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

Физическая архитектура хранения, секционирование таблиц, оптимизация индексов и запросов по выборочной статистике – эти вопросы всерьёз не рассматривались, база данных тихо кряхтела одним файлом, правда, на мощном 16-ядерном сервере с 32 гигабайтами памяти и быстрым дисковым массивом.

Разработка между тем шла дальше. Новый толстый клиент работал через слой WCF с сервером приложения. Ведь каждому «специалисту» известно, что если данные в СУБД обрабатываются медленно, то необходимо их оттуда загодя вытаскивать, кэшировать и обрабатывать на сервере приложений. Вдруг, так быстрее получится?

Однажды я наблюдал, правда, уже в другом продукте, как обрабатывали таким образом матрицу прав доступа. Две сотни пользователей, десять миллионов объектов и voila – списки размером порядка 100 миллионов элементов сидят в памяти сервера приложения, где со скрипом тормозов обрабатываются запросами LINQ. Выдавать из СУБД информацию, уже прошедшую необходимые фильтры доступа, почему-то оказалось сложнее.

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

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

Можно ли, будучи в здравом уме, представить себе, чтобы обработка данных шла быстрее их передачи между слоями системы и отображения? Для этого надо серьёзно постараться в освоении «паттернов», нагромоздить кучу вроде бы правильного, но бессмысленного кода с высокой цикломатической сложностью, глубинами иерархий и связностью классов. Ситуацию не спасала автоматическая генерация кода большей части этого Ада Паттернов по сравнительно простой модели с несколькими десятками сущностей.

Упомянутую проблему консолидации нами было предложено решить с помощью кубов OLAP. Действительно, после такой переработки, процедура стала идти вместо суток несколько часов, причём, что в MOLAP[117], что в ROLAP[118] вариантах. Что, собственно, означает: при правильной организации физического хранения и грамотном SQL-коде как минимум тех же результатов можно было бы добиться, не выходя за пределы реляционной БД. Например, наше пожелание создать в определённой таблице кластерный индекс не встретило понимания и было потеряно в глубинах архитектурного буйства и организационных процедур.

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

Спустя почти год, мы благополучно закрыли проект и, утерев пот со лба, передали модуль на сопровождение заказчику. К тому времени ситуация дошла до попыток внедрения в фирме – продуктовом разработчике – «гибких» экстремальных методик. При наличии штата экспертов предметной области и 25-летнего опыта создания функциональных моделей это означало полный разрыв проектирования с производством.

Через небольшое время фирма была поглощена холдингом Cegid – крупнейшим во Франции поставщиком собственных и приобретённых специализированных отраслевых ERP-решений. Уже имея свои лоскутки по розничной торговле, они просто купили фирму со всеми долгами, потому что сотни крупных клиентов – это не шутка, а серьёзный актив, которому они отныне будут предлагать и свои решения.

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

Один из «Технических Дней Microsoft» (TechDays) в 2011 году был целиком посвящён специализации DBA (DataBase Administrator). А выступающий на сцене ведущий эксперт не постеснялся напрямую высказать призыв: «Последние годы я вижу тотальное падение компетенции в области баз данных. DBA, проснитесь!»

Оглавление книги