Александр Пузаков1C начиная с версии 8.3.5 поддерживает работу с SQL Server 2014.
Однако, это вовсе не значит, что 1С поддерживает работу с In-Memory OLTP вообще, и тем более, в объеме, который позволился бы ускориться на порядки раз.
Нужно понимать основную идею In-Memory OLTP: для того чтобы ускорить работу в сотни раз недостаточно просто разместить данные в памяти (часто можно видеть ситуацию: вся или значимая часть базы в буфере, однако особого ускорения на порядки не наблюдается); разработчики пошли по пути изменения идеологии работы движка (можно наверное говорить, об его упрощении, хотя это не совсем так).
А изменение идеологии движка требует изменение и идеологии клиентского приложения (в данном случае 1с). На текущий момент я вижу как минимум следующие существенные моменты:
1. Очень много времени теряется на обслуживание механизма латчей и блокировок, которые необходимы при конкурентном доступе к данным, расположенным на медленном носителе (дисках). Однако, если данные расположены в памяти, необходимость в латчах и блокировках _почти_ пропадает, по этому было решено от них отказаться. "Почти" - потому что при конкурентной записи одних и тех же данных механизм блокировок все-таки требуется. Так как в In-Memory OLTP в sql2014 нет блокировок, то второй и последующие клиенты, пытающиеся изменить один и тот же набор данных получат не ожидание на блокировке, а отказ выполнения запроса (откат транзакции).
Клиентское приложение должно быть перепроектировано с учетом логики работы нового движка sql-сервера (например, в этом случае приложение может повторить запрос после какого-то таймаута).
2. Интерпретатор плана выполнения запроса был вполне терпим по сравнению с задержками, связанными с медленными носителями, но когда данные находятся в памяти - издержки на интерпритацию становятся слишком заметны в общей структуре выполнения запроса, по этому в Hekaton введен механизм компиляции T-SQL в машинный код, который выполняется на стороне SQL-сервера. Однако нужно понимать что этот сценарий предполагает прекомпиляцию в виде хранимых процедур. Я не смотрел тесты, но я думаю что врядли можно как-то исхитриться и получить какой-либо выигрыш при компиляции в момент исполнения (для меня на текущий момент вообще не факт что это можно реализовать). Но зато прекомпилированный код дает выигрыш в 100 и более раз по сравнению с интерпретацией.
3. В in-memory таблице primary key строится по хэшу и для оптимальной работы следует сразу (при создании таблицы) определить количество уникальных значений ключа хотя бы с точностью до одного порядка. Ошибка в большую или меньшую сторону - это потеря производительности (не такая существенная как в предыдущих двух случаях, но тоже приличная). Исправление "ошибки", на сколько я понимаю, только через пересоздание таблицы. Как вы думаете, "угадает" ли 1с-платформа сколько у вас, к примеру, должно быть записей в Справочнике.Номенклатура?
4. LOB'ы в In-memory таблице хранить нельзя в принципе. Есть выход хранить lob не в in-memory, а в обычной таблице и делать JOIN, то тогда получим не компилированный, а интерпретируемый код выполнения запроса с соответствующей деградацией производительности.
Поправьте меня, если я не прав, но на сколько я понимаю, ни один из вышеприведенных моментов на текущий момент платформа 1с не учитывает и поддержка SQL 2014 сводится к тому, что привел sza (
15268123 ), т.е. плюс-минус получаем ту же производительность что и на SQL 2012.
