Структуры хранения #4 – Memory-optimized columnstore

Автор: Hugo Kornelis, Storage structures 4 – Memory-optimized columnstore;

Настало время для следующей части моей серии о структурах хранения. Предыдущие части охватывали дисковое хранение строк, колоночные индексы и оптимизированное для памяти хранение. В этой части я рассмотрю комбинацию двух последних: оптимизированные для памяти колоночные индексы.

Оптимизированные для памяти колоночные индексы были представлены в SQL Server 2016. За это время я видел несколько эффектных маркетинговых презентаций Microsoft, в которых много говорилось о «аналитике в реальном времени» (real-time operational analytics). Новая тенденция, согласно которой аналитическая обработка больше не должна выполняться на устаревшей копии данных в отдельном хранилище, а непосредственно в OLTP-базе данных. Отчёты всегда были бы полностью актуальными, необходимость в ETL-конвейере отпала бы, а благодаря сочетанию оптимизированных для памяти структур для OLTP-нагрузок и колоночных индексов для аналитической обработки всё всегда было бы быстро. В теории.

Я больше не слышал термин «аналитика в реальном времени» после первоначального выпуска SQL Server 2016. А начиная с внедрения SQL Server 2017, я не припомню, чтобы слышал от кого-либо из сотрудников Microsoft использование терминов «оптимизированный для памяти» и «колоночный» в одном докладе, не говоря уже об одном предложении.

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

Структуры хранения #3 – In-Memory OLTP

Автор: Hugo Kornelis, Storage structures 3 – Memory-optimized;

После обсуждения традиционного хранения строк на диске (rowstore) в части 1 и колоночных хранилищ (columnstores) в части 2, пришло время обратить наш взгляд в SQL Server на структуры хранения, оптимизированные для памяти.

Оптимизированное для памяти хранение было представлено в SQL Server 2014 в рамках проекта, который имел кодовое название «Hekaton» и позже был переименован в in-memory OLTP. В то время как колоночные индексы были специально нацелены на крупномасштабную аналитическую работу, Hekaton и оптимизированные для памяти таблицы специально предназначены для высоконагруженных OLTP-нагрузок. Полностью устраняя блокировки обычные и краткие и используя предварительно скомпилированный машинный код, где это возможно, время обработки транзакций значительно сокращается, что позволяет достичь пропускной способности, ранее недостижимой.

Название «оптимизированные для памяти» выбрано очень осознанно. Эта функция не просто заменяет дисковое хранилище на хранилище в памяти. Сама структура данных была полностью переработана, чтобы извлечь выгоду из скорости современной памяти и обеспечить безопасный параллельный доступ без использования блокировок или защёлок.

Обратите внимание, что оптимизированные для памяти колоночные индексы, доступные с SQL Server 2016, будут описаны в отдельной статье. Эта статья посвящёна оптимизированным для памяти индексам rowstore.