Таблицы, оптимизированные для памяти - их действительно сложно поддерживать?


18

Я исследую преимущества обновления с MS SQL 2012 до 2014 года. Одна из главных особенностей SQL 2014 - это оптимизированные для памяти таблицы, которые, очевидно, делают запросы очень быстрыми.

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

  • Нет (max)размеров полей
  • Максимум ~ 1 КБ на строку
  • Нет timestampполей
  • Нет вычисляемых столбцов
  • Нет UNIQUEограничений

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

Настоящим ударом является тот факт, что вы не можете выполнить ALTER TABLEоператор, и вам приходится проходить через эту проверку каждый раз, когда вы просто добавляете поле в INCLUDEсписок индекса. Более того, похоже, что вам необходимо отключить пользователей от системы, чтобы внести какие-либо изменения в схемы таблиц MO в действующей БД.

Я нахожу это совершенно возмутительным, поскольку я действительно не могу поверить, что Microsoft могла бы инвестировать так много капитала для разработки в эту функцию и сделать ее поддержку настолько непрактичной. Это приводит меня к выводу, что я, должно быть, получил неправильный конец палки; Должно быть, я неправильно понял что-то об оптимизированных для памяти таблицах, что заставило меня поверить, что поддерживать их гораздо сложнее, чем есть на самом деле.

Итак, что я неправильно понял? Вы использовали таблицы МО? Есть ли какой-то секретный переключатель или процесс, который делает их практичными в использовании и обслуживании?

Ответы:


18

Нет, в памяти это на самом деле не отполировано. Если вы знакомы с Agile, вы будете знакомы с понятием «минимальный продукт для отправки»; в памяти это то. У меня такое чувство, что MS нуждался в ответе на Hana SAP и тому подобное. Это то, что они могли отладить в сроки выпуска 2014 года.

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


SQL Server 2016 теперь общедоступен. Как я и предполагал, In-Memory OLTP получил ряд улучшений. Большинство изменений реализуют функциональность, которой традиционные таблицы пользовались в течение некоторого времени. Я предполагаю, что будущие функции будут выпущены одновременно как для оперативной памяти, так и для традиционных таблиц. Временные таблицы являются показательным примером. Новое в этой версии поддерживается таблицами в памяти и на диске .


14

Одна из проблем с новой технологией - особенно релизом V1, который довольно громко был раскрыт как не полный функций - заключается в том, что каждый запрыгивает на подножку и полагает, что он идеально подходит для любой рабочей нагрузки. Это не. Преимущество Hekaton - рабочие нагрузки OLTP до 256 ГБ с множеством точечных поисков на 2-4 сокетах. Это соответствует вашей рабочей нагрузке?

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

Очевидно, вам необходимо проверить, является ли прирост производительности значительным в вашей среде, и если да, то стоит ли компромиссы. Если вы получаете значительный прирост производительности из таблиц в памяти, я не уверен, почему вы беспокоитесь о том, какое количество обслуживания вы собираетесь выполнять для столбцов INCLUDE. Ваши индексы в памяти по определению покрывают. Они действительно могут быть полезны для избежания поиска по диапазону или полного сканирования традиционных некластеризованных индексов, и эти операции не должны выполняться в таблицах в памяти (опять же, вам следует профилировать свою рабочую нагрузку и посмотреть, какие операции улучшаются а что нет - не все беспроигрышно). Как часто вы гадите с колонками INCLUDE в ваших индексах сегодня?

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

SQL Server 2016

Если вы приближаетесь к SQL Server 2016, я написал в блоге об улучшениях, которые вы увидите в In-Memory OLTP, а также об устранении некоторых ограничений . Наиболее заметно:

  • Увеличение максимального размера таблицы: 256 ГБ => 2 ТБ
  • Столбцы LOB / MAX, индексы на обнуляемые столбцы, устранение требований сортировки BIN2
  • Изменить и перекомпилировать процедуры
  • Некоторая поддержка ALTER TABLE - он будет в автономном режиме, но вы сможете изменять и / или удалять / заново создавать индексы (однако, это не поддерживается в текущих сборках CTP, поэтому не принимайте это как гарантию)
  • Триггеры DML, ограничения FK / check, MARS
  • ИЛИ, НЕ, В, СУЩЕСТВУЕТ, ОТЛИЧАЕТСЯ, СОЮЗ, ВНЕШНИЕ СОЕДИНЕНИЯ
  • параллелизм

Я использовал столбцы «включить» в качестве примера тривиального изменения, которое мне, возможно, придется внести, но теперь я узнал от вас, что это не очень хороший пример. Более уместным является, например, добавление новых столбцов, которые могут иметь значение NULL, что является очень неразрушающим действием в обычной таблице, но будет очень обременительным для таблиц MO. Поскольку система, над которой мы работаем, постоянно расширяется (наши запросы на функции конкурируют по количеству с сообщениями об ошибках), это, вероятно, станет для нас убийцей.
Шаул Бер

3
@ шал хорошо, так что не используйте его. Или только положить стабильные таблицы в память. Или рассмотрите другой дизайн, в котором вы постоянно добавляете столбцы (EAV). На самом деле, я думаю, вы просто ругаетесь, что эта технология не для вас. У меня есть дети, поэтому я не жалуюсь, что Porsche Cayman S для меня не практичен или, по крайней мере, не ежедневный водитель. Может быть, я мог бы использовать его по выходным (точно так же, как вы могли бы использовать OLTP в памяти для частей вашей схемы, но не для всего). Тот факт, что у вас есть не столь распространенные требования и которые конфликтуют с функциями V1, не является ошибкой Microsoft.
Аарон Бертран

Аарон, что такое EAV?
Шаул Бер


2

Вы не можете щелкнуть правой кнопкой мыши таблицу, оптимизированную для памяти, чтобы открыть конструктор и добавить новые столбцы по своему усмотрению из Sql Server Management Studio. Вы также не можете щелкнуть внутри имени таблицы как средство переименования таблицы. (SQL 2014 на момент написания этой статьи.)

Вместо этого вы можете щелкнуть правой кнопкой мыши таблицу и написать команду create для нового окна запроса. Эта команда создания может быть изменена путем добавления любых новых столбцов.

Таким образом, чтобы изменить таблицу, вы можете сохранить данные в новой таблице, временной таблице или табличной переменной. Затем вы можете удалить и заново создать таблицу с новой схемой и, наконец, скопировать обратно фактические данные . Эта игра из 3 контейнерных оболочек является чуть менее удобной для большинства случаев использования.

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

Затем вам придется взвесить, если ограничения и обходные пути того стоят для вашего варианта использования. У вас есть проблемы с производительностью? Вы пробовали все остальное? Повысит ли это вашу производительность в 10-100 раз? Использовать его или не использовать его, скорее всего, в любом случае будет немного проще.


-2

Вы можете использовать In-Memory OLTP в операционных серверах без каких-либо серьезных проблем. мы использовали эту технологию в банковской и платежной компании,

В общем, мы можем использовать оптимизированные для памяти таблицы, когда рабочая нагрузка слишком высока. с помощью In-Memory OLTP вы можете достичь более высокой производительности в 30 раз! Microsoft исправляет большинство этих ограничений в SQL Server 2016 и 2017. Оптимизированные для памяти таблицы имеют совершенно другую архитектуру по сравнению с таблицами на основе дисков.

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

Вы можете использовать эти электронные книги и узнать, как использовать эту технологию:

Кален Делани: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Дмитрий Короткевич: https://www.apress.com/gp/book/9781484227718

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.