В памяти Олтп хэш-индекс против не кластеризованных

Question

Таблицы памяти SQL 2014 поддерживают два типа индексов: хэш-не кластеризованный и не кластеризованный. Поскольку таблицы, оптимизированные для памяти, не хранятся в виде строк, нам нужен один индексный компилятор. Ниже приведен синтаксис для создания хэш-индекса

CREATE TABLE dbo.sample_memoryoptimizedtable_Hash
(
 c1 int NOT NULL,
 c2 float NOT NULL,
 c3 decimal(10, 2) NOT NULL
CONSTRAINT PK_sample_memoryoptimizedtable_Hash **PRIMARY KEY NONCLUSTERED HASH**
(
 c1 
)WITH ( BUCKET_COUNT = 1024)
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )
GO

Выше оператор создает хеш-индекс и сохраняет соответствующие строки в свои сегменты. Букеты содержат указатели на адрес памяти данных.

Но когда мы создаем некластеризованный индекс с определением ниже

CREATE TABLE dbo.sample_memoryoptimizedtable_Range
(
 c1 int NOT NULL,
 c2 float NOT NULL,
 c3 decimal(10, 2) NOT NULL
CONSTRAINT PK_sample_memoryoptimizedtable_Range PRIMARY KEY NONCLUSTERED 
(
 c1 ASC
) 
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )
GO

Как хранится вышеупомянутый индекс, хранится ли он в виде B-дерева, поскольку этот индекс не хешируется, а таблицы, индексы воссоздаются при запуске. Как SQL хранит данные.

Ниже приведены лучшие ссылки и мой анализ на данный момент.

http://www.mssqltips.com/sqlservertip/3099/understanding-sql-server-memoryoptimized-tables-hash-indexes/

Answer 1

"Некластеризованные" индексы, на которые вы ссылаетесь, на самом деле являются индексами Range. И индексы Hash, и Range являются некластеризованными, и в таблицах OLTP в памяти нет "кластеризованных" индексов (первичный ключ принудительно реализуется как кластерный хэш-индекс). Индексы диапазона реализуются с помощью модифицированных B-деревьев, и вы можете прочитать больше о базовых деталях обоих в техническом документе sigmod по адресу http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf