Комментарии 7
Лучше сначала про ограничения напишите, которые накладываются на таблицы и хранимые процедуры при работе в in-memory OLTP. На синтетических тестах прирост действительно хороший получается, но не каждую реальную таблицу и процедуру можно без изменений в in-memory загнать.
Да, ссылка на msdn годная )
Как заявили на презентации продукта, ограничений пока чуть больше, чем много. Но, это полноценная версия, соответственно многие ограничения с течением времени будут сняты. Общая ссылка на ограничения в конструкциях, типах и т.д. msdn.microsoft.com/en-us/library/dn246937
Ссылка, которую Вы привели, дана в статье.
«Существуют ограничения на типы используемых полей. Подробно прочитать о них можно здесь».
Мне следовало написать явный URL? Не работают гиперлинки?
«Существуют ограничения на типы используемых полей. Подробно прочитать о них можно здесь».
Мне следовало написать явный URL? Не работают гиперлинки?
>Лучше сначала про ограничения напишите
Я написал про ограничения. Читайте внимательнее.
«Вообще таблицы в памяти имеют тучу ограничений. Не поддерживается большинство табличных хинтов: Нет TABLOCK, XLOCK, PAGLOCK,… На NOLOCK не ругается, но и не реагирует, как будто его и нет. Динамические и keyset-курсоры молчаливо переводятся в static. Не поддерживаются операторы TRUNCATE TABLE и MERGE (когда таблица в памяти выступает назначением). Существуют ограничения на типы используемых полей. Подробно прочитать о них можно здесь»
Чем Вы недовольны? Мне нужно было сделать копи-пасту из документации, ссылку на которую я привел? Но статья все-таки посвящена обзору Гекатона, а не его ограничениям.
Я написал про ограничения. Читайте внимательнее.
«Вообще таблицы в памяти имеют тучу ограничений. Не поддерживается большинство табличных хинтов: Нет TABLOCK, XLOCK, PAGLOCK,… На NOLOCK не ругается, но и не реагирует, как будто его и нет. Динамические и keyset-курсоры молчаливо переводятся в static. Не поддерживаются операторы TRUNCATE TABLE и MERGE (когда таблица в памяти выступает назначением). Существуют ограничения на типы используемых полей. Подробно прочитать о них можно здесь»
Чем Вы недовольны? Мне нужно было сделать копи-пасту из документации, ссылку на которую я привел? Но статья все-таки посвящена обзору Гекатона, а не его ограничениям.
В целом всё замечательно, статья хорошая и ссылка на msdn действительно отвечает на все вопросы по ограничениям. Я недоволен тем, что большинство статей про Hekaton напоминают рекламу со звездочками на билбордах — «Небольшие квартиры всего за 2,5 миллиона», а ниже мелким шрифтом «Площадь 10 м2». Читаешь, пробуешь воспроизвести примеры — действительно работает, не наврали. А как попытаешься внедрить, понимаешь что с текущей схемой данных на production эту технологию применить нельзя. (слишком маловата квартирка в 10м2).
IDENTITY, Computed columns, constraints — для многих это базовые потребности.
Я понимаю что технология in-memory OLTP может эффективно применяться для определенного рода задач, в которых эти ограничения не являются ключевыми. К примеру staging таблицы в ETL или хранение фиксированных справочников. Именно про это и хочется прочитать, каковы реальные сценарии использования Hekaton с учетом всех его ограничений?
IDENTITY, Computed columns, constraints — для многих это базовые потребности.
Я понимаю что технология in-memory OLTP может эффективно применяться для определенного рода задач, в которых эти ограничения не являются ключевыми. К примеру staging таблицы в ETL или хранение фиксированных справочников. Именно про это и хочется прочитать, каковы реальные сценарии использования Hekaton с учетом всех его ограничений?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
In-Memory OLTP в SQL Server 2014. Часть I