Özelleştirilmiş tablo türlerini kullanma

Tamamlandı

SQL Server, standart disk tabanlı tabloların ötesinde belirli senaryolar ve iş yükleri için tasarlanmış özel tablo türlerini destekler. Bellek içi, zamansal, dış, LEDGER ve GRAPH gibi bu tablo türleri, standart tabloların verimli bir şekilde ele alınamadığını belirli performans, uyumluluk veya mimari zorlukları çözer.

Bu özelleştirilmiş tablo türlerinin ne zaman ve nasıl kullanılacağını anlamak, uygulamanızın gereksinimlerini karşılayan etkili veritabanı çözümleri tasarlamak için çok önemlidir.

Bellek içi iyileştirilmiş tablolar kullanma

Geleneksel disk tabanlı tablolar, önbelleğe alma olsa bile disk I/O'dan kaynaklanan gecikmeye neden olur. Milisaniyelik yanıt sürelerine sahip saniyede binlerce işlem gibi yüksek hız gerektiren senaryolarda disk gecikme süresi performans sorununa dönüşür. Bellek içi tablolar, verileri tamamen RAM'de kilitsiz, iyimser eşzamanlılık ile tutarak bunu ortadan kaldırır.

Bellek içi tabloların ne zaman kullanılacağını anlama

Bellek içi iyileştirilmiş tablolar , belirli iş yükleri için önemli performans avantajları sağlar:

  • Oturum durumu depolama - Milyonlarca eşzamanlı oturuma sahip web uygulamaları
  • Gerçek zamanlı analiz - Mikrosaniye gecikme süresi gerektiren finansal ticaret sistemleri
  • Yüksek frekanslı OLTP - 10.000'den fazla işlemi/saniyeyi işleyen sipariş işleme sistemleri
  • Önbelleğe alma katmanı - Sık erişilen başvuru verileri (ürün katalogları, yapılandırmalar)
  • Hazırlama tabloları - Yoğun ekleme/güncelleştirme işlemlerine sahip ETL işlemleri

Örneğin, bir e-ticaret sitesi, alışveriş sepeti verileri için bellek içi tablolar kullanarak 50.000 eşzamanlı sepeti milisaniyenin altında yanıt süresiyle işleyerek ödeme gecikme süresini 80%azaltır.

Dengeleri göz önünde bulundurun

Bellek içi tablolar daha hızlı erişim için gerçek tablo verilerini RAM'de depolarken, geleneksel tablolar verileri diskte depolar. Ancak, veri boyutu kullanılabilir RAM ile sınırlıdır ve bu tablolar , VARCHAR(MAX)veya NVARCHAR(MAX)gibi VARBINARY(MAX)büyük nesne türlerini desteklemez.

Tablo verileri bellekte yer alsa da SQL Server, dayanıklılık sağlamak için işlem günlüklerini diske yazmaya devam eder. Başka bir deyişle, sunucu yeniden başlatılırsa kaydedilmiş işlemleri kaybetmezsiniz; veriler işlem günlüğünden belleğe geri kurtarılır.

seçeneğini kullanarak MEMORY_OPTIMIZED = ON bellek içi iyileştirilmiş bir tablo oluşturabilirsiniz. Bir örnek aşağıda verilmiştir:

-- Create in-memory optimized table
CREATE TABLE dbo.OrderCache (
    OrderID INT PRIMARY KEY NONCLUSTERED,
    CustomerID INT,
    OrderDate DATETIME2,
    Amount DECIMAL(10,2),
    INDEX IX_CustomerID NONCLUSTERED (CustomerID)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

Zamana bağlı tabloları kullanma

Zamana bağlı tablolar , veri değişikliklerinin tam geçmişini otomatik olarak izler. Bir satırı güncelleştirdiğinizde veya sildiğinizde, SQL Server önceki sürümü otomatik olarak bağlı bir geçmiş tablosunda depolar ve bu sürümün ne zaman geçerli olduğunu gösteren zaman damgaları gösterir. Bu saydam bir şekilde gerçekleşir; normal INSERT, UPDATEve DELETE deyimlerini kullanarak verileri değiştirirsiniz ve veritabanı altyapısı sürüm oluşturma işlemini işler.

En önemli avantaj, verileri herhangi bir zamanda mevcut olduğu gibi sorgulamaktır. Karmaşık denetim tablolarını korumadan veya özel sürüm oluşturma mantığı yazmadan "bu çalışanın 1 Ocak 2025'teki maaşı neydi?" veya "geçen çeyrekte stokta olan tüm ürünleri göster" sorusunu sorabilirsiniz.

Zamana bağlı tablolar uyumluluk, sorun giderme ve analitik gereksinimlere hizmet ediyor:

  • Uyumluluk ve denetim - Tam değişiklik geçmişi gerektiren finansal kayıtlar
  • Sorun giderme - Tartışmalı işlemlerin gerçekleştiği sırada hesap bakiyelerini araştırma
  • Eğilim analizi - Ürün fiyatlarının üç aylık dönemler içinde nasıl değiştiğini analiz etme
  • Veri kurtarma - Yedeklemeleri geri yüklemeden yanlışlıkla güncelleştirmeleri geri döndürme
  • Yavaşça değişen boyutlar - Veri ambarı Tür 2 boyutları otomatik

Yaygın iş senaryoları arasında maaş değişikliklerini ve promosyonlarını izleyen uygulamalar, stok eğilimlerini analiz eden envanter yönetimi, uyumluluk için hasta kayıt geçmişini koruyan sağlık hizmetleri ve uyuşmazlık çözümü için sigorta izleme ilkesi kapsam değişiklikleri yer alır.

Zamana bağlı tablo avantajlarını göz önünde bulundurun

Zamansal tablolar sıfır uygulama kodu değişikliği gerektirir ve saydam geçmiş izlemesi sunar. Zaman noktasındaki sorgular basit bir söz dizimini kullanır ve otomatik temizleme işlemi eski verileri temizler. Ancak, geçici tablolar depolama gereksinimlerini kabaca iki katına çıkarır.

Zamana bağlı tablolar , denetim ve belirli bir noktaya analiz için veri değişikliklerinin tam geçmişini otomatik olarak korur.

seçeneğini kullanarak SYSTEM_VERSIONING = ON zamansal tablo oluşturabilirsiniz. Zamana bağlı tablolar, her satır sürümünün geçerlilik süresini izlemek için iki ek DATETIME2 sütun ve bu zaman damgalarını hangi sütunların izlediğini tanımlamak için bir PERIOD FOR SYSTEM_TIME yan tümce gerektirir. Bir örnek aşağıda verilmiştir:

-- Create temporal table with automatic history tracking
CREATE TABLE Employee (
    EmployeeID INT PRIMARY KEY,
    EmployeeName NVARCHAR(100),
    Department NVARCHAR(50),
    SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START,
    SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
) WITH (SYSTEM_VERSIONING = ON);

-- Query historical data
SELECT * FROM Employee
FOR SYSTEM_TIME AS OF '2026-01-01' 
WHERE EmployeeID = 1;

Zamansal tablo oluşturduğunuzda, SQL Server önceki satır sürümlerini depolamak için otomatik olarak bir geçmiş tablosu oluşturur ve her iki tabloyu da saydam bir şekilde yönetir.

Dış tabloları kullanma

Modern veri mimarilerinde genellikle veri gölleri, blob depolama ve birden çok sistem arasında dağıtılmış veriler bulunur. Geleneksel olarak, tüm verileri sorgulamadan önce veritabanınıza ETL (ayıklama, dönüştürme, yükleme) yapmanız gerekir. Dış tablolar , veri sanallaştırmanın verileri taşımadan nerede yaşadığını sorgulamasına olanak tanıyarak depolama maliyetlerinden ve ETL karmaşıklığında tasarruf sağlar.

Dış tabloların ne zaman kullanılacağını anlama

Dış tablolar, dağıtılmış depolama sistemleri arasında verileri sorgulama konusunda mükemmeldir:

  • Data lake tümleştirmesi - Azure Data Lake Storage'da içeri aktarmadan Parquet/CSV dosyalarını sorgulama
  • Veri keşfi - İçeri aktarma işlemine karar vermeden önce ham verileri analiz etme
  • Maliyet iyileştirme - Zaten başka bir yerde depolanan verileri yinelemekten kaçının
  • Federasyon sorguları - Dış sistemlerdeki dosyalarla veritabanı tablolarını birleştirme
  • Arşiv depolama - Daha ucuz blob depolamada depolanan geçmiş verilerine erişme

Yaygın senaryolar arasında işlem verilerinin yanı sıra veri göllerinde yılların günlük dosyalarını sorgulama, canlı veritabanı kayıtlarını arşivlenmiş blob depolama verileriyle birleştirme, tam geçiş olmadan eski verilere erişme ve milyonlarca IoT algılayıcısı JSON dosyasını içeri aktarmadan sorgulama sayılabilir.

Performans kısıtlamalarını göz önünde bulundurun

Dış tablolar kaynaklar arasında birleşik sorgulama sağlar ancak sınırlamaları vardır:

  • Veri taşıma veya depolama yinelemesi yok
  • Ağ gecikme süresi ve dosya ayrıştırma nedeniyle genellikle yerel tablolardan daha yavaş
  • Salt okunur (çoğu senaryoda güncelleştirilemez/silinemez)
  • Sınırlı dizin oluşturma ve iyileştirme

CREATE EXTERNAL TABLE deyimini bir veri kaynağı ve dosya biçimiyle kullanarak bir dış tablo oluşturabilirsiniz. Bir örnek aşağıda verilmiştir:

-- Create external table pointing to data lake
CREATE EXTERNAL TABLE dbo.ExternalSalesData (
    OrderID INT,
    CustomerID INT,
    OrderAmount DECIMAL(10,2),
    OrderDate DATE
) WITH (
    LOCATION = '/raw/sales/',
    DATA_SOURCE = DataLakeSource,
    FILE_FORMAT = ParquetFormat
);

Kayıt defteri tablolarını kullanma

Düzenlemeye tabi sektörlerde verilerin üzerinde oynanmadığını kanıtlamak önemlidir. Geleneksel veritabanlarında yöneticiler tarafından değiştirilen veriler, yapılan yedeklenmiş değişiklikler veya denetim günlükleri silinebilir. Kayıt defteri tabloları, bağımsız olarak doğrulanabilir ve kriptografik veri bütünlüğü kanıtı sağlayan kurcalama kanıtı kayıtları oluşturmak için blok zinciri teknolojisinden esinlenen kriptografik doğrulamayı kullanır.

Kayıt defteri tablolarının ne zaman kullanılacağını anlama

Kayıt defteri tabloları mevzuat uyumluluğu ve adli denetim gereksinimlerine hizmet ediyor:

  • Finansal işlemler - Bankacılık, ödeme işleme, kripto para borsaları
  • Tedarik zinciri - Ürün kaynağını, gözetimini ve orijinalliğini izleme
  • Yasal kayıtlar - Sözleşmeler, sözleşmeler, değişmezlik gerektiren yasal dosyalar
  • Sağlık - Reçete kayıtları, hasta onay formları
  • Kamu - Oylama kayıtları, arazi kayıt defterleri, izin verme

Örneğin, bir banka, hareket kayıtlarını depolamak için genel muhasebe tablolarını kullanabilir ve böylece denetçilerin deftere nakilden sonra hiçbir hareketin değiştirilmediğini doğrulamasına olanak sağlar. Tedarik zinciri şirketi, defter tablolarını kullanarak ürün menşeini izleyebilir ve müşterilere orijinallik kanıtı sunar.

Güncellenebilir ve yalnızca ekleme yapılabilen defterler arasında seçim yapma

Kayıt defteri tabloları iki tür olarak gelir. Güncelleştirilebilir kayıt defteri tabloları, tüm değişiklikleri kriptografik olarak izlerken , INSERTve UPDATE işlemlerine izin verirDELETE. Sistem, önceki sürümleri geçici tablolara benzer şekilde, ancak kurcalamaya karşı dayanıklı doğrulamanın ek avantajıyla otomatik olarak bir geçmiş tablosunda depolar. Yalnızca ekleme kayıt defteri tabloları yalnızca işlemlere izin verir INSERT ve mutlak veri bütünlüğü gerektiren senaryolar için gerçekten sabit kayıtlar oluşturur.

Hem güncelleştirilebilir kayıt defteri tabloları hem de zamansal tablolar oluşturarak her iki teknolojiyi de birleştirerek belirli bir noktaya sorgu özellikleriyle birlikte şifreleme doğrulaması elde edebilirsiniz.

Örneğin, bir ilaç şirketi klinik deneme verileri için yalnızca ek kayıt defteri tablolarını kullanır ve bağımsız denetçilere test sonuçlarının gönderimden sonra değiştirilmediğini gösteren şifreleme kanıtı sağlar.

seçeneğini kullanarak LEDGER = ON bir kayıt defteri tablosu oluşturabilirsiniz. Bir örnek aşağıda verilmiştir:

-- Create ledger table
CREATE TABLE dbo.FinancialTransaction (
    TransactionID INT PRIMARY KEY IDENTITY,
    AccountNumber NVARCHAR(20),
    Amount DECIMAL(15,2),
    TransactionType NVARCHAR(20)
) WITH (LEDGER = ON);

-- Append-only ledger provides immutability
CREATE TABLE dbo.AuditLog (
    LogID INT PRIMARY KEY IDENTITY,
    EventDescription NVARCHAR(500),
    EventTimestamp DATETIME2
) WITH (LEDGER = ON, APPEND_ONLY = ON);

Bir kayıt defteri tablosu oluşturduğunuzda, SQL Server otomatik olarak gizli sütunlar ekler ve şifreleme zincirini izlemek için destekleyici veritabanı nesneleri oluşturur. Her satır değişikliği, önceki işlemlere doğrudan bağlanan kriptografik bir karma oluşturur ve üzerinde oynandığına dair kanıt sağlayabilen bir denetim izi yaratır. sys.database_ledger_transactions gibi yerleşik sistem görünümlerini ve şifreleme zincirinin kesintisiz kaldığını doğrulamak için sp_verify_database_ledger gibi yordamları kullanarak veri bütünlüğünü doğrulayabilirsiniz.

Grafik tablolarını kullanma

İlişkisel veritabanları yapılandırılmış verilerde üstünlük sağlar ancak çok sayıda birleştirme gerektiren yüksek oranda bağlı verilerle mücadele eder. "Arkadaşlarınızın arkadaşlarını" veya "üç dereceyle kategorilere bağlı ürünleri" bulmak geleneksel tablolarla karmaşık hale gelir. SQL Graph özellikleri, düğümleri (varlıklar ) ve kenarları (ilişkiler) yerel olarak modelleyip karmaşık ilişki sorgularını basit ve performanslı hale getirir.

Grafik tabloları ilişki modellemeyi basitleştirir ancak yeni söz dizimleri öğrenmeyi gerektirir. Bağlı verilerin sezgisel modellemesini, ilişki geçişi için daha basit sorguları ve çok atlamalı sorgular için daha iyi performans sağlar. Esnek şema, gelişen ilişkileri barındırıyor. Ancak, grafik tablolarında söz dizimi için MATCH bir öğrenme eğrisi vardır ve yoğun okuma içeren ilişki sorguları için en iyi performansı gösterir.

Veritabanı, grafik verilerinizi modellemek için birlikte çalışan birden çok düğüm ve kenar tablosu içerebilir. Hangi tabloların veri ilişkilerinize göre düğümleri, hangilerinin ise kenarları temsil ettiğini tanımlarsınız.

Uyarı

Grafik tabloları her senaryo için uygun değildir. Ebeveyn-çocuk ilişkilerinin basit olduğu ve yabancı anahtarların düzgün çalıştığı durumlar, karmaşık ilişkiler olmadan öncelikli olarak işlemsel veriler veya yüksek oranda yapılandırılmış, kararlı şemalar için bunlardan kaçının.

Graf tablosu yapısını anlama

SQL Graph, ilişkileri modellemek için iki tür tablo kullanır. Düğüm tabloları varlıkları depolar ve otomatik olarak her düğümü benzersiz olarak tanımlayan gizli $node_id bir sütun içerir. Uç tablolar düğümler arasındaki ilişkileri depolar ve bağlantıları korumak için , , ve gizli sütunlarını içerir. Bu özel sütunlar, MATCH sözdiziminin ilişkiler arasında verimli bir şekilde gezinmesini sağlar.

AS NODE ve AS EDGE söz dizimini kullanarak grafik tablolar oluşturabilirsiniz. Bir örnek aşağıda verilmiştir:

-- Create graph tables
CREATE TABLE Person AS NODE;
CREATE TABLE Manages AS EDGE;
CREATE TABLE Knows AS EDGE;

-- Insert nodes
INSERT INTO Person VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Charlie');

-- Insert edges (relationships)
INSERT INTO Manages VALUES (1, 2), (2, 3);

-- Query relationships
SELECT Person1.name, Person2.name 
FROM Person AS Person1, Manages, Person AS Person2
WHERE MATCH (Person1-(Manages)->Person2)
AND Person1.id = 1;

Düğüm ve kenar tabloları oluşturduğunuzda SQL Server, verimli graf geçişi sorgularını etkinleştiren gizli sistem sütunlarını otomatik olarak yönetir.

Özel tablo türlerinin her biri bazı tavizler/özellikler sunar: bellek içi tablolar RAM gerektirir, zamana bağlı tablolar çift depolama alanı gerektirir, dış tablolar ağ gecikmesi ekler, kayıt defteri tabloları silinmeyi engeller ve grafik tablolar yeni söz dizimi gerektirir. Dağıtımdan sonra bu kararların değiştirilmesi zor olduğundan tasarım sırasında doğru tablo türünü seçmenizi öneririz.