Реляционная модель тридцать лет держала корпоративные данные, и в большинстве учётных задач она остаётся правильным выбором. Но мы всё чаще встречаем заказчиков, у которых Oracle или MS SQL упираются в потолок – не из-за плохого администрирования, а из-за природы нагрузки. Отчёт по таблице на сотни миллионов строк строится полчаса. Веб-сервис с пиками в десятки тысяч запросов в секунду падает, как только мастер-узел перестаёт справляться. В таких случаях проблему не лечат добавлением памяти – меняют саму модель хранения.

Колоночные хранилища: аналитика вместо транзакций

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

В этом сегменте уже есть зрелые продукты: Sybase IQ работает на рынке больше десяти лет, Vertica и Infobright набирают вес, а у Microsoft с SQL Server 2008 R2 появилась PowerPivot с колоночным движком в памяти. Для хранилищ данных и BI-витрин выигрыш на тяжёлых запросах достигает порядка величины. Подвох в том, что эти системы плохи на частых точечных вставках и обновлениях – это инструмент для чтения и анализа, а не для проводок. Поэтому колоночное хранилище ставят рядом с транзакционной базой, а не вместо неё, и связывают их ETL-процессом.

NoSQL: когда важнее масштаб и доступность

Вторая группа задач – высоконагруженные веб-сервисы, где данные слабо структурированы, а главное требование – горизонтальное масштабирование на дешёвых серверах. Здесь поднялась волна NoSQL: Google со своим BigTable, Amazon с Dynamo, открытые Cassandra, HBase, MongoDB, CouchDB. Это не «база лучше реляционной», а другой набор компромиссов. Эти системы сознательно жертвуют частью гарантий ACID и строгой согласованностью ради доступности и распределённости – выбор, который формулирует теорема CAP.

Корпоративному заказчику NoSQL подходит точечно: каталоги и профили с миллионами записей, логи и события, кэш и сессии, хранение документов переменной структуры. Любопытно, что та же инженерная мода видна и за пределами серверов – на недавней Google I/O, где показали Android 2.2 Froyo, сквозной темой была работа с большими распределёнными данными на стороне облака. А вот биллинг, бухгалтерию и любые операции, где деньги обязаны сходиться до копейки, мы по-прежнему держим в реляционной СУБД.

Как выбирать под проект

Гнаться за модой здесь дорого. Решение принимают от профиля нагрузки: соотношение чтения и записи, объём, требования к согласованности и регуляторике. Для госсектора отдельный фактор – сертификация и защита данных: молодые open-source-движки этими атрибутами пока не обладают, и это часто закрывает вопрос.

Мы внедряем гибридную архитектуру: реляционное ядро для учёта, колоночную витрину для отчётности, NoSQL для нагруженных и слабоструктурированных участков. Чтобы такая связка не рассыпалась, команда должна уметь итеративно проверять гипотезы на нагрузке – здесь помогает Scrum в корпоративной разработке, а не водопадное проектирование схемы на год вперёд. Связать реляционное ядро, колоночную витрину и NoSQL в работающий контур – это уже подбор и интеграция хранилищ под профиль нагрузки, а не выбор одной модной базы.

Вывод

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