OLTP против OLAP

Допустим, вы решили создать клон Facebook. Вы и ваш сосед по комнате работаете несколько недель, чтобы запустить приложение. Все выглядит отлично, у вас более 100 пользователей (включая вашу любовь из вводного курса биологии). Затем в один прекрасный день отключается электричество. Вы снова запускаете приложение и обнаруживаете, что все данные исчезли. Вы проводите небольшое исследование и обнаруживаете, что хранение пользовательских данных в словаре Python, вероятно, было не лучшей идеей. Итак, вы используете реляционную базу данных для сохранения ваших данных. Перенесемся на несколько месяцев вперед, и ваша пользовательская база вырастет в геометрической прогрессии. Вы обращаетесь к своему другу, специализирующемуся на маркетинге, с просьбой разместить рекламу на вашем веб-сайте. Друг, о котором идет речь, говорит о том, что вы должны выбирать рекламу на основе демографических данных пользователей. Как говорится, нет смысла размещать рекламу сливового сока, если все ваши пользователи — бедные студенты. Достаточно просто, говорите вы себе, я просто запущу SQL-запрос, чтобы получить средний возраст. Проходит минута... Затем еще одна, и еще... Вы уже готовы сдаться, когда получаете гневную жалобу от пользователя на то, что он вечно загружает фотографию своего кота. Вы решаете, что самое простое — это купить сервер побольше. Перенесемся еще на несколько месяцев вперед, и вы попытаетесь выполнить более сложные запросы (некоторые из которых занимают часы), заполнить несколько информационных панелей и тому подобное. Скорость вашего сайта снижена до минимума, и вы рискуете потерять всех своих пользователей.

К счастью, ваш мальчик, Мартин Фаулер, приезжает, чтобы выступить с докладом в вашей школе. После этого вы подходите к нему и спрашиваете его совета.

Он говорит:

Нет, падван, ты все делаешь не так…

Большинство EnterpriseApplications хранят постоянные данные в базе данных. Эта база данных поддерживает оперативные обновления состояния приложения, а также различные отчеты, используемые для поддержки принятия решений и анализа. Однако операционные потребности и потребности в отчетности часто сильно различаются — с разными требованиями схемы и разными шаблонами доступа к данным. Когда это происходит, часто имеет смысл разделить потребности в отчетах в базе данных отчетов, которая берет копию основных операционных данных, но представляет их в другой схеме.

Вы отвечаете:

Теперь я понимаю, зачем нужна отдельная база данных, то есть запросы, выполняемые к базе данных отчетов, не добавляют нагрузки на рабочую базу данных, но зачем другая схема?

Непогрешимый сенсей отвечает:

На практике хранение дешево, но время аналитика дорого.

В приведенном выше примере операционная база данных, в которой хранятся данные, используемые клоном Facebook, является примером системы OLTP, тогда как база данных отчетов является примером системы OLAP.

Обработка онлайн-транзакций

Онлайн-обработка транзакций (OLTP) характеризуется большим количеством ACID-совместимых CRUD-транзакций (создание, чтение, обновление, удаление).

Производительность системы OLTP измеряется количеством транзакций в секунду.

Системы OLTP можно использовать для хранения таких вещей, как покупки, бронирования или, как в нашем примере, сообщения пользователей.

Если вы когда-либо посещали курс «Введение в базы данных», скорее всего, вы проектировали базы данных для поддержки транзакций OLTP. Это связано с тем, что на практике, в отличие от систем OLAP, схемы базы данных OLTP находятся в 3-й нормальной форме (3NF).

Базы данных, ориентированные на строки, хорошо подходят для систем OLTP. Предположим, что клиент заказал пару носков на Amazon. Нам нужно создать новую запись в нашей таблице Orders. Предполагая, что мы использовали жесткий диск в качестве вторичного хранилища, поскольку данные хранятся в базе данных, ориентированной на строки, мы могли бы последовательно записывать каждый столбец строки (например, номер заказа, количество и т. д.) на диск. Таким образом, избегая подъема головы для записи данных в другой сектор, что имело бы место в базе данных, ориентированной на столбцы.

Аналитическая обработка онлайн

Онлайн-аналитическая обработка (или сокращенно OLAP) характеризуется относительно небольшим объемом транзакций только для чтения.

Мы количественно оцениваем производительность системы OLAP по времени ответа на запрос.

Данные в системах OLAP получены из систем OLTP. Другими словами, нередко создаются новые таблицы, запрашивая базу данных OLTP через определенные промежутки времени.

База данных OLAP хранит свои данные с использованием звездообразных схем. Не вдаваясь в подробности, схемы типа «звезда» не находятся в 3-й нормальной форме (3NF), потому что основная задача систем OLAP заключается в упрощении (т. е. меньшем количестве объединений) анализа данных.

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

Заключение

Давайте соберем все это вместе, мы обсудили 4 основных различия между системами OLTP и OLAP:

Запросы

  • OLTP: простой CRUD
  • OLAP: сложные агрегаты

Производительность

  • OLTP: транзакции/единица времени
  • OLAP: единица времени/количество записей

Ориентация

  • OLTP: ориентированный на строки
  • OLAP: ориентированный на столбцы

Схема

  • OLTP: модель объекта в 3NF
  • OLAP: схема «звезда»

Ресурсы