Зареждане на големи данни? За повече скорост, предварително сортиране и групово зареждане
Намирането на повече скорост при зареждане на големи данни е предизвикателство в ETL, reorg и индекс на много голяма база данни (VLDB) попълват операции. Един от начините за по-бързо зареждане на големи данни е чрез предварителното им сортиране, така че базата данни да не се сортира. IBM и други доставчици на мейнфрейм бази данни дават този съвет от десетилетия и той все още е вярен в релационните бази данни, използвани в Unix и други „отворени системи“ днес, включително Oracle, DB2, Sybase и SQL Server.
Бенчмарковете в тази област показват подобрения спрямо несортирани товари в зависимост от обема, но доставчици на сортиране като IRI твърдят, че производителността на натоварване се е подобрила между два и десет пъти. В доклада на TUSC Consulting „Влияние на индекса за сравнителен анализ върху скоростите на зареждане на OLTP и възстановяване на размера на блока на онлайн базата данни в Oracle“, само тест за вмъкване на единичен индекс от 100 000 реда показа, че предварително сортираните данни се зареждат с 58% по-бързо и изискват 49% по-малко пространство:
- Зареждането в сортиран ред имаше 42% по-ниска продължителност на редове/секунда.
- Несортирани вмъквания в индекси принуждават да се извършва повече вътрешна работа на базата данни (управление на блокове и реорганизация на пространството)
- В индексите, сортирани по натоварване, коефициентът на клъстериране ще бъде близо до броя на листовите блокове.
- Редът на заредените данни е от решаващо значение за ефективността на зареждането.
Много години по-късно, в глава 13 от своето ръководство „Expert Oracle Database 11g Administration“, Сам Р. Алапати (Miro Consulting) препоръчва предварително сортиране във връзка с директни натоварвания по пътя като най-бързия начин за групово зареждане на Oracle (срещу вмъквания):
„ Зареждането по директен път опцията не използва оператора SQL INSERT за поставяне на данни в таблици; по-скоро той форматира блокове от данни на Oracle и ги записва директно във файловете на базата данни. Този процес на директно записване елиминира голяма част от режийните разходи, свързани с изпълнението на SQL изрази за зареждане на таблици. Тъй като методът за зареждане по директен път не се бори за ресурси на базата данни, той ще зареди данни много по-бързо от конвенционалното зареждане на данни. За по-голямо натоварване на данни, методът за зареждане по директен път е най-добър и може да е единственият жизнеспособен метод за зареждане на данни в таблици поради простата причина, че конвенционалното натоварване може да изисква повече време, отколкото е налично.“
За администраторите на VLDB днес, това е мястото, където CoSort идва, тъй като:
„Освен очевидните предимства на по-краткото време за зареждане, директното зареждане също ви помага да изградите отново индекси и данни за предварително сортиране на таблицата.”
CoSort традиционно се използва при външното предварително сортиране на плосък файл, който ще бъде импортирането към зареждане, указващо „direct=true“ и тази опция:
„SORTED INDEXES:Параметърът SORTED_INDEXES сигнализира на SQL*Loader, че данните са сортирани по определен индекс, което подобрява производителността на зареждане.“
По подобен начин документацията на Microsoft SQL Server определя предварителното сортиране на файлове като един от „Методите за оптимизиране на груповото импортиране“:
По подразбиране операцията за групово импортиране предполага, че файлът с данни не е подреден. Ако таблицата има клъстериран индекс, bcp помощна програма, израз BULK INSERT и функция OPENROWSET(BULK...) (Transact-SQL) ви позволяват да укажете как данните във файла с данни се сортират по време на операция за групово импортиране. Не е задължително данните във файла с данни да бъдат сортирани в същия ред като таблицата. Въпреки това, можете да подобрите производителността на операцията за групово импортиране, ако посочите същата подредба за файла с данни като таблицата.
Полето /KEY в скрипт CoSort SortCL обикновено е най-дългият индексен (първичен) ключ в таблицата, но не е задължително. Според TUSC за подобни колони:
- По-малко по-дълги индекси са за предпочитане пред повече по-къси индекси
- Водещата колона определя разходите за зареждане на индекса
Имайте предвид също, че:
- За Vertica и други RDBMS праймери, поддържането на колони в сортирани редове оптимизира производителността на заявката. Дори старият съвет в Ръководството за Rdb/VMS на DEC за поддръжка и производителност на базата данни все още е верен:
„Сортирайте предварително записите, които планирате да съхранявате в таблица, по стойност на първичен ключ, преди да ги заредите в базата данни. Когато записите се заредят, те ще бъдат физически съседни един до друг или групирани, докато в базата данни не се съхранят допълнителни записи. Поддържането на това подреждане е от полза за заявки, които избират редове въз основа на диапазон от стойности или които съединяват много редове от една таблица с редове в същата таблица.“
- Предварителното сортиране на данни в таблици може да спести време и в изгледите. Според „Oracle Database 10g:The Complete Reference“ от Кевин Лони:
„Сортирането на данните в изгледа може да опрости разработването на вашето приложение. Например, ако кодът ви преминава през набор от записи, предварителното сортиране на тези записи може да направи обработката и проверката на грешки по-лесни. При разработването на вашето приложение ще знаете, че данните винаги ще ви се връщат по подреден начин.”
- Г-н Alapati предупреждава администраторите на база данни за ограничение на директните натоварвания на пътя:
„Забележка:При директно натоварване не можете да използвате никакви SQL функции. Ако трябва да извършите голямо натоварване на данни и също така да трансформирате данните по време на зареждане, имате проблем. Конвенционалното натоварване на данни ще ви позволи да използвате SQL функции за трансформиране на данни, но методът е много бавен в сравнение с директното натоварване. По този начин, за големи натоварвания на данни, може да искате да обмислите използването на една от по-новите техники за зареждане/трансформиране, като външни таблици или функции на таблици.“
Програмата SortCL на CoSort обаче може да трансформира данните за зареждане по време на предварително сортиране; чрез комбиниране на същия тип SQL функции в един и същ скрипт за работа и I/O пас, включително:обединения, агрегиране, кръстосани изчисления, търсения, избор/филтриране, функции на подниз и низ, както и множество цели за преформатиране и персонализиран отчет — в същата операция за предварително сортиране.
- Новата помощна програма за офлайн реорганизация в IRI Workbench (Eclipse GUI) използва IRI FACT (Бързо извличане) за бързо разтоварване на данни от таблицата чрез OCI, използва CoSort за предварително сортиране на първичния ключ и записва и изпълнява SQL*Loader директно натоварвания на пътя, за да оптимизирате и комбинирате всяка от тези стъпки.
