Презентацию к лекции 20 Вы можете скачать здесь.
Введение: Почему традиционные базы данных ставят вопросы
Реляционные базы данных (РБД) на протяжении примерно тридцати лет успешно обслуживали потребности отрасли. Их производительность соответствовала росту объемов информации и требованиям рынка. Однако с появлением феномена Big Data возникла необходимость пересмотреть подходы к хранению данных. Чтобы понять, почему РБД и большие данные не всегда совместимы, необходимо рассмотреть определение Big Data.
Стандартное определение включает три основные характеристики (правило «трех V»):
- Объем (Volume);
- Скорость (Velocity);
- Разнообразие (Variety).
Со временем этот список расширился. Добавились Достоверность (Veracity) и другие характеристики, такие как виртуализация и Ценность (Value). Достоверность стала актуальной после того, как индустрия научилась справляться с объемом, скоростью и разнообразием. Она описывает, насколько данные чисты, сколько в них шума, аномалий и противоречий. Акцент сместился с погони за объемом в сторону понимания ценности данных для бизнеса.
Скорость: слабое место реляционной модели
Изначально РБД были созданы для быстрой обработки структурированной информации. Их главная ценность — высокая скорость операций чтения (выборки данных по условию). Это достигается за счет двух факторов:
- Структурирование и типизация данных, что позволяет оптимизировать внутренние процедуры.
- Использование стандартного языка запросов (SQL).
- Применение индексов.
Однако высокая скорость чтения имеет свою цену. Построение индексов — ресурсоемкая операция. Пока количество операций чтения многократно превышает количество операций записи, система работает эффективно.
Проблемы начинаются, когда скорость записи или обновления данных выравнивается со скоростью чтения. Индексы должны постоянно перестраиваться, что резко снижает производительность. В сценарии анализа больших данных мы сталкиваемся именно с такой ситуацией: один аналитик или приложение выполняет выборку из огромного потока данных, который генерируется множеством источников. Здесь интенсивность записи сопоставима с интенсивностью чтения, что делает традиционные РБД неоптимальными.
Масштабирование: дилемма распределенности
Второй вызов для РБД — масштабирование. Существует два подхода:
- Вертикальное масштабирование (Vertical Scaling): увеличение мощности одного сервера (больше памяти, быстрее диски, перенос данных в RAM).
- Горизонтальное масштабирование (Horizontal Scaling): увеличение количества машин (серверов) в кластере.
Именно с горизонтальным масштабированием у классических РБД возникают фундаментальные трудности. Они не были спроектированы для работы с распределенными копиями данных.
Ключевое требование к РБД — Консистентность (Consistency) или целостность данных. Это означает, что взаимосвязанные данные должны быть согласованы в любой момент времени. При распределении базы на несколько серверов возникает дилемма: либо мириться с временной рассогласованностью данных (отложенная синхронизация), либо терпеть большие задержки при выполнении транзакций для поддержания целостности.
Чаще всего проблему масштабирования в РБД решали через Репликацию (Replication). Создается одна мастер-база, в которую вносятся все изменения, и несколько баз-копий, предназначенных только для чтения. Такой подход отлично масштабирует операции чтения, но совершенно не решает проблему масштабирования записи, так как все изменения по-прежнему упираются в один мастер-узел.
Вариативность и разреженность данных
Самая значительная проблема РБД связана с разнообразием данных (Variety).
Представим, что мы собираем данные об одном объекте из разных источников. В одном источнике есть информация об одних его атрибутах, в другом — о других. Если мы создадим единую реляционную таблицу с полями из обоих источников, то большинство строк будут содержать пропуски (NULL значения).
Например, для записи из первого источника поле из второго источника будет пустым, и наоборот.
Такие данные называют разреженными (Sparse). Их хранение в РБД приводит к неоптимальному использованию дискового пространства.
Вторая и не менее критичная проблема — изменение схемы данных (Schema Evolution). После того как накоплен большой объем данных, построены индексы и система работает быстро, добавление всего одного нового поля превращается в сложную задачу. Изменение типа поля без потери целостности и связей с другими таблицами — это операция, с которой РБД справляются хуже всего.
Современные данные движутся не в сторону большей структурированности, а в сторону неструктурированности или полуструктурированности. Структура данных зачастую непредсказуема. Система должна быть готова сохранять информацию с неизвестной заранее схемой и продолжать обрабатывать её.
Краткие итоги
Сопоставление архитектурных принципов реляционных систем с реальностью современных данных выявляет фундаментальный конфликт парадигм. Дело не в том, что традиционные базы данных стали «плохими», а в том, что изменился сам характер задач и ландшафт данных. РБД создавались в эпоху, когда доминировали транзакции и предсказуемые структуры, где ценность обеспечивалась за счет строгости и целостности.
Ключевое ограничение проявляется в экономике операций. Реляционная модель оптимизирована под сценарий, где чтение многократно доминирует над записью. Платой за эту скорость является сложная система индексов. Как только баланс смещается в сторону непрерывного поступления данных, накладные расходы на поддержание индексов становятся критическими, лишая систему её главного преимущества. Это указывает на необходимость иных моделей хранения, которые изначально проектируются под потоковую запись.
Не менее существенным барьером является жесткая связанность данных и схемы в РБД. Требование консистентности вступает в прямое противоречие с необходимостью горизонтального масштабирования, заставляя прибегать к компромиссам вроде репликации, которые лишь частично решают проблему производительности. В свою очередь, появление разреженных и быстро эволюционирующих данных обесценивает саму идею заранее заданной и строгой схемы. Попытка втиснуть такие данные в таблицы ведет либо к деградации производительности из-за пустых значений, либо к дорогостоящим и рискованным миграциям схемы.
Таким образом, переход к экосистемам больших данных — это не эволюционное улучшение РБД, а смена архитектурного мышления. Понимание этих ограничений критически важно для выбора правильного инструмента. Если для систем учета и транзакций (OLTP) реляционные базы по-прежнему остаются стандартом, то для задач аналитики над большими массивами разнородных данных требуются решения, способные принять как должное неструктурированность, распределенность и асинхронность. Игнорирование этих фундаментальных различий ведет к архитектурным ошибкам, которые проявляются в виде низкой производительности, сложности поддержки и неспособности системы адаптироваться к изменениям.
Введение
Реляционные базы данных (РБД) около 30 лет успешно обслуживали отрасль. Однако появление Big Data поставило вопрос об их применимости для новых задач. Определение Big Data включает «три V»: Объем (Volume), Скорость (Velocity), Разнообразие (Variety). Позже к ним добавились Достоверность (Veracity) и Ценность (Value). Акцент сместился с погони за объемом в сторону понимания пользы данных для бизнеса.
Проблема 1: Скорость и индексы
РБД изначально создавались для быстрой обработки структурированных данных. Их главная ценность — высокая скорость чтения (выборки). Это достигается структурированием, использованием SQL и, главное, индексами.
Построение индексов — это ресурсозатратная операция. РБД работают хорошо, пока чтения намного больше, чем записи. В аналитике больших данных ситуация обратная: множество источников пишут данные, а один аналитик их читает. Скорость записи выравнивается со скоростью чтения. Индексы должны постоянно перестраиваться, что критически снижает производительность.
Проблема 2: Масштабирование и консистентность
Существует вертикальное (увеличение мощности одного сервера) и горизонтальное (увеличение числа серверов) масштабирование. РБД плохо приспособлены к горизонтальному масштабированию из-за требования Консистентности (Consistency). Данные должны быть согласованы всегда. При распределении базы по разным машинам возникает дилемма: либо мириться с временной рассогласованностью, либо терпеть большие задержки на синхронизацию.
Чаще всего для масштабирования чтения использовали Репликацию (Replication) — создание одной мастер-базы на запись и множества копий на чтение. Это не решает проблему масштабирования записи, так как все изменения упираются в один мастер-узел.
Проблема 3: Разнообразие и структура
Это самая главная проблема. Данные из разных источников об одном объекте могут иметь разный набор атрибутов. При объединении их в одну таблицу большинство полей будет содержать пустые значения NULL. Такие данные называют разреженными (Sparse). Это приводит к неоптимальному использованию ресурсов.
Вторая проблема — изменение схемы данных (Schema Evolution). После накопления большого объема данных добавление хотя бы одного нового поля или изменение типа поля — крайне сложная и рискованная операция, нарушающая целостность.
Современные данные движутся в сторону неструктурированности. Мы не знаем заранее, какой будет структура данных в следующий момент, но должны уметь их сохранять и обрабатывать. РБД с их жесткой схемой для этого не подходят.
1. Реляционные базы данных хорошо работают в сценариях с преобладанием операций чтения над записью.
2. Ключевое преимущество РБД — скорость выборки — достигается за счет индексов, обслуживание которых ресурсозатратно.
3. Интенсивная запись и обновление данных в РБД вызывают необходимость постоянной перестройки индексов, что критически снижает производительность.
4. Горизонтальное масштабирование РБД ограничено требованием консистентности данных, так как распределенность порождает задержки синхронизации.
5. Репликация в РБД решает проблему масштабирования чтения, но не записи, так как все изменения упираются в один мастер-узел.
6. Хранение разреженных (sparse) данных в РБД приводит к появлению большого количества NULL-значений и неэффективному использованию ресурсов.
7. Изменение схемы данных в РБД с накопленным большим объемом информации — чрезвычайно сложная и рискованная операция.
8. Современные данные часто имеют непредсказуемую или быстро меняющуюся структуру, что не соответствует реляционной модели.
9. Ценность данных (Value) становится ключевой характеристикой, определяющей целесообразность работы с ними, а не погоня за объемом.
10. Недостатки РБД в контексте Big Data носят архитектурный, а не эволюционный характер, что требует принципиально иных технологий хранения.
1. Какие ключевые характеристики определяют понятие Big Data?
2. Что является основной операцией, под которую оптимизированы реляционные базы данных, и за счет чего достигается её высокая скорость?
3. Почему выравнивание скоростей чтения и записи создает проблемы для производительности РБД?
4. В чем заключается разница между вертикальным и горизонтальным масштабированием?
5. Каким образом требование консистентности данных ограничивает горизонтальное масштабирование РБД?
6. Какой метод чаще всего используется для масштабирования чтения в РБД и каков его главный недостаток?
7. Что такое разреженные (sparse) данные и почему они неэффективно хранятся в РБД?
8. Почему операция изменения схемы данных является проблемной для РБД?
9. Как появление данных с непредсказуемой структурой влияет на целесообразность использования РБД?
10. Какая характеристика Big Data, добавленная позже других, описывает качество и достоверность информации?
