[Fukiku]

Stsenaarium järgmine: on tabel 6 miljoni kirjega, kust rakendus pärib ridu kahe veeru alusel. Enamasti peaks vastuseks tulema üks rida, mõnikord rohkem, aga harva. Loodud on ka index, mis hõlmab täpselt neid kahte veergu, kumbki neist pole primary key. Hetkel jookseb päring ca 1,5 sekundit.

Kas mingi indeksitega trikitamisega õnnestuks seda veel kiiremaks saada? Igasuguste indeksite ja muude sättungitega saan suhteliselt vabalt toimetada, kuna seda baasi ükski teine rakendus ei kasuta. Rakenduskihis on Java ja Hibernate, aga baasi poolt vaadates ei saa vast neid süüdistada, sest enam lihtsamaks seda päringut ka vast käsitsi ei kirjuta. Juba praegu on Hibernate poolt genereeritud umbkaudu "SELECT * FROM table WHERE this AND that"

Suuremas pildis on päring osa andmete migreerimisest legacy süsteemist uude süsteemi ja migreerimist tahab ca 1,4 miljonit kirjet. Ühe kirje migreerimine võtab koos selle 1,5 sekundit päringuga ca 3 sekundit ja sellises tempos on kogu töö kestus poolteist kuud. Seega, kui saaks päringust veel mingi pool sekundit või sekund maha, oleks summaarne ajavõit arvutatav päevades, et mitte öelda nädalates.

Kui on vaja lisainfot, siis jagan võimaluse piires ja anonümiseeritult..

[Mnator]

Proovi siiski C++ ära. Ehki väidad nagu java poleks pidur.

[Renka]

Fukiku, ma ei saa nüüd aru kas tegu on konreetselt päringu peale kuluva ajaga või läheb sinna sisse ka kogu muu overhead mis tuleneb Java ja ühenduse loomise poolelt?

Muidu alati on päringute puhul ju abiks EXPLAIN Või misiganes analoog MSSQL'il ka ei ole.

[Fukiku]

Ma ei näe, kuidas saab Java pidur olla, kui ma rakenduse poolt näen, et asi seisab päringu taga 1,5 sekundit ja ka SQL Serveri activity monitor näitab päringu kestuseks ~1500 millisekundit. Kõrval teine päring view pihta, mille taga on viis tabelit, jookseb 100 millisekundiga ja on ka rakenduse poolt vaadates väga kiire, samas seal ei ole muid piiravaid tingimusi peale tabelite omavahelise joinimise. Ühe suht primitiivse WHERE tingimusega lendas selle kestus ka nelja sekundi peale.. aga see oli näpukas, seda tingimust polnud tegelikult vaja.

Ühesõnaga - ma ei näe, et pidur oleks rakenduskihis. Pealegi, uues keeles rakenduse uuesti kirjutamine võtaks mul ilmselt kogu selle aja ära, mida ma hüpoteetilise jõudluse kasvuga säästaks..

[Renka]

Fukiku, see on ju lihtsalt testitav. Lase sama päring otse baasis käima.

Igatahes kui see rakenduse osa on välistatud eks siis tuleb baasi poolelt aadata, et kuidas indekseid kasutatakse. EXPLAIN PLAN vmt analoog on ju sellejaoks täpselt õige tööriist. Võibolla ei kasutatagi indekseid millegi pärast? Või on ehk mälu nii vähe füüsiliselt (või virtuaalselt piiratud), et indekseid ei hoitagi mälus ning kettalt lugemine võtab aega? Või on siis andmemahud mis liiguvad serverite vahel niivõrd suured, et kaob aeg sinna?

Samas IMHO peaksid sa selliseid elementaarseid debugimise meetodeid ju minust paremini teadma

[Fukiku]

Renka, baasi optimeerimist ja debugimist pole eriti ette tulnud varem. Seega selles vallas nii kõva käpp ei ole.

Hetkel aga hablasin lahti, milles küsimus on vist ja ega sel viisil suurt vist midagi teha ka pole.. kuigi ma natuke uurin veel. Ühesõnaga, Hibernate genereerib sellise päringu:

[Renka]

Fukiku, vaata ehk on sellest abi: http://msdn.microsoft.com/en-us/library/bb510478(v=sql.105).aspx

Peaks teoorias forcema Index Seek'i.

[mattiaza]

Kas MSSQLis on olemas (või üldse vajalik) midagi sarnast PostgreSQLi "VACUUM ANALYZE" käsule?

PostgreSQLis see "defragmenteerib" tabelis olevaid andmeid, garbage collect'ib kustutatud kirjeid ja arvutab uued statistilised näitajad tabeli suuruse ja väärtuste jaotuse kohta. Vahel kui planeerija halba execution plani (seeki asemel scanid) pakub, siis põhjuseks on aegunud statistilised näitajad.

[DoS]

Mis tüüpi need väljad on? Võimalik, et tegu on selle NVARCHAR vs VARCHAR probleemiga:

http://stackoverflow.com/q/6544865
http://stackoverflow.com/q/1306774
http://stackoverflow.com/q/5237280
jne.

[iFlop]

Äkki on võimalik (vajalike) andmeid korraga eksportida ning mingit muud teed pidi uude süsteemi importida? Juhul kui üks kirje on näiteks 1kB, siis peaks see isegi mällu mahtuma: 6 miljoni kirjet ~6GB ja 1,4m ~1,4GB
Kui peaksid javas tegutsema, siis mingisugune hashmap oleks ehk abiks...

[napoleon]

Tõenäoliselt tead seda isegi, aga nii igaks juhuks lisan, et ka väljade järjekord indeksis on oluline. Ehk siis peaks andmetele otsa vaatama ja panema indeksis esimeseks välja selle, mis andmete hulka rohkem kitsendab. Kui need on umbes 50-50, siis muidugi vahet pole.

Kui seal migreerimise osas väga keerukat äriloogikat taga pole, siis võib alternatiiv ka see olla, et tõmmata need 1,4 miljonit kirjet kuhugi tabelisse ja teha migreerimiseks stored proc või siis kasutada vahendit, mis suudab päringud mssql jaoks paremal kujul ette sööta.

[Fukiku]

Tänud kõiki kaasa mõtlemast, peaauhinna saab sedakorda DoS

Selgus, et kühvel suuresti oligi selles, et väljad olid VARCHAR, aga MS SQL'i JDBC draiver vaikimisi saatis kõik parameetrid baasi NVARCHAR tüübina. Kuna tüübid täpselt ei sobinud, siis läks index seek asemel käiku index scan, mis oli kosmiliselt aeglasem. Kõige lihtsam ja valutum lahendus oli hetkel asjakohased väljad NVARCHAR'iks konverteerida ja index uuesti ehitada. Sain päringu kiiruse millisekunditesse.

Tänud veel kord kaasa mõtlemast. Sain ka ise jälle palju targemaks.