Access
 sql >> Baza danych >  >> RDS >> Access

Tworzenie i dostęp do baz danych i tabel OLTP w pamięci

To jest drugi artykuł z serii artykułów o SQL Server In-Memory OLTP.

Artykuł wprowadzający — SQL Server In-Memory OLTP, pokrótce przedstawił podstawy nowego silnika Hekaton. W tej części skupimy się na praktyce. Mówiąc dokładniej, zobaczymy, jak tworzyć bazy danych i tabele zoptymalizowane w pamięci, a także jak je oceniać za pomocą T-SQL.

Warunki wstępne, aby zacząć korzystać z baz danych zoptymalizowanych pod kątem pamięci

OLTP w pamięci jest automatycznie instalowany w 64-bitowej wersji Enterprise lub Developer programu SQL Server 2014 lub SQL Server 2016. 32-bitowa edycja programu SQL Server nie zapewnia składników OLTP w pamięci.

Tak więc, jeśli masz na swoim komputerze zainstalowaną 64-bitową edycję SQL Server dla programistów, możesz zacząć tworzyć bazy danych i struktury danych, które będą przechowywać dane zoptymalizowane pod kątem pamięci bez konfiguracji dodatków.

Każda pojedyncza baza danych, która będzie zawierać tabele zoptymalizowane pod kątem pamięci, powinna zawierać jedną grupę plików MEMORY_OPTIMIZED_DATA. Ta grupa plików zawiera jeden lub kilka kontenerów. Każdy kontener przechowuje dane i/lub pliki delta. SQL Server używa tych plików do odzyskiwania tabel zoptymalizowanych pod kątem pamięci. Kontenery mogą być umieszczane na różnych macierzach dyskowych,
podobnie do grup plików FILESTREAM.

Składnia tworzenia grupy plików zoptymalizowanej pod kątem pamięci jest prawie taka sama jak w przypadku tradycyjnej grupy plików FILESTREAM, z kilkoma różnicami:

  1. Tylko jedna grupa plików zoptymalizowana pod kątem pamięci może być utworzona dla bazy danych.
  2. Opcja CONTAINS MEMORY_OPTIMIZED_DATA musi być wyraźnie określona.

Możesz utworzyć grupę plików w trakcie tworzenia bazy danych:

CREATE DATABASE InMemoryDemo
ON PRIMARY
(
NAME = N'InMemoryDemo',
FILENAME = N'D:\Data\InMemoryOLTPDemo.mdf'
),
FILEGROUP IMOFG CONTAINS MEMORY_OPTIMIZED_DATA
(
NAME = N'InMemoryDemo_Data',
FILENAME = N'D:\IMOFG\InMemoryDemo_Data.mdf'
)

Alternatywnie możesz dodać grupę plików MEMORY_OPTIMIZED_DATA do istniejącej bazy danych, a następnie dodać pliki do tej grupy plików.

-- Adding the containers
ALTER DATABASE
  DemoDB ADD FILE
  (
  NAME = 'DemoDB_Mod',
  FILENAME = 'D:\Data\DemoDB_Mod'
  )
  TO FILEGROUP DemoDB_Mod

Wewnętrznie OLTP w pamięci wykorzystuje mechanizm przesyłania strumieniowego oparty na technologii FILESTREAM, która jest dobrze przystosowana do sekwencyjnego dostępu do we/wy.

Tworzenie tabel zoptymalizowanych pod kątem pamięci

Teraz mamy wszystko, czego potrzebujemy, aby rozpocząć tworzenie obiektów zoptymalizowanych pod kątem pamięci. Stwórzmy tabelę zoptymalizowaną pod kątem pamięci.

Składnia tworzenia tabel zoptymalizowanych w pamięci jest bardzo podobna do składni tworzenia tabel opartych na dyskach. Istnieje jednak kilka rozszerzeń i ograniczeń:

  1. Klauzula MEMORY_OPTIMIZED =ON identyfikuje tabelę jako zoptymalizowaną w pamięci.
  2. Tabele zoptymalizowane w pamięci nie obsługują wszystkich typów danych obsługiwanych przez tradycyjne tabele. Następujące typy danych nie są obsługiwane:
  • przesunięcie daty i godziny
  • geografia
  • geometria
  • hierarchiid
  • rowwersja
  • XML
  • wariant_sql
  • Typy zdefiniowane przez użytkownika

Tabelę zoptymalizowaną pod kątem pamięci można utworzyć z następującymi wartościami trwałości:SCHEMA_AND_DATA lub SCHEMA_ONLY. SCHEMA_AND_DATA to wartość domyślna.
W przypadku określenia SCHEMA_ONLY, wszystkie zmiany w tabeli nie będą rejestrowane, a dane tabeli nie są przechowywane na dysku.

Każda tabela zoptymalizowana pod kątem pamięci musi zawierać co najmniej jeden indeks. Należy zauważyć, że ograniczenie PRIMARY KEY niejawnie tworzy indeks. Trwała tabela zoptymalizowana pod kątem pamięci zawsze wymaga ograniczenia PRIMARY KEY.

CREATE TABLE dbo.Person (
  [Name] VARCHAR(32) NOT NULL PRIMARY KEY NONCLUSTERED
 ,[City] VARCHAR(32) NULL
 ,[Country] VARCHAR(32) NULL
 ,[State_Province] VARCHAR(32) NULL
 ,[LastModified] DATETIME NOT NULL
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

Indeksy złożone można dodać po utworzeniu wszystkich kolumn:

CREATE TABLE dbo.Person (
  [Name] VARCHAR(32) NOT NULL PRIMARY KEY NONCLUSTERED
 ,[City] VARCHAR(32) NULL
 ,[Country] VARCHAR(32) NULL
 ,[State_Province] VARCHAR(32) NULL
 ,[LastModified] DATETIME NOT NULL
 ,INDEX T1_INDX_C1C2 NONCLUSTERED ([Name], [City])
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

Podczas tworzenia tabeli zoptymalizowanej w pamięci aparat OLTP w pamięci tworzy procedury DML umożliwiające dostęp do tej tabeli. Ładuje procedury jako pliki DLL. Dla określonej operacji SQL Server wywołuje wymagany plik DLL.

Zmienianie tabel i indeksów

Zmiana tabel przed SQL Server 2016 była niemożliwa. Aby dokonać zmian w schemacie, trzeba było usunąć i odtworzyć tabelę w pamięci.

W nowej wersji SQL Server ALTER TABLE jest częściowo obsługiwana.

SQL Server 2016 zapewnia możliwość wykonywania operacji off-line:dodawania i usuwania (modyfikowania) kolumn, indeksów i ograniczeń. Ponadto możliwa jest teraz praca z tabelami w pamięci za pomocą projektanta tabel SSMS lub edytora tabel dbForge Studio dla SQL Server.

Zauważ, że ALTER TABLE wymaga przebudowy tabeli. Dlatego przed uruchomieniem tej operacji musisz upewnić się, że masz wystarczająco dużo pamięci. Podczas operacji przebudowy każdy wiersz jest ponownie wstawiany do nowej tabeli i tabela nie jest dostępna podczas wykonywania operacji ALTER.

Możesz wprowadzić wiele zmian do jednej tabeli i połączyć je w jedną instrukcję ALTER TABLE. Możesz DODAĆ kolumny, indeksy i ograniczenia oraz UPUŚĆ kolumny, indeksy i ograniczenia. Pamiętaj, że nie możesz łączyć poleceń ADD i DROP w jednej tabeli ALTER TABLE.

-- index operations
-- change hash index bucket count
ALTER TABLE dbo.TableName ALTER INDEX IX_Name REBUILD WITH (BUCKET_COUNT = 131072);
GO
-- add index
ALTER TABLE dbo.TableName ADD INDEX IX_Name NONCLUSTERED (ColName);
GO
-- drop index
ALTER TABLE dbo.TableName DROP INDEX IX_Name;
GO
-- add multiple indexes
ALTER TABLE dbo.TableName ADD INDEX IX_Name NONCLUSTERED (ColName),
 INDEX IX_Name2 NONCLUSTERED (ColName2);
GO
-- Add a new column and an index 
ALTER TABLE dbo.TableName ADD Date DATETIME, INDEX IX_Name NONCLUSTERED (ColName);
GO
-- Drop a column
ALTER TABLE dbo.TableName DROP COLUMN ColName;
GO

Typy tabel i zmienne tabel

SQL Server 2016 zapewnia możliwość tworzenia typów tabel zoptymalizowanych pod kątem pamięci, których można używać podczas definiowania zmiennej tabeli:

CREATE TYPE TypeName
AS TABLE (
Col1 SMALLINT NOT NULL,
Col2 INT NOT NULL,
Col3 INT NOT NULL,
Col4 INT NOT NULL,
INDEX IX_Col1 NONCLUSTERED HASH (Col1)
WITH (BUCKET_COUNT = 131072),
INDEX IX_Col1 NONCLUSTERED (Col2))
WITH (MEMORY_OPTIMIZED = ON);
GO
DECLARE @VariableName TypeName;
GO

Ta zmienna jest przechowywana tylko w pamięci. Tabele i typy tabel zoptymalizowane w pamięci wykorzystują te same struktury danych, więc dostęp do danych będzie bardziej wydajny w porównaniu do zmiennych tabel opartych na dyskach.

Aby uzyskać więcej informacji, zapoznaj się z następującym wpisem na blogu MSDN:Poprawa wydajności tabel tymczasowych i zmiennych tabel przy użyciu optymalizacji pamięci

Podsumowanie

In-Memory OLTP to stosunkowo młoda technologia zaprojektowana do pracy z ogromnymi i bardzo obciążonymi systemami OLTP, które obsługują setki, a nawet tysiące jednoczesnych użytkowników. Została wprowadzona w SQL Server 2014 i ewoluowała w SQL Server 2016.
Jednocześnie technologia ta zawiera szereg ograniczeń i ograniczeń.
Nie wszystkie funkcje T-SQL i typy danych obsługiwane przez pamięć- zoptymalizowane tabele, takie tabele nie mogą zawierać wierszy przekraczających 8060 bajtów, a także nie obsługują pamięci
ROW-OVERFLOW i LOB. Nie można zmieniać tabel i indeksów (w SQL Server 2014) po utworzeniu tabeli.
Pomimo tego spodziewamy się, że kolejne wersje In-Memory OLTP będą miały mniej ograniczeń!

Przeczytaj również:

Używanie indeksów w tabelach SQL Server zoptymalizowanych pod kątem pamięci


No
  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Nowe sterowniki dla SQL Server… Co musisz wiedzieć

  2. Łączenie się z Microsoft Access w IRI Workbench

  3. Jak zatrzymać lub kontrolować znaczniki sprawdzania błędów programu Microsoft Access

  4. Używanie dużych parametrów dla procedury składowanej Microsoft SQL z DAO

  5. Jaka jest różnica między Office 365 a Office 2016?