Jednym z wyzwań związanych z nowym projektem bazy danych jest to, że nie wiesz, jak duże będą ostatecznie tabele, dopóki nie zostaną wypełnione sporą ilością danych. Ale jeśli projekt musi uwzględniać ewentualne problemy ze skalowalnością, nie można go wdrożyć w celu uzyskania tych danych, dopóki nie zostanie wykonane oszacowanie. Jednym ze sposobów na obejście tego jest agresywne prototypowanie rzeczy. Użyj w tym celu sprzętu pomostowego, aby nowe aplikacje mogły tymczasowo funkcjonować podczas sortowania takich szczegółów. Możesz po prostu wziąć pod uwagę, że będziesz musiał przenieść aplikację i być może przeprojektować ją po kilku miesiącach, kiedy będziesz miał lepszy pomysł, jakie dane będą w niej wyświetlane.
Innym sposobem na obejście tego problemu z kurczakiem/jajkiem jest napisanie generatora danych. Skonstruuj ręcznie wystarczającą ilość przykładowych danych, aby zobaczyć, jak wygląda, jaka jest gęstość i jak rozkładają się jej wartości. Następnie napisz coś, co bierze te statystyki i tworzy podobny do nich większy zestaw danych. Nigdy nie dostaniesz, że jest to idealne, ale nie musi tak być. Generowanie gigantycznych zestawów danych, nawet z pewnymi wadami, jest nadal najlepszym dostępnym sposobem szacowania rozmiaru bazy danych. Istnieje tak wiele źródeł narzutów, że trudno jest wziąć pod uwagę, że wszelkie zmierzone rozmiary tabel i indeksów, oparte na czymś takim jak twoje dane, będą o wiele dokładniejsze niż jakiekolwiek inne podejście. Jest powód, dla którego w końcu odpowiadam na wiele pytań dotyczących problemów związanych z wydajnością, używając najpierw pgbench do utworzenia bazy danych o odpowiednim rozmiarze.
Jednak generowanie danych nie jest łatwe. W szczególności generowanie realistycznych znaczników czasu jest zawsze denerwujące. I bez względu na to, jak wydajnie myślisz, że je napisałeś, zwykle trwają one dłużej, niż się spodziewasz – a nawet dłużej, aby uzyskać dane wynikowe w bazie danych i odpowiednio zindeksowane.
I tak jest nadal, bez względu na to, ile razy to robiłeś, ponieważ nawet jeśli zrobisz wszystko dobrze, prawo Murphy’ego będzie ingerować i sprawić, że praca będzie bolesna. Wszystkie moje komputery w domu są zbudowane ze stosunkowo taniego sprzętu komputerowego. Nie najtańsze dostępne rzeczy - mam standardy - ale z pewnością nie używam tej samej jakości, którą poleciłbym ludziom szukać na serwerze. Problem z generowaniem danych w tym tygodniu przypomniał, dlaczego lepszy sprzęt jest wart, ile kosztuje praca o krytycznym znaczeniu dla firmy.
Po wygenerowaniu kilku miliardów wierszy danych i oglądaniu tego importu przez 10 godzin nie byłem zadowolony, że całe zadanie zostało przerwane w ten sposób:
psql:load.sql:10: ERROR: invalid input syntax for type timestamp: "201^Q-04-14 12:17:55"
CONTEXT: COPY testdata, line 181782001, column some_timestamp: "201^Q-04-14 12:17:55"
Okazuje się, że gdzieś w trakcie pisania 250 GB danych testowych, które wygenerowałem, jedna z linii wyjściowych była uszkodzona. Dwa bity przeskoczyły i zapisane dane były błędne. Na pewno nie wiem, gdzie to się stało.
Pamięć jest najbardziej prawdopodobnym podejrzanym. Prawdziwe serwery używają ECC RAM i nie bez powodu. Jeśli monitorujesz system z dużą ilością pamięci RAM, liczba błędów po cichu poprawianych przez ECC może być szokująca. Pamięć RAM, której używam w domu, jest dobra, ale wskaźniki błędów w dowolnej pamięci bez możliwości wykrywania / korekcji błędów będą wyższe niż byś chciał - i nigdy nie zostaną wykryte, chyba że wystąpią w kodzie, który prowadzi do awarii systemu. Praca z generowaniem danych jest dobra w ujawnianiu tych problemów, ponieważ zazwyczaj powoduje duże obciążenie co najmniej jednego procesora na serwerze przez potencjalnie kilka dni z rzędu. Jeśli w twoim systemie wystąpi jakakolwiek niestabilność, rozgrzanie systemu i pozostawienie go na długi czas pogorszy sytuację.
Drugą warstwą ochrony przed tego rodzaju uszkodzeniem jest umieszczanie sum kontrolnych danych zapisywanych na dysku w celu ochrony przed błędami zapisu, a następnie ponownego odczytu danych. Suma kontrolna bloku wykonana przez system plików ZFS jest jedną z lepszych implementacji tego. W moim przypadku to, czy korzystałem z ZFS, czy nie, mogło nie mieć znaczenia. Gdyby bity zostały odwrócone, zanim nastąpiła suma kontrolna bloku, wypisałbym niepotrzebne dane – z sumą kontrolną śmieci, aby je dopasować – niezależnie od tego.
Moim następnym krokiem było użycie podziału narzędzie do wzięcia mojego gigantycznego pliku i podzielenia go na więcej kawałków wielkości kęsa - kolejne kilka godzin, aby poczekać, aż to się skończy. Wtedy mógłbym rozpocząć ładowanie dobrych plików, podczas gdy naprawiłem zły.
Biorąc pod uwagę, że wynikowe pliki miały 13 GB każdy, a mój jeden serwer ma 16 GB pamięci RAM, chociaż mogłem naprawić tę jednoznakową literówkę za pomocą vi. Teoretycznie tak powinno być, ale zaczynam mieć wątpliwości, biorąc pod uwagę, jak długo czekałem na ponowne zapisanie pliku:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21495 gsmith 20 0 8542m 8.3g 1544 R 98 53.0 419:56.70 vi datafile-ag
To solidne 7 godzin, które czekałem tylko na naprawienie tej jednej literówki, abym mógł dokończyć ładowanie danych testowych. Jak już mówiłem, poważne generowanie danych nigdy nie jest łatwe.
