Статьи

В памяти OLT P (Таблица оптимизатора памяти) В SQL 2014

Март 26, 2018

Вступление

SQL 2014 поставляется с некоторыми удивительными функциями, о которых я расскажу в своем блоге. Одна из интересных функций — In Memory OLTP (Таблица оптимизатора памяти).

В этой статье мы пытаемся узнать об этом. Надеюсь, это будет интересно и информативно.

Что это?

Microsoft выпускает SQL Server 2014 с новым набором функций OLTP в памяти, которые значительно повышают производительность OLTP и сокращают время обработки для серверов с большим объемом памяти и многоядерных процессоров.

В памяти OLTP — это новая технология, представленная Microsoft, чтобы снизить нагрузку на OLTP и обеспечить значительное улучшение обработки. Повышение производительности также зависит от имеющегося у нас оборудования и от того, как мы пишем наш запрос. С помощью этой технологии мы в полной мере используем современные тенденции в оборудовании и требования современных приложений.

SQL Server обычно предназначен для сохранения данных на диске и загрузки данных в память для обслуживания запроса, сделанного Запросом. Это сделано для управления ресурсами, так как это довольно дорого.

В настоящее время стоимость аппаратного обеспечения довольно низкая, и мы можем управлять сервером с огромным REM и многоядерным процессором, и на нем работает новая функция Microsoft под названием In Memory OLTP.

Функции OLTP в памяти — это новый компонент ядра базы данных, который полностью интегрирован в SQL Server и работает параллельно с традиционным ядром базы данных. Это позволяет нам объявлять таблицу для хранения в основной памяти, чтобы ваша рабочая нагрузка OLTP могла быстрее получать доступ к этим резидентным данным в памяти.

В таблице, оптимизированной для памяти, все данные хранятся в памяти, а не на диске.

Тип памяти Оптимизировать таблицу

Существует два типа таблицы оптимизации памяти

1.   SCHEMA_AND_DATA

2.   SCHEMA_ONLY

SCHEMA_AND_DATA:

Таблица SCHEMA_AND_DATA, оптимизированная для памяти, представляет собой таблицу, которая находится в памяти, где данные доступны после сбоя сервера, завершения работы или перезапуска SQL Server.

Использование: Данные транзакции торговой точки могут хорошо подходить для таблицы типов SCHEMA_AND_DATA. Мы могли бы хотеть, чтобы наши транзакции в точках продаж выполнялись как можно быстрее, чтобы таблица типов оптимизации памяти обеспечивала это, но мы не хотели бы потерять эти транзакции, если наш сервер будет перезапущен.

SCHEMA_ONLY

 SCHEMA_ONLY Таблица, оптимизированная для памяти, — это таблица, в которой не сохраняются данные в случае сбоя SQL Server или остановки или перезапуска экземпляра. Таблицы, оптимизированные для памяти SCHEMA_ONLY, сохраняют свою структуру таблиц в случае сбоя сервера или его остановки.

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

Ведение версии в строках

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

,

Как мы это сделаем?

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

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

IF EXISTS (SELECT *
           FROM   sys.databases
           WHERE name = N'InMemoryExample'
)
  DROP DATABASE InMemoryExample;
GO

CREATE DATABASE InMemoryExample
ON PRIMARY
  (NAME = InMemory_Data,
   FILENAME = N'C:\data\InMemoryExample_Data.mdf',
   SIZE = 100MB,
   FILEGROWTH = 10MB),
FILEGROUP InMemoryExample_InMemory CONTAINS MEMORY_OPTIMIZED_DATA
  ( NAME = InMemory_InMemory,
    FILENAME = N'C:\data\InMemoryExample_InMemory.mdf')

LOG ON
  ( NAME = InMemoryExample_Log,
    FILENAME = N'C:\data\InMemoryExample_Log.ldf',
    SIZE = 100MB,
    FILEGROWTH = 10MB)

GO

Сценарий выглядит так же. Пожалуйста, внимательно ознакомьтесь со сценарием, единственные различия, которые мы находим, 

 FILEGROUP InMemoryExample_InMemory CONTAINS MEMORY_OPTIMIZED_DATA
  ( NAME = InMemory_InMemory,
    FILENAME = N'C:\data\InMemoryExample_InMemory.mdf')

Мы создали FILEGROUP с именем «InMemoryExample_InMemory», который будет использоваться для поддержки наших таблиц, оптимизированных для памяти. Эта файловая группа содержит один файл. Без этой файловой группы «MEMORY_OPTIMIZED_DATA» я не смог бы создать таблицу с оптимизированной памятью в нашей новой базе данных.

Шаг 2 [Создание таблицы, оптимизированной для памяти]

Здесь мы собираемся создать два типа таблицы, оптимизированной для памяти. Таблица SCHEMA_AND_DATA: 

 IF  OBJECT_ID('MemoryOptimized_Schema_And_Data','U') IS NOT NULL
    DROP TABLE MemoryOptimized_Schema_And_Data
GO

CREATE TABLE MemoryOptimized_Schema_And_Data
(
       Id    INT        NOT NULL,
       Col1  CHAR(1000) NOT NULL,
       CONSTRAINT PK_MemoryOptimized_Schema_And_Data
        PRIMARY KEY NONCLUSTERED HASH (Id)
        WITH (BUCKET_COUNT = 1024)
) WITH (MEMORY_OPTIMIZED = ON,
        DURABILITY = SCHEMA_AND_DATA);

SCHEMA_ONLY Таблица: 

 IF  OBJECT_ID('MemoryOptimized_Schema_Only','U') IS NOT NULL
    DROP TABLE MemoryOptimized_Schema_Only
GO

CREATE TABLE MemoryOptimized_Schema_Only
(
       Id     INT        NOT NULL,
       Col1   CHAR(1000) NOT NULL,
       CONSTRAINT PK_MemoryOptimized_Schema_Only
        PRIMARY KEY NONCLUSTERED HASH (Id)
        WITH (BUCKET_COUNT = 1024)
) WITH (MEMORY_OPTIMIZED = ON,
        DURABILITY = SCHEMA_ONLY);

Теперь мы должны это понять. Пожалуйста, внимательно посмотрите на часть сценария. 

 CONSTRAINT PK_MemoryOptimized_Schema_Only
        PRIMARY KEY NONCLUSTERED HASH (Id)
        WITH (BUCKET_COUNT = 1024)

Здесь мы создаем неклассифицированный хэш-индекс для идентификатора столбца. Для таблицы, оптимизированной для памяти, требуется индекс HASH. Он не может превышать 8. Для CTP1 для индекса HASH могут использоваться только столбцы с типами сортировки Windows BIN2. Поэтому в нашей таблице мы просто создаем индекс HASH для столбца INT, а не столбца char.

Второе — это BUCKET_COUNT. BUCKET_COUNT определяет количество различных сегментов, которые SQL Server будет создавать в памяти для хранения записей моей таблицы, оптимизированной для памяти. Каждый сегмент идентифицируется значением, созданным при хешировании столбца индекса. Каждое уникальное значение ключа индекса, имеющее одинаковое значение хеш-функции, будет храниться в одном и том же сегменте. Поэтому рекомендуется создать значение сегмента, равное или превышающее количество уникальных значений ключа, которые мы ожидаем для вашей таблицы с оптимизированной памятью.

Таблицы, оптимизированные для памяти, поддерживают только следующие типы данных : bit, tinyint, smallint, int, bigint, money, smallmoney, float, real, datetime, smalldatetime, datetime2, date, time, numberic, decimal, char (n), varchar ( n), nchar (n), nvarchar (n), sysname, binary (n), varbinary (n) и уникальный идентификатор . Обратите внимание, что ни один из больших типов данных бинарных объектов не допускается, даже переменные символьные типы данных «max». Стоит также упомянуть, что общая длина записи не должна превышать 8060. Это ограничение длины записи будет применяться при создании нашей таблицы. Шаг 3 [Вставка данных в таблицу, оптимизированную для памяти] 

 SET NOCOUNT ON;

USE InMemoryExample;
GO

DELETE FROM MemoryOptimized_Schema_And_Data;
DELETE FROM MemoryOptimized_Schema_Only;

SET STATISTICS IO Off;
SET STATISTICS TIME Off;

DECLARE @s datetime = getdate()

-- Load Normal Table
DECLARE @I int = 0;
WHILE @I < 1000
BEGIN
       SET @I+=1;
       INSERT INTO Normal(Id,C1)
       VALUES (@i,cast(@I as varchar(4)) + 'A');
END;

SELECT DATEDIFF(ms,@s,getdate()) as Normal;

-- Load SchemaAnadData table --
SET @s = getdate();
SET @I = 0;
WHILE @I < 1000
BEGIN
       SET @I+=1;
       INSERT INTO MemoryOptimized_Schema_And_Data
               (Id, Col1)
        VALUES (@i,cast(@I as varchar(4)) + 'A');
END;

SELECT DATEDIFF(ms,@s,getdate()) as SchemaAndData;

-- Load SchemaOnly table
SET @s = getdate();
SET @I = 0;
WHILE @I < 1000
BEGIN
       SET @I+=1;
       INSERT INTO MemoryOptimized_Schema_Only
               (Id, Col1)
        VALUES (@i,cast(@I as varchar(4)) + 'A');
END;
SELECT DATEDIFF(ms,@s,getdate()) As SchemaOnly;
GO

Некоторые ограничения

  • НЕТ оператора TRUNCATE TABLE для моих таблиц, оптимизированных для памяти.
  • НЕТ оператора ALTER TABLE против моих таблиц, оптимизированных для памяти.
  • НЕТ ОБНОВЛЕНИЯ столбцов первичного ключа моих таблиц, оптимизированных для памяти.
  • НЕТ ИНОСТРАННЫХ КЛЮЧЕЙ или ПРОВЕРКИ.
  • НИКАКИХ УНИКАЛЬНЫХ ограничений кроме ПЕРВИЧНОГО КЛЮЧА.

Надеюсь, вам понравится.

52
Share: