Wydajność UUID w MySQL?

W mojej pracy używamy UUID jako PKs. Z doświadczenia mogę ci powiedzieć, że nie używaj ich jako PKs (przy okazji SQL Server).

To jedna z tych rzeczy, że gdy masz mniej niż 1000 płyt to jest ok, ale kiedy masz miliony, to najgorsza rzecz, jaką możesz zrobić. Dlaczego? Ponieważ UUID nie są sekwencyjne, więc za każdym razem, gdy wstawiany jest nowy rekord MSSQL musi przejść do właściwej strony, aby wstawić rekord, a następnie wstawić rekord. Naprawdę brzydką konsekwencją tego jest to, że strony kończą się w różnych rozmiarach i kończą się fragmentarycznie, więc teraz musimy zrobić okresową de-fragmentację.

Kiedy używasz autoincrement, MSSQL zawsze przejdzie do ostatniej strony, a ty skończysz z równie wielkimi stronami (teoretycznie), więc wydajność wybierania tych rekordów jest znacznie lepsza (również dlatego, że wstawki nie będą blokować tabeli/strony tak długo).

Jednak dużą zaletą używania UUID jako PKs jest to, że jeśli mamy klastry DBs, nie będzie konfliktów podczas łączenia.

Polecam następujący model: 1. PK Int Identity 2. Dodatkowa kolumna generowana automatycznie jako UUID.

W ten sposób proces scalania jest możliwy(uuid byłby twoim prawdziwym kluczem, podczas gdy PK byłby tylko czymś tymczasowym, co daje dobrą wydajność).

Uwaga: najlepszym rozwiązaniem jest użycie NEWSEQUENTIALID (jak mówiłem w komentarzach), ale dla starszych aplikacji z niedużym czasem na refaktoryzację (a co gorsza, nie kontrolowanie wszystkich wstawek), to niemożliwe. Ale rzeczywiście, od 2017 roku, powiedziałbym, że najlepszym rozwiązaniem tutaj jest NEWSEQUENTIALID lub robi Guid.Grzebień z NHibernate.

Hope this helps

Należy wziąć pod uwagę fakt, że Autoinkrementy są generowane pojedynczo i nie można ich rozwiązać za pomocą równoległego rozwiązania. Walka o uuid ostatecznie sprowadza się do tego, co chcesz osiągnąć, a co potencjalnie poświęcisz.

On performance, krótko :

UUID taki jak ten powyżej to 36 znaki długie, w tym myślniki. Jeśli przechowujesz ten VARCHAR (36), jesteś zmniejszy wydajność porównywania dramatycznie. To jest twój podstawowy key, nie chcesz, żeby to było powolne.

Na poziomie bitów UUID wynosi 128 bitów, co oznacza, że zmieści się w 16 bajtach, zauważ, że nie jest to zbyt czytelne dla człowieka, ale utrzyma niski poziom pamięci i jest tylko 4 razy większy niż 32-bitowy int, lub 2 razy większy niż 64-bitowy int. Użyję VARBINARY (16) Teoretycznie może to działać bez dużo kosztów.

Polecam przeczytać dwa posty:

• Brian " Krow" Bezczynne myśli akera-mity, GUID vs Autoincrement
• do UUID czy nie ?

Myślę, że pomiędzy tymi dwoma, odpowiadają na twoje pytanie.

Staram się unikać UUID po prostu dlatego, że jest to ból do przechowywania i ból do użycia jako klucz podstawowy, ale są zalety. Głównym jest to, że są wyjątkowe.

Zazwyczaj rozwiązuję problem i unikam UUID za pomocą pól dual key.

KOLEKTOR = UNIKALNY PRZYPISANY DO MASZYNY

ID = rekord pobrany przez kolektor (pole auto_inc)

To oferuje mi dwie rzeczy. Szybkość pól auto-inc i unikalność danych przechowywanych w centralnej lokalizacji po ich zebrane i zgrupowane razem. Wiem też podczas przeglądania danych, gdzie zostały zebrane, co często jest dość ważne dla moich potrzeb.

Widziałem wiele przypadków, gdy miałem do czynienia z innymi zestawami danych dla klientów, w których zdecydowali się użyć UUID, ale nadal mają pole, gdzie dane zostały zebrane, co naprawdę jest stratą wysiłku. Wystarczy użyć dwóch (lub więcej w razie potrzeby) pól, ponieważ klucz naprawdę pomaga.

Właśnie widziałem zbyt wiele hitów wydajności przy użyciu UUID. Czują jak oszust...

Zamiast centralnie generować unikalne klucze dla każdego wstawiania, co powiesz na przydzielanie bloków kluczy do poszczególnych serwerów? Gdy zabraknie im kluczy, mogą poprosić o nowy blok. Następnie rozwiązujesz problem napowietrzności, podłączając każdą wkładkę.

Keyserver utrzymuje następny dostępny identyfikator

• Serwer 1 żąda bloku id.
• keyserver zwraca (1,1000)
  Serwer 1 może wstawić 1000 rekordów, dopóki nie będzie musiał żądać nowego bloku
• Serwer 2 blok indeksu żądań.
• keyserver zwraca (1001,2000)
• itd...

Możesz wymyślić bardziej wyrafinowaną wersję, w której serwer mógłby zażądać liczby potrzebnych kluczy lub zwrócić nieużywane bloki do serwera kluczy, który oczywiście musiałby utrzymywać mapę używanych / nieużywanych bloków.

Każdemu serwerowi przypisałbym numer ID w sposób transakcyjny. Następnie każdy wstawiony rekord po prostu automatycznie utworzy swój własny licznik. Połączenie ServerID i RecordID będzie unikalne. Pole ServerID można zindeksować i wybrać wydajność na podstawie ServerID (w razie potrzeby) może być znacznie lepiej.

A może jakiś ręcznie wykonany UID? Daj każdemu z tysięcy serwerów ID i zrób klucz podstawowy kluczem combo autoincrement, MachineID???

Ponieważ klucz podstawowy jest generowany w sposób zdecentralizowany, nie masz możliwości użycia auto_increment.

Jeśli nie musisz ukrywać tożsamości zdalnych maszyn, użyj uuid typu 1 zamiast uuid. Są one łatwiejsze do wygenerowania i mogą przynajmniej nie zaszkodzić wydajności bazy danych.

To samo tyczy się varchar (char, naprawdę) vs. binary: może pomóc tylko w sprawach. Czy to naprawdę ważne, jak bardzo wydajność jest lepsza?

Krótka odpowiedź jest taka, że wiele baz danych ma problemy z wydajnością (w szczególności z dużymi wolumenami wstawiania) z powodu konfliktu między ich metodą indeksowania a celową entropią uuid w bitach wysokiego rzędu. Istnieje kilka popularnych hacków:

• Wybierz inny typ indeksu (np. nonclustered na MSSQL), który nie przeszkadza
• munge danych, aby przenieść entropię do bitów niższego rzędu (np. zmiana kolejności bajtów uuid V1 W MySQL)
• uczyń UUID kluczem wtórnym z auto-increment int primary key

... ale to są wszystkie hacki ... i pewnie te delikatne.

Najlepszą odpowiedzią, ale niestety najwolniejszą, jest żądanie, aby twój dostawca ulepszył swój produkt, aby mógł poradzić sobie z uuid jako kluczami podstawowymi, tak jak każdy inny typ. Nie powinni zmuszać cię do robienia własnych na wpół upieczonych hack, aby nadrobić ich niepowodzenie w rozwiązaniu tego, co stało się powszechnym przypadkiem użycia i będzie nadal rosnąć.