Przejście do prowadnic sekwencyjnych (grzebieniowych) - co z istniejącymi danymi?

Question

Mamy bazę danych z ponad 500 tabelami, w których prawie wszystkie tabele mają klastrowany PK, który jest typu danych (unikalny identyfikator).

Jesteśmy w trakcie testowania przełącznika z "normalnych" "losowych" instrukcji wygenerowanych za pomocą metody .NETs Guid.NewGuid() do sekwencyjnych komunikatów generowanych przez NHibernate guid.comb algorithm. Wydaje się, że działa dobrze, ale co z klientami, którzy mają już miliony wierszy z "losowymi" wartościami klucza podstawowego?

• Czy skorzystają z faktu, że nowe identyfikatory generowane od teraz będą sekwencyjne?
• Czy można/należy coś zrobić z ich istniejącymi danymi?

Z góry dziękuję za wszelkie wskazówki na ten temat.

Answer 1

Możesz to zrobić, ale nie jestem pewien, czy chcesz. Nie widzę żadnej korzyści z używania sekwencyjnych przewodników, w rzeczywistości używanie przewodników nie jest zalecane jako klucz podstawowy, chyba że istnieją przyczyny związane z dystrybucją/replikacją. Czy używasz indeksu klastrowego?

Powiedziawszy, że jeśli pójdziesz do przodu, polecam najpierw załadować tabelę z wartościami z twojego algorytmu.

Będziesz mieć kłopoty z kluczami obcymi. Konieczne będzie skojarzenie starego i nowego pliku GUID w tabeli formalnej, usunięcie kluczy obcych, wykonanie aktualizacji transakcyjnej, a następnie ponowne zastosowanie kluczy obcych.

Nie sądzę, że jest to warte kłopotów, chyba że całkowicie odejdziesz od guids, aby powiedzieć system oparty na liczbach całkowitych.

Answer 2

Zależy od tego, czy tabele są klastrowane w głównym indeksie, czy w innym indeksie. Na przykład, jeśli tworzysz dużą liczbę nowych rekordów w tabeli z identyfikatorem GUID PK i datą utworzenia, zwykle ma sens klastrowanie przed datą utworzenia w celu zoptymalizowania operacji wstawiania.

Z drugiej strony, w zależności od wykonanych zapytań, klaster na identyfikatorze GUID może być lepszy, w takim przypadku użycie sekwencyjnych identyfikatorów GUID może pomóc w wydajności wstawiania. Powiedziałbym, że nie jest możliwe udzielenie ostatecznej odpowiedzi na twoje pytanie bez dogłębnej znajomości użytkowania.

Answer 3

Mam do czynienia z podobnym problemem, myślę, że byłoby możliwe zaktualizowanie istniejących danych poprzez napisanie aplikacji, aby zaktualizować istniejące klucze za pomocą algorytmu NHibernate guid.comb. Aby przesłać nowe klucze do powiązanych tabel kluczy obcych, możliwe jest tymczasowe uaktualnienie kaskadowe? Robiąc to za pomocą kodu .NET byłoby wolniej niż skrypt SQL, inną opcją może być powielenie logiki guid.comb w SQL, ale nie jestem pewien, czy jest to możliwe.

Jeśli zdecydujesz się zachować istniejące dane, użycie algorytmu guid.comb powinno poprawić wydajność, nadal będzie podział strony, gdy pojawią się inserty, ale ponieważ nowe guidy są sekwencyjne zamiast całkowicie losowe, będzie to co najmniej trochę zredukowany. Inną opcją do rozważenia jest usunięcie indeksu klastrowanego na kluczu podstawowym GUID, chociaż nie jestem pewien, na ile wpłynie to na wydajność istniejących zapytań.