Едно от предизвикателствата при работа с нов дизайн на база данни е, че не знаете неща като това колко големи ще бъдат таблиците, докато действително не бъдат попълнени с достатъчен обем данни. Но ако дизайнът трябва да вземе предвид евентуалните проблеми с мащабируемостта, не можете да го разгърнете, за да получите тези данни, докато не бъде направена оценката. Един от начините да заобиколите това е агресивно прототипиране на неща. За тази цел използвайте стационарния хардуер, с който новите приложения могат да работят временно, докато сортирате подробности като този. Можете просто да вземете предвид, че ще трябва да преместите приложението и евентуално да го преработите след няколко месеца, когато имате по-добра представа какви данни ще се показват в него.
Другият начин да заобиколите този проблем с пиле/яйце е да напишете генератор на данни. Създайте достатъчно примерни данни на ръка, за да видите как изглежда, колко плътно е и как се разпределят стойностите му. След това напишете нещо, което взема тези статистически данни и произвежда по-голям набор от данни, подобен на него. Никога няма да го постигнете идеално, но не е задължително. Генерирането на гигантски набори от данни, дори с някои недостатъци, все още е най-добрият наличен начин за оценка на размера на базата данни. Има толкова много източници на режийни разходи, че е трудно да се отчете, че всички измерени размери на таблица и индекс, базирани на нещо като вашите данни, ще бъдат много по-точни от всеки друг подход. Има причина, поради която в крайна сметка отговарям на много въпроси относно опасенията, свързани с производителността, като използвам pgbench, за да създам първо база данни с подходящ размер.
Генерирането на данни обаче не е лесно. По-специално генерирането на реалистични времеви марки винаги е досадно. И без значение колко ефективно смятате, че сте ги написали, те обикновено отнемат повече време, отколкото очаквате да се изпълняват – и дори повече, за да получите получените данни в база данни и правилно индексирани.
И това продължава да е така, независимо колко пъти сте правили това, защото дори и да направите всичко правилно, Законът на Мърфи ще се намеси, за да направи работата болезнена независимо. Всички мои компютри у дома са изградени от сравнително евтин компютърен хардуер. Не е най-евтините налични неща – имам стандарти – но със сигурност не използвам същото качество, бих препоръчал на хората да търсят в сървър. Проблемът с генерирането на данни тази седмица напомни защо по-добрият хардуер струва колко струва за критична за бизнеса работа.
След като генерирах няколко милиарда реда данни и гледах импортирането в продължение на 10 часа, не ми беше приятно цялата работа да бъде прекъсната по следния начин:
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"
Оказа се, че някъде по средата на записването на 250 GB тестови данни, които генерирах, един от изходните линии беше повреден. Два бита се обърнаха и изписаните данни бяха грешни. Не знам къде се е случило това със сигурност.
Паметта е най-вероятният заподозрян. Истинските сървъри използват ECC RAM и с добра причина. Ако наблюдавате система с много RAM, броят на грешките, коригирани безшумно от ECC, може да бъде шокиращ. RAM паметта, която използвам у дома, е добра, но процентите на грешки във всяка памет без възможности за откриване/коригиране на грешки ще бъдат по-високи, отколкото бихте искали – и никога не се откриват, освен ако не се случат в код, който води до срив на системата. Работата по генериране на данни е добра за разкриването на тези проблеми, тъй като обикновено поставя поне един процесор на вашия сървър под голямо натоварване за потенциално дни подред. Ако има някаква нестабилност във вашата система, загряването на системата и оставянето й да работи за дълго време ще я влоши.
Вторият слой на защита срещу този вид корупция е поставянето на контролни суми върху данните, които се записват на диск, за защита срещу грешки при записване и след това обратно четене на данните. Блоковата контролна сума, извършена от файловата система ZFS, е една от по-добрите реализации на това. В моя случай, дали съм използвал ZFS или не, може да не е имало никаква разлика. Ако битовете бяха обърнати преди да се случи блоковата контролна сума, щях да изпиша нежелани данни – с нежелана контролна сума, която да я съвпада – независимо.
Следващата ми стъпка беше да използвам split помощна програма, за да взема моя гигантски файл и да го разбия на по-големи парчета – още няколко часа, за да изчакам това да приключи. Тогава можех да започна да зареждам добрите файлове, докато поправя лошия.
Като се има предвид, че получените файлове бяха по 13 GB всеки и моят един сървър има 16 GB RAM, въпреки че можех да поправя тази печатна грешка с един знак с помощта на vi. Теоретично това трябва да е така, но започвам да се съмнявам, като се има предвид колко дълго чаках файлът да се изпише отново след това:
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
Това са солидни 7 часа, които чаках само тази печатна грешка с един знак да бъде поправена, за да мога да завърша зареждането на тестовите данни. Както казах, генерирането на сериозни данни никога не е лесно.
