Jednou z výzev při práci s novým návrhem databáze je, že nevíte, jak velké tabulky nakonec budou, dokud nebudou skutečně naplněny značným množstvím dat. Pokud však návrh musí zohledňovat případné problémy se škálovatelností, nemůžete jej nasadit k získání těchto dat, dokud nebude proveden odhad. Jedním ze způsobů, jak to obejít, je agresivní prototypování věcí. Pro tento účel použijte pracovní hardware, na kterém mohou nové aplikace dočasně žít, zatímco budou třídit podrobnosti, jako je tento. Můžete prostě počítat s tím, že budete muset aplikaci přesunout a případně ji předělat po několika měsících, až budete mít lepší představu, jaká data se v ní objeví.
Dalším způsobem, jak obejít tento problém slepice/vejce, je napsat generátor dat. Ručně vytvořte dostatek ukázkových dat, abyste viděli, jak vypadají, jak jsou husté a jak jsou distribuovány jejich hodnoty. Pak napište něco, co vezme tyto statistiky a vytvoří větší soubor dat podobný tomu. Nikdy to nebude dokonalé, ale nemusí to tak být. Generování obřích datových sad, i když mají některé nedostatky, je stále nejlepší dostupný způsob, jak odhadnout velikost databáze. Existuje tolik zdrojů režie, že je těžké počítat s tím, že jakékoli naměřené velikosti tabulek a indexů založené na něčem, jako jsou vaše data, budou mnohem přesnější než jakýkoli jiný přístup. Existuje důvod, proč nakonec odpovídám na mnoho otázek o problémech souvisejících s výkonem tím, že nejprve pomocí pgbench vytvořím databázi vhodné velikosti.
Generování dat však není snadné. Zejména generování realistických časových razítek je vždy otravné. A bez ohledu na to, jak efektivně si myslíte, že jste je napsali, jejich spuštění obvykle trvá déle, než očekáváte – a ještě déle, než se výsledná data dostanou do databáze a správně indexují.
A bude tomu tak i nadále, bez ohledu na to, kolikrát jste to udělali, protože i když uděláte všechno správně, Murphyho zákony vám budou překážet, aby byla práce bolestivá. Všechny mé počítače doma jsou postaveny z relativně levného PC hardwaru. Není to nejlevnější dostupná věc – mám standardy – ale rozhodně nepoužívám stejnou kvalitu, jakou bych lidem doporučil hledat na serveru. Problém s generováním dat z tohoto týdne připomněl, proč stojí lepší hardware za kritickou práci.
Po vygenerování několika miliard řádků dat a sledování tohoto importu po dobu 10 hodin mě nepotěšilo, že jsem celou práci nechal takto přerušit:
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"
Ukázalo se, že někde uprostřed zápisu 250 GB testovacích dat, které jsem vygeneroval, byl jeden z výstupů řádků poškozen. Dva bity se obrátily a zapsaná data byla chybná. S jistotou nevím, kde se to stalo.
Paměť je nejpravděpodobnějším podezřelým. Skutečné servery používají ECC RAM, a to z dobrého důvodu. Pokud monitorujete systém s velkým množstvím paměti RAM, může být počet chyb v tichosti opravených ECC šokující. RAM, kterou používám doma, je dobrá, ale chybovost v jakékoli paměti bez možností detekce/opravy chyb bude vyšší, než byste si přáli – a nikdy nezjištěna, pokud se nevyskytnou v kódu, který vede ke zhroucení systému. Práce s generováním dat je dobrá při odhalování těchto problémů, protože obvykle zatěžuje alespoň jeden CPU na vašem serveru po dobu potenciálně dní v řadě. Pokud je ve vašem systému nějaká nestabilita, zahřátí systému a jeho ponechání na dlouhou dobu ho zhorší.
Druhou vrstvou ochrany proti tomuto druhu korupce je umístění kontrolních součtů na data zapisovaná na disk, aby se zabránilo chybám při zápisu a následném opětovném čtení dat. Kontrolní součet bloků prováděný souborovým systémem ZFS je jednou z jeho lepších implementací. V mém případě to, zda jsem použil ZFS nebo ne, nemuselo mít žádný vliv. Pokud by se bity přehodily předtím, než došlo ke kontrolnímu součtu bloku, bez ohledu na to bych vypsal nevyžádaná data – s kontrolním součtem nevyžádané pošty, který by jim odpovídal.
Mým dalším krokem bylo použití rozdělení nástroj, který vezme můj obří soubor a rozdělí ho na větší kousky – dalších pár hodin čekání na dokončení. Pak jsem mohl začít načítat dobré soubory, zatímco jsem opravil ten špatný.
Vzhledem k tomu, že výsledné soubory byly 13 GB každý a můj jeden server má 16 GB RAM, i když jsem mohl opravit tento jeden znakový překlep pomocí vi. Teoreticky by to tak mělo být, ale začínám mít pochybnosti vzhledem k tomu, jak dlouho jsem čekal, až se soubor poté znovu odepíše:
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 je solidních 7 hodin, kdy jsem čekal jen na opravu tohoto překlepu s jedním znakem, abych mohl dokončit načítání testovacích dat. Jak jsem řekl, generování seriózních dat není nikdy snadné.