Тарасов С. В. СУБД для программиста. Базы данных изнутри

Большие данные как состояние отрасли

Термин «большие данные» (big data) был извлечён из пыльных закромов маркетологами от компьютерных технологий несколько лет назад. Попробуем взглянуть, чего в этом явлении больше: нового или хорошо забытого старого.

Прежде всего, у человека с дефрагментированными мозгами, а сия процедура необходима из-за непрерывно поступающей обрывочной информации, должен возникнуть естественный вопрос: «Большие — это, простите, сколько?»

Во время написания этой главы словом «большие» оценивались объёмы, начиная примерно с 1-10 петабайт.

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

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

В1975 году конференция по базам данных, представляющая широкое сообществоспециалистов, ввела в обиход проблематику очень больших баз данных (Conference on Very Large Databases). Название с точки зрения маркетинга, было менее удачным, всего лишь скупая аббревиатура VLDB.

В1979 году на поднимающейся волне интереса к большим базам данных или, точнее, платёжеспособного спроса на прогрессирующую элементную базу, была образована компания с говорящим названием Teradata. И уже в 1984 году нарынкепоявилсяеёпродуктTeradata database, предназначенный длямассивнопараллельнойобработки(MPP) большихобъёмовданных. Да, вы не ослышались, продукт появился именно для того, чтобы в 1984 году обрабатывать те «большие данные». А большими, в соответствии с аппаратными возможностями ЭВМ той эпохи, считались тогда данные порядка 1 терабайта.

181

Примерно к началу-середине 1990-х стоимость носителей информации стала подъёмной даже для средних предприятий. Вышли на рынок массово доступные продукты для анализа данных. Маркетинговым «кейсом» для ЛПР19 было незабвенное: «Анализ выявил, что изменение местоположения прилавков с бананами увеличит их продажу на 146%». Поезд стал набирать ход, и к 2000 году средства анализа данных были включены в СУБД ведущих поставщиков, например, Microsoft OLAP. Sybase выпускает специализированную СУБД «IQ» со входным языком SQL, использующее колоночное хранение.

Следуетпризнать, что базаданныхразмеромв1 терабайтисейчас, в2014 году, вовсе не является маленькой. Транзакционные БД даже крупных предприятий со всеми сделками, контрактами, проводками, каталогами и прочим жизненно важным хозяйством измеряются десятками и сотнями гигабайт за период в несколько лет.

Из-за того, что сегодня вы можете купить себе домой жёсткий диск объёмом в1 терабайтпо цене поездки на такси из аэропорта вцентр города, такие данные не перестали быть достаточно большими. Заполнить подобную БД осмысленной информацией и потом попытаться её анализировать с приемлемым временем отклика — задача, которая, попрежнему, под силу только профессиональным аналитикам в содружестве со специалистами СУБД.

Чтобы не быть голословным, приведу примеры. База данных перемещений всех пассажиров парижского региона, при условии, что все ониимеютименныемагнитныекарты, загодумещаетсяв1 (один) терабайт. В тот же один терабайт укладываются неагрегированные данные за 3-5 лет бухгалтерий всех основных компаний по добровольному медицинскому страхованию национального уровня (десятки миллионов застрахованных, десятки финансовых операций в месяц на человека) с 30-40 уровнями аналитики(измерений). Контораповеб-маркетингуумещаетвБДразмером около одного терабайта данные всей активности пользователей национальной службы (порядка 10 миллионов профилей) с примерно 30

19 ЛПР — Лицо Принимающее Решения, аналог англ. VIP — Very Important Person

182

измерениями за 1-2 года. База данных сбора информации с устройств национальной электрической сети (сотни тысяч устройств, пакеты приходят каждые 10 минут) за 5 лет накапливает 3-4 терабайта.

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

На этом принципе фильтрации информации для анализа работают все выжившие в результате эволюции живые организмы. Если человеческий мозг одновременно будет воспринимать всю полноту приходящих от рецепторов сигналов, то под давлением поступающих петабайтов произойдёт мгновенный крах всей системы. Поэтому, например, читая в метро книжку, вы не замечаете деталей происходящего события или разговора в нескольких метрах. А если книжка требует напряжения мысли, то не заметите и как у вас вытащат кошелёк.

При этом человеческий организм способен настроиться на приём более детальнойинформации. Сосредоточиться. Напрячься. Сконцентрироваться. Уловить на слух тонкий звук, запах, лёгкое прикосновение, едва заметную игру теней. Если надо.

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

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

183

среды. И отпечатываются в памяти для анализа действительно важные события.

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

Янамеренно не касаюсь специализированных БД, типа тех, что имеются

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

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

Для таких специалистов «большие данные» открывают новые сцены и рынки. Перекрестимужеупоминавшийсявышепринциптранзакционности

ACID в BASE (Basically Available, Soft-state, Eventual consistency). Не будем упоминать, что распределенные БД массово существовали в 1980-90-х годах. По ключевым словам «репликация», «сервер репликации», «двухфазнаяфиксация» желающиесмогутнайтинемалоинтересного. Ичто от распределённых архитектур всеми силами избавлялись при первой же возможности по причине гораздо более высоких расходов на разработку и

184

эксплуатацию по сравнению с централизованными решениями. Сформулируем принцип CAP: есть три качества распределенных систем —

Consistency, Availability и Partition Tolerance, выбирайте любые два.

Назовём этот принцип теоремой, которую, правда, никто всерьёз не будет доказывать. Зато он очень похож на другую управленческую «теорему» в софтостроении: «Быстро, качественно и дёшево — выберите два нужных критерия из трёх».

Одним словом, люди всерьёз пытаются ломать прежние тенденции. Что имеем в итоге на сегодняшний день. Позитивные моменты:

облегчение работы с объёмами данных, считавшимися большими 30 лет назад. Правда, в основном за счёт развития аппаратуры и универсальных РСУБД;

некоторые подвижки в теоретических работах и их реализации;

возможность сбора и анализа большего объёма информации в научной сфере;

относительная общедоступность решений по обработке данных, считающихся большими сегодня (Hadoop, MapReduce и др.).

Не обошлось, конечно, и без негативных:

на практике принцип сбора данных «на случай если они вдруг понадобятся в будущем» быстро превращает хранилище в помойку и кладбище;

в научной сфере развернулись дискуссии на тему достоверности и собственно научности подходов, потому что при широком доступе к результатам экспериментов найденные в данных закономерности выдаются за подтверждённые гипотезы без объяснений природы связи. Самая настоящая астрология въехала в науку на колёсах телеги «больших данных». Например, корреляция между потреблением сыра «Моцарелла» на душу населения и числом получивших степень доктора наук в США за 2000-2009 годы —

185

целых 96 %20, и, согласно цифрам, эти явления гораздо более связаны, нежелизависимостьмеждуналичиемтучнанебеидождём.

за исключением случаев необходимости использования специализированных СУБД, пользуясь некомпетентностью в области баз данных части разработчиков и руководителей проектов, ведётся достаточноагрессивная пропаганда противуниверсальныхРСУБД;

освоение бюджетов проектами с неизвестной рентабельностью с однойстороны, повышениерасходовнамэйнфреймыдляподдержки существующих систем 40-50-летней давности — с другой.

Что можно делать в такой ситуации? Наверное, наилучшим решением будет исходить из собственных потребностей. Тогда их придётся анализировать, планировать объёмы и удивляться, что во многих случаях можно обойтись вполне обычными данными, без «больших».

Ну, а если имеются неосвоенные бюджеты, то почему бы не собрать петабайт-другой данных. Вдруг он когда-нибудь понадобится?

20По данным USDA (per capita consumption of mozzarella cheese) и National Science Foundation (civil engineering doctorates awarded)

186

Программирование с испытаниями

«Обычно арьергард прежнего авангарда является авангардом нового арьергарда». С. Е. Лец

Типы соединений в SQL на примерах

Основная операция в SQL-запросах — соединение, представляющее собой последовательность множественных операций пересечения, согласно критериям, и объединения выбранных кортежей (строк) в результирующее отношение (таблицу). Для чего служат различные виды соединений таблиц проще всего запомнить на практических примерах.

Для иллюстрации возможностей соединений используются две связанные таблицы: контактные лица (contacts) и компании (companies).

CREATE TABLE companies ( company_id INT NOT NULL,

company_name VARCHAR(64) NOT NULL, phone VARCHAR(16) NULL, CONSTRAINT pk_companies

PRIMARY KEY (company_id)

)

CREATE TABLE contacts ( contact_id INT NOT NULL, contact_name VARCHAR(64), phone VARCHAR(16) NULL, company_id INT NULL, CONSTRAINT pk_contacts

PRIMARY KEY (contact_id), CONSTRAINT fk_contact_company FOREIGN KEY (company_id)

REFERENCES companies(company_id)

)

Заполним таблицы данными.

INSERT INTO companies

VALUES (1, 'Рога и копыта', null) INSERT INTO companies

VALUES (2, 'НИИ ЧАВО', '322-223')

INSERT INTO contacts

VALUES (1, 'Бендер Остап Сулейманович', null, 1) INSERT INTO contacts

187

VALUES (2, 'Гарин Петр Петрович', '322-223', null) INSERT INTO contacts

VALUES (3, 'Привалов Александр Иванович', '322-223', 2)

Наши исходные заполненные таблицы будут выглядеть следующим образом.

Таблица компаний (companies)

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

Обычное эквисоединение, оно же внутреннее (INNER JOIN)

соединение.

SELECT contact_name, company_name FROM contacts INNER JOIN companies

ON contacts.company_id = companies.company_id ORDER BY contact_name

Внешнее соединение слева (LEFT JOIN) включает все строки таблицы или результата, находящегося слева от оператора JOIN.

SELECT contact_name, company_name

FROM contacts LEFT OUTER JOIN companies

ON contacts.company_id = companies.company_id ORDER BY contact_name

188

Аналогичным образом, внешнее соединение справа (RIGHT JOIN)

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

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

SELECT contact_name, company_name

FROM contacts RIGHT OUTER JOIN companies ON contacts.phone = companies.phone

ORDER BY contact_name

Привалов Александр Иванович НИИ ЧАВО

Выполним для полноты эксперимента ещё и внешнее соединение слева по тому же атрибуту.

SELECT contact_name, company_name

FROM contacts LEFT OUTER JOIN companies ON contacts.phone = companies.phone

ORDER BY contact_name

Результат

Привалов Александр Иванович НИИ ЧАВО

Полное соединение (FULL JOIN) также проводим по неключевому атрибуту — номеру телефона.

SELECT contact_name, company_name

189

FROM contacts FULL OUTER JOIN companies

ON contacts.phone = companies.phone

ORDER BY contact_name

Нетрудно убедиться, что итогом полного соединения является объединение результатов, полученных внешними соединениями слева и справа.

Привалов Александр Иванович НИИ ЧАВО

Перекрёстное соединение (CROSS JOIN), оно же декартово произведение в терминах реляционной алгебры — каждая строка левой таблицы соединяется со всеми строками правой. Если в первой таблице имеется N строк, а во второй — М строк, то в результирующей таблице вы получите ровно N·M строк, поэтому будьте осторожны при использовании перекрёстного соединения на больших таблицах.

SELECT contact_name, company_name FROM contacts CROSS JOIN companies ORDER BY contact_name

Привалов Александр Иванович Рога и копыта Привалов Александр Иванович НИИ ЧАВО

Исходники и синхронизация структур

В «Дефрагментации» [13] мимоходом было упомянуто понятие

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

190