MySQL'de UUID performansı?

MySQL veritabanımız için birincil anahtarlar olarak UUID değerlerini kullanmayı düşünüyoruz. Eklenen veriler düzinelerce, yüzlerce ve hatta binlerce uzak bilgisayardan üretilir ve saniyede 100-40.000 ekleme hızında eklenir ve hiçbir zaman güncelleme yapmayız.

Veritabanının kendisi, biz verileri toplamaya başlamadan önce genellikle yaklaşık 50 milyon kayda ulaşacaktır, bu nedenle çok büyük bir veritabanı değil, küçük de değil. Ayrıca InnoDB üzerinde çalışmayı planlıyoruz, ancak yaptığımız şey için daha iyi bir motor varsa bunu değiştirmeye açıkız.

Java'nın Type 4 UUID'sini kullanmaya hazırdık, ancak test sırasında bazı garip davranışlar görüyoruz. Birincisi, varchar (36) olarak depoluyoruz ve şimdi ikili (16) kullanmanın daha iyi olacağının farkındayım - ne kadar iyi olduğundan emin değilim.

Daha büyük soru şudur: 50 milyon kaydımız varken bu rastgele veriler endeksi ne kadar kötü bir şekilde alt üst ediyor? Örneğin, en soldaki bitlerin zaman damgalı olduğu bir tip-1 UUID kullansaydık daha iyi olur muyduk? Veya belki de UUID'leri tamamen atmalı ve auto_increment birincil anahtarlarını düşünmeliyiz?

MySQL'de bir dizin / birincil anahtar olarak depolandıklarında farklı UUID türlerinin performansı hakkında genel düşünceler / ipuçları arıyorum. Teşekkürler!

Bir UUID, Evrensel Olarak Benzersiz bir Kimliktir. Burada düşünmeniz gereken evrensel kısım budur.

Eğer Do gerçekten evrensel benzersiz olması kimlikleri gerek? Öyleyse, UUID'ler tek seçeneğiniz olabilir.

Ben şiddetle eğer öneririm yapmak kullanımı UUIDs, bir numara olarak değil, bir dize olarak saklayabilirsiniz. 50M + kayıtlarınız varsa, depolama alanından tasarruf, performansınızı artıracaktır (ancak ne kadar olduğunu söyleyemem).

Kimliklerinizin evrensel olarak benzersiz olması gerekmiyorsa, o zaman kimliklerin bir tablo içinde benzersiz olacağını garanti eden auto_increment'i kullanmaktan çok daha iyisini yapabileceğinizi sanmıyorum (çünkü değer her seferinde artacaktır)

Benim işimde UUID'yi PK olarak kullanıyoruz. Deneyimlerimden size söyleyebileceğim şey, ONLARI PK olarak KULLANMAYIN (bu arada SQL Server).

1000'den az kayda sahip olduğunuzda sorun değil, ancak milyonlarınız olduğunda yapabileceğiniz en kötü şey bu. Neden? UUID sıralı olmadığından, her yeni kayıt eklendiğinde MSSQL'in kaydı eklemek için doğru sayfaya gitmesi ve ardından kaydı yerleştirmesi gerekir. Bunun gerçekten çirkin sonucu, sayfaların hepsinin farklı boyutlarda olması ve parçalanmış olmalarıdır, bu yüzden şimdi periyodik parçalanma yapmamız gerekiyor.

Bir otomatik artırma kullandığınızda, MSSQL her zaman son sayfaya gider ve sonunda eşit boyutta sayfalarla (teoride) sonuçlanır, bu nedenle bu kayıtları seçme performansı çok daha iyidir (ayrıca INSERT'ler tablo / sayfayı Elveda).

Bununla birlikte, UUID'yi PK olarak kullanmanın en büyük avantajı, DB kümelerimiz varsa, birleştirme sırasında çakışma olmayacak olmasıdır.

Aşağıdaki modeli tavsiye ederim: 1. PK INT Kimliği 2. UUID olarak otomatik olarak oluşturulan ek sütun.

Bu şekilde, birleştirme işlemi mümkündür (UUID sizin GERÇEK anahtarınız olurken, PK size iyi performans sağlayan geçici bir şey olacaktır).

NOT: En iyi çözüm NEWSEQUENTIALID kullanmaktır (yorumlarda söylediğim gibi), ancak yeniden düzenleme yapmak için fazla zamanı olmayan (ve daha da kötüsü, tüm ekleri kontrol etmeyen) eski uygulama için bunu yapmak mümkün değildir. Ama gerçekten 2017 itibariyle, en iyi çözümün NEWSEQUENTIALID veya NHibernate ile Guid.Comb yapmak olduğunu söyleyebilirim.

Bu yardımcı olur umarım

Dikkate alınması gereken bir nokta, Otomatik artışların birer birer üretildiği ve paralel bir çözüm kullanılarak çözülemeyeceğidir. UUID'leri kullanma mücadelesi, sonunda elde etmek istediklerinize karşı potansiyel olarak feda ettiğiniz şeye bağlıdır.

Performans hakkında kısaca :

Yukarıdakine benzer bir UUID, çizgiler dahil 36 karakter uzunluğundadır. Bu VARCHAR'ı (36) saklarsanız, karşılaştırma performansını önemli ölçüde düşürürsünüz. Bu sizin birincil anahtarınızdır, yavaş olmasını istemezsiniz.

Bit düzeyinde, bir UUID 128 bittir, bu da 16 bayta sığacağı anlamına gelir, bunun insan tarafından okunabilir olmadığını ancak depolamayı düşük tutacağını ve 32 bitlik int veya 2'den yalnızca 4 kat daha büyük olduğunu unutmayın. 64 bitlik bir int'den kat daha büyük. Bir VARBINARY kullanacağım (16) Teorik olarak, bu çok fazla ek yük olmadan çalışabilir.

Aşağıdaki iki gönderiyi okumanızı tavsiye ederim:

• Brian "Krow" Aker'in Boştaki Düşünceleri - Mitler, GUID ve Otomatik Artırma
• UUID'ye mi yoksa UUID'ye mi?

Sanırım ikisi arasında, sorunuza cevap veriyorlar.

UUID'den kaçınma eğilimindeyim çünkü saklanması ve birincil anahtar olarak kullanılması bir acıdır, ancak avantajları vardır. Bunlardan en önemlisi, EŞSİZ olmaları.

Genellikle sorunu çözerim ve çift anahtarlı alanları kullanarak UUID'den kaçınırım.

KOLLEKTÖR = BİR MAKİNEYE ATANMIŞ EŞSİZ

KİMLİK = KOLLEKTÖR TARAFINDAN TOPLANAN KAYIT (auto_inc alanı)

Bu bana iki şey sunuyor. Otomatik artırma alanlarının hızı ve birlikte toplanıp gruplandırıldıktan sonra merkezi bir konumda depolanan verilerin benzersizliği. Ayrıca, verilerin nerede toplandığına göz atarken, bunun genellikle ihtiyaçlarım için oldukça önemli olduğunu biliyorum.

Müşteriler için diğer veri setleriyle uğraşırken UUID kullanmaya karar verdikleri, ancak yine de verilerin toplandığı bir alana sahip olan ve gerçekten çaba israfı olan birçok vaka gördüm. Anahtarınız gerçekten yardımcı olduğu için yalnızca iki (veya gerekirse daha fazla) alan kullanmak.

UUID kullanarak çok fazla performans isabeti gördüm. Hile gibi hissediyorlar ...

Her ekleme için merkezi olarak benzersiz anahtarlar üretmek yerine, anahtar bloklarını ayrı sunuculara ayırmaya ne dersiniz? Anahtarları tükendiğinde yeni bir blok talep edebilirler. Ardından, her bir kesici uç için bağlayarak genel gider sorununu çözersiniz.

Anahtar sunucusu bir sonraki kullanılabilir kimliği korur

• Sunucu 1, kimlik bloğu ister.
• Anahtar sunucusu döndürür (1,1000)
  Sunucu 1, yeni bir blok talep etmesi gerekene kadar 1000 kayıt ekleyebilir
• Sunucu 2, dizin bloğu ister.
• Anahtar sunucusu döndürür (1001,2000)
• vb...

Bir sunucunun gerekli anahtar sayısını talep edebileceği veya kullanılmayan blokları anahtar sunucusuna geri gönderebileceği daha karmaşık bir sürüm elde edebilirsiniz, bu durumda elbette kullanılan / kullanılmayan blokların bir haritasını tutması gerekir.

Her sunucuya işlemsel bir şekilde sayısal bir kimlik atardım. Ardından, eklenen her kayıt kendi sayacını otomatik olarak artıracaktır. Sunucu Kimliği ve Kayıt Kimliği kombinasyonu benzersiz olacaktır. Sunucu Kimliği alanı endekslenebilir ve Sunucu Kimliğine (gerekirse) dayalı olarak gelecekteki seçim performansı çok daha iyi olabilir.

Kısa cevap, birçok veritabanının, indeksleme metotları ile UUID'lerin yüksek mertebeli bitlerdeki kasıtlı entropisi arasındaki bir çelişki nedeniyle performans problemlerine (özellikle yüksek INSERT hacimlerinde) sahip olmasıdır. Birkaç yaygın saldırı vardır:

• bunu önemsemeyen farklı bir dizin türü seçin (örneğin, MSSQL'de kümelenmemiş)
• Entropiyi daha düşük sıralı bitlere taşımak için verileri munge (örneğin, MySQL'de V1 UUID'lerin baytlarını yeniden sıralama)
• UUID'yi otomatik artışlı int birincil anahtar ile ikincil bir anahtar haline getirin

... ama bunların hepsi hack - ve muhtemelen bu konuda kırılgan olanlar.

En iyi cevap, ancak maalesef en yavaş olanı, satıcınızın UUID'leri tıpkı diğer türler gibi birincil anahtarlar olarak ele alabilmesi için ürününü geliştirmesini istemektir. Yaygın bir kullanım durumu haline gelen ve sadece büyümeye devam edecek olan şeyi çözmedeki başarısızlıklarını telafi etmek için kendi yarı pişmiş hack'lerinizi yuvarlamanız için sizi zorlamamalılar.

El yapımı bazı UID'ler ne olacak? Binlerce sunucunun her birine bir kimlik verin ve birincil anahtarı otomatik artırmanın birleşik anahtarı, MachineID ???

Birincil anahtar merkezi olmayan bir şekilde oluşturulduğundan, yine de bir otomatik artırma kullanma seçeneğiniz yoktur.

Uzak makinelerin kimliğini gizlemeniz gerekmiyorsa, UUID'ler yerine Type 1 UUID'leri kullanın. Oluşturmaları daha kolaydır ve en azından veritabanının performansına zarar veremezler.

Aynı şey varchar (char, gerçekten) ve ikili için de geçerlidir: yalnızca sorunlara yardımcı olabilir. Performansın ne kadar geliştirildiği gerçekten önemli mi?

Bu sorunun oldukça eski olduğunun farkındayım ama araştırmamda buna değindim. Birkaç şey olduğundan beri (SSD her yerde bulunur InnoDB'de güncellemeler var vb.).

Araştırmamda performans üzerine oldukça ilginç bir yazı buldum :

GUID / UUID indeks ağaçlarının rastlantısallığından dolayı oldukça dengesizleşebileceğini iddia ederek . MariaDB KB'de başka bir gönderinin bir çözüm önerdiğini buldum . Ama o zamandan beri yeni UUID_TO_BIN bununla ilgileniyor. Bu işlev yalnızca MySQL'de (test edilmiş sürüm 8.0.18) mevcuttur ve MariaDB'de (sürüm 10.4.10) mevcut değildir.

TL; DR: UUID'yi dönüştürülmüş / optimize edilmiş BINARY (16) değerleri olarak saklayın.