О точности диагностики патологий

Сергей Кузнецов

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

Идейные статьи писать гораздо труднее, чем технические (хотя бы потому, что для этого нужны идеи). Таких статей на порядке меньше, чем технических. И тем они ценнее. С моей точки зрения, статья Адама Якобса "Патологии больших данных" относится к категории "идейных" статей, будоражущих сообщество баз данных, заставляющих людей думать.

Статья написана на (почти) популярном уровне, не требует (почти) никаких предварительных знаний. Фактически, цель статьи состоит в том, чтобы показать, что при создании эффективных средств анализа данных большого объема невозможно обходиться старыми методами. Необходимы новые, подчас рискованные подходы, в которых применяются все возможности современных аппаратных средств, и которые опираются на теоретические результаты и алгоритмы, полученные в разных областях computer science.

Первой специализацией автора статьи была лингвистика, а степень PhD он получил в области вычислительной нейропсихологии. Ему приходилось заниматься аналитическими исследованиями больших объемов данных, и с начала 2000-х он работает в компании 1010data Inc., где руководит разработкой аналитической СУБД Tenbase.

Таким образом, Адам Якобс пришел в область управления данными сравнительно недавно, не из унивеситета, а из научной практики. В отличие от многих других действующих членов сообщества баз данных, которые с юных лет воспитывались на идеях Кодда, опыте System R и Ingres и т.д., он пытается смотреть на мир аналитики данных полностью открытыми глазами. И, конечно, это делает его наблюдения и размышления особенно ценными. С другой стороны, как показывает статья, ему не хватает этой самой академической подготовки в области управления данными, что делает некоторые его выводы, на мой взгляд, сомнительными.

С этого места мне хотелось бы перейти к критическим замечаниям по поводу статьи "Патологии больших данных". Если вы ее еще не прочитали, прервите чтение моей заметки и почитайте статью Якобса, а потом, если захотите, вернитесь к моим комментариям.

Статья Адама Якобса начинается с эффектного примера аналитического приложения с фиктивными данными "всемирной переписи". Автор убедительно демонстрирует, что для опытного программиста создание эффективно работающего кода такого приложения не составляет труда. Далее он хочет показать, что современные SQL-ориентированные СУБД с этой задачей не справляются, и выбирает в качестве жертвы PostgreSQL. Он утверждает, что запрос с группировкой по всем трем столбцам таблицы с миллиардом строк и тремя столбцами (общим объемом в 40 гигабайт) на машине с 20 гигабайтами основной памяти эта система выполняла в течение суток. По его мнению, основной проблемой является то, что система выполняла запрос с использованием предварительной полной сортировки этой таблицы.

Насколько я понял из Internet, в мире PostgreSQL к моменту написания этой заметки еще никто не воспроизвел эксперимент Якобса (публика из сообщества PostgreSQL сетует, что, мол, неизвестен точный формат таблицы). Но мне кажется, что, как бы не была устроена таблица, занимающая 40 гигабайт внешней памяти, крайне трудно написать программу внешней сортировки, которая при наличии буфера в основной памяти объемом в 20 гигабайт работала бы 24 часа. Что-то здесь не так.

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

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

Не могу не поспорить с еще одним утверждением автора, которое он и сам признает спорным: "проблемы обработки транзакций ... в значительной степени решены". По-видимому, это так, если иметь в виду объемы данных, здесь действительно нет проблем. Но есть проблема обработки транзакций в реальном времени. Не буду здесь об этом распространяться, а лишь сошлюсь на статью Майкла Стоунбрейкера и др. "OLTP в Зазеркалье".

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

В частности, и в Ingres, и в Postgres можно было хранить таблицы в виде B-дерева в полностью упорядоченном виде. Начиная с System R, в SQL-ориентированных СУБД можно использовать кластеризованные индексы, и при последовательном чтении кластеризованной таблицы она обрабатывается в почти упорядоченном виде. Другое дело, что при создании таблицы нужно явно сказать системе, как хранить эту таблицу, но тут уже никуда не денешься (хотя и здесь в последние годы наблюдается прогресс; в частности, применяется адаптивная оптимизация, автоматически изменяющая физические структуры базы данных). И все это абсолютно не противоречит реляционной модели данных.

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

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

Рассуждения Якобса про денормализацию таблиц и про потребность хранения нескольких копий одной и той же таблицы с разным физическим представлением интересны, но опять же не являются откровением. По поводу денормализации мне вспоминается руководство администратора к одной из версий СУБД Infotmix Online (не менее чем 15-летней давности). В этом руководстве денормализации посвящалась отдельная глава. Рекомендовалось после создания правильным и теоретически обоснованным образом нормализованной схемы базы данных внимательно проанализировать будущую рабочую нагрузку системы баз данных и денормализовать таблицы, чтобы запросы в среднем выполнялись более эффективно. По сути, у Якобса говорится о том же.

Что же касается второго аспекта, то в SQL-ориентированных базах данных уже много лет поддерживается механизм материализованных представлений. С его помощью можно добиться в точности желаемого эффекта: поддерживать в базе данных (неважно, централизованной или распределенной) несколько по-разному хранимых копий одной и той же таблицы. По-видимому, Якобс об этом не знает или не желает вспоминать.

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

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

На мой взгляд, и статья, и моя заметка заслуживают дополнительного обсуждения. Пишите мне, я отвечу, может быть, лично, а возможно, и публично.