Beyond UUIDs: Smarter Identifier Strategies for Modern Systems

Transcript

1. Veritabanı Performansında Benzersiz Kimliklerin Rolü: INT, UUID, ULID, UUIDv7 Karşılaştırması
2. 2023- YILDIZ TECHNICAL UNIVERSİTY Mathematical Engineering (Licentiate Degree) YILDIZ TECHNICAL UNIVERSİTY Computer Engineering/IT (Master's Degree (Non-Thesis)) 2013-2018 2019-2020 YILDIZ TECHNICAL UNIVERSİTY Mathematical Engineering (Master's Degree (Thesis)) 2021-.. DOĞUŞ TEKNOLOJİ Software Support Asistant Specialist Software Asistant Specialist Software Specialist 2018-2021 KARİYER.NET Software Specialist Senior Software Specialist Expert Software Engineer Software Development Lead Mavi (2016) Overtech (2017) INTERNSHIPS Junior Frontend Developer 2018 ICONEC WAVE X: @kardelanite in: kardelruveydacetin
3. UUID Nedir ve Neden Kullanılır? Peki, GUID Kullanmanın Değeri Nedir? UUID’ler neden veritabanı performansını olumsuz etkileyebilir? RFC 9562 ve UUIDv7 UUIDv4’ün Sorunu UUIDv7: Zaman Sıralı UUID ULID Demo Ajanda
4. UUID Nedir ve Neden Kullanılır? 128 bit (16 byte) benzersiz kimlik .NET → Guid.NewGuid() ile üretilir Küresel benzersizlik → çakışma neredeyse imkânsız Versiyon & varyant bitleri dışında rastgele değerler En yaygın: UUID v4 (random)
5. Peki, GUID Kullanmanın Değeri Nedir? Küresel benzersizlik → Çakışma ihtimali yok denecek kadar az Dağıtık sistemler için ideal → Merkezi otorite gerekmez. Veritabanı & framework desteği → SQL Server, PostgreSQL, Oracle native destekler. Primary key olarak kullanılabilir.
6. UUID’ler neden veritabanı performansını olumsuz etkileyebilir? Yavaşlayan Insert İşlemleri Bir veritabanında satır eklediğinizde (INSERT), aslında veriler sadece tabloya yazılmaz; aynı zamanda indeks yapısına da kaydedilir. Çoğu modern veritabanında bu indeks yapısı bir B+ Tree’dir.
7. B+ Tree, sıralı bir yapıdır. Yani küçükten büyüğe doğru düzenli dizilmiş değerler vardır. Integer veya artan kimlikler (auto-increment IDs) bu yapıya kusursuz şekilde oturur: yeni değer her zaman sona eklenir. Hiyerarşik bir ağaçtır: En tepede bir kök düğüm (root) vardır, altında ara düğümler, en altta ise yaprak (leaf) düğümleri bulunur. Sıralıdır: Küçük değerler solda, büyük değerler sağda yer alır. Yapraklar veriye gider: En alt seviyedeki yaprak düğümler, tablodaki satırlara (örneğin primary key değerine karşılık gelen kayıtlara) işaret eder.
8. B+ Tree sayesinde veritabanı indeksleri düzenli ve sıralı kalır. Bu da aramaları ve sıralı sorguları inanılmaz hızlı yapmamızı sağlar. Artan integer ID → Kitapları rafta sırayla yerleştirmek gibi. Düzenli, kolay. UUID → Kitapları rastgele yerlere sıkıştırmaya çalışmak gibi. Raf sürekli yeniden düzenlenmek zorunda kalır.
9. Index Fragmentation (Parçalanma) UUID’lerin rastgeleliği sadece ekleme hızını etkilemez, aynı zamanda zamanla indeksin parçalanmasına yol açar. Bir başka deyişle, veriler diskte dağınık şekilde dağılır. Sorgular daha yavaş çalışır çünkü veriler fiziksel olarak ardışık değildir. Veritabanı bakım maliyetleri artar (reindex, vacuum gibi işlemler daha sık yapılır).
10. Yüksek Depolama Maliyeti Integer: 4 byte BigInt: 8 byte UUID: 16 byte UUID’ler dağıtık sistemler için mükemmel bir araçtır ama her zaman en iyi seçim değildir. Özellikle yoğun veritabanı yazma işlemlerinde, indeks yoğun kullanılan sistemlerde ve devasa ölçeklerde performans sorunlarına yol açabilirler.
11. RFC 9562 ve UUIDv7 Mayıs 2024’te yayımlanan RFC 9562 belgesi ile birlikte, UUID standardı güncellenmiş ve modern gereksinimlere cevap verecek şekilde UUIDv7 resmî olarak tanımlanmıştır. Bu doküman yalnızca UUID’nin temel yapısını (128-bit uzunluk, küresel benzersizlik, varyant ve versiyon alanları) açıklamakla kalmamış, aynı zamanda gelecekteki ölçeklenebilir sistemler için daha uygun yeni sürümler de önermiştir. RFC 9562 belgesi
12. UUIDv4’ün Sorunu Neydi? Bu yapı sayesinde küresel benzersizlik garanti edilse de, sıralanabilirlik (ordering) özelliği tamamen kaybolmaktadır. Dolayısıyla UUIDv4 tabanlı kimlikler, veritabanlarında özellikle insert performansı ve indeks parçalanması (index fragmentation) gibi ciddi problemlere yol açabilmektedir. 4 bitlik version alanı → 0100 (v4’ü ifade eder). 2 bitlik variant alanı → UUID standardının varyantını belirtir. Kalan 122 bit → tamamen rastgele üretilir.
13. UUIDv7: Zaman Sıralı UUID Monotonik olarak artan (time-ordered) değerler üretir, Veritabanı indekslerine doğal biçimde uyum sağlar, Rastgelelik sayesinde çakışma olasılığını neredeyse ortadan kaldırır. İlk 48 bit → Unix zaman damgası (milisaniye cinsinden). Sonraki 4 bit → versiyon alanı (0111 yani v7). Kalan bitler → rastgelelik (random bits).
14. .NET Desteği UUIDv7 Bu sayede geliştiriciler, sıralanabilir (time-ordered) UUID’ler doğrudan .NET ekosisteminde kullanabileceklerdir. Böylece hem küresel benzersizlik korunmakta, hem de veritabanı performansı açısından daha uyumlu kimlikler elde edilmektedir. 2024 yılı ortası itibarıyla .NET içerisinde Guid.NewGuid() yalnızca UUIDv4 üretmektedir. Ancak .NET 9 ile birlikte UUIDv7 API’si resmî olarak eklenmiştir.
15. ULID ULID, UUID gibi 128 bit uzunluğa sahiptir ve bu nedenle depolama açısından tamamen uyumludur. Yapısı iki ana bileşenden oluşmaktadır: Zaman bileşeni (48 bit): Unix zaman damgasını milisaniye hassasiyetinde saklar. Rastgelelik bileşeni (80 bit): Benzersizlik garantisi sağlamak amacıyla rastgele değerlerden oluşur.
16. .NET Ekosisteminde ULID Kullanımı UUID’ler .NET içerisinde uzun süredir yerleşik (native) olarak desteklenmektedir (System.Guid). Buna karşın ULID henüz .NET Runtime içerisinde standart bir tür olarak sunulmamaktadır. Yani Guid.NewGuid() ile olduğu gibi doğrudan framework tarafından üretilmez.
17. ULID Veritabanı Eşleştirmesi (Entity Framework Core) String (CHAR(26)): Okunabilirlik sağlar ancak depolama maliyeti daha yüksektir. Binary (BINARY(16)): UUID ile birebir uyumlu boyut, daha düşük depolama ve daha verimli indeksleme
18. Demo
19. Önkoşullar .NET 9 SDK (Guid v7 için) Docker (SQL Server 2022 container) Windows/Linux/macOS fark etmez.
20. Proje İskele Oluşturulması
21. Proje İskele Oluşturulması
22. Modellerin Oluşturulması RecInt
23. Modellerin Oluşturulması RecGuidV4 GUID v4 Clustered PK
24. Modellerin Oluşturulması RecGuidV4 GUID v4 Clustered PK 04097D14–57DB-40F3-B4E7–002CEF75A64A 04097D14 → 32 bit 57DB → 16 bit 40F3 → 16 bit B4E7 → 16 bit 002CEF75A64A → 48 bit 04097D14, 57DB, F3, E7, 2CEF75A64A kısımları tamamen random’dur. O yüzden GUID’ler sıralanamaz (index fragmentation’ın sebebi de bu). 40F3 B4E7
25. Modellerin Oluşturulması RecUlidString → ULID (string, 26 char) clustered PK Toplam 128 bit uzunluğundadır (GUID ile aynı). 26 karakterlik Crockford Base32 alfabesiyle gösterilir (0-9 ve A-Z, ama I, L, O, U yok → karışıklığı önlemek için).
26. Modellerin Oluşturulması RecUlidString → ULID (string, 26 char) clustered PK 01K618JS0QR9D24JK2EMRVSZN6 Toplam uzunluk: 26 karakter Base32 (Crockford) ile kodlanmış 48 bit (ilk 10 karakter) → Timestamp 80 bit (son 16 karakter) → Randomnes 01K618JS0Q R9D24JK2EMRVSZN6 Timestamp (ms) içerir. Bu bölüm tamamen rasgele üretilmiş bitlerden oluşur.
27. RecUlidBinary → ULID (binary 16) clustered PK Modellerin Oluşturulması
28. Modellerin Oluşturulması RecUlidBinary → ULID (binary 16) clustered PK 0x01998289647C0184E1799AFD09853FC3 01998289647C 0184E1799AFD09853FC3 Timestamp (ms) içerir. randomness kısmı
29. Modellerin Oluşturulması RecGuidV4_ClusterOnDate → GUID v4 (nonclustered PK) + CreatedOn (clustered) CreatedOn → Clustered Index olarak tanımlandı. Yani tablodaki kayıtların fiziksel saklanma sırası bu alana göre belirlenir.
30. Modellerin Oluşturulması RecGuidV7 → GUID v7 (Clustered PK, .NET 9) CreatedOn → Clustered Index olarak tanımlandı. Yani tablodaki kayıtların fiziksel saklanma sırası bu alana göre belirlenir.
31. Modellerin Oluşturulması RecUlidBinary → ULID (binary 16) clustered PK 01998289–65AE-7ED8–9FC7–00051593D6DD 0199828965AE 00051593D6DD Unix Zaman Damgası randomness kısmı 7ED8 Versiyon RFC 9562
32. DbContext & EF Core eşlemeleri 1 2 3
33. DbContext & EF Core eşlemeleri 4 5 6
34. Sonuçlar
35. Sonuçlar
36. Sonuçlar