PREPARE PostgreSQL 9.3

[Wuu]

Man par nelaimi jālieto SQL. Interesē, kā no PostgreSQL 9.3 izspiest visu maksimālo. Par indeksiem neiet runa.

 

Cik saprotu, https://www.postgresql.org/docs/9.3/static/sql-prepare.htmlir jēdzīgs variants, kas aizsargā arī no SQL injekcijas un panāk maksimālo jaudu no prastiem/bieži lietojamajiem pieprasījumiem.

Man tikai ļoti nepatīk, ka funkcijas glabājas sesijās . Kas pie velna notiek ar sesiju, ja piemēram ir disconects uz pāris sekundēm vai reconnekts?

Nevar šos prepare saglabāt piemēram uz tabulas, kā funkciju?

 

Problēma ir, kā ORM ir drausmīgi lēns. Jo normāla variantā nodarbojas ar ko jocīgi.

 

Pat raw query `select from users where email = 'xxx@xxx.xx'` ir standarta 2x ātrāks, par ORM.

 

Piemēram Mongoosse var ielikt lean(), lai neatgriež objectu. Šim nekādu tādu ekstru nav un atgriežas tikai datus. Sails.js

Edited July 9, 2016 by Wuu

[jurchiks]

Read you some PHP PDO (http://php.net/manual/en/pdo.prepare.php). Man ir vienkārša abstrakcijas bibliotēka: https://github.com/jurchiks/dbhandler

Bet gan jau, ka te tūlīt visi viņu nodirsīs, tā kā vari arī uzcept savu vai meklēt kaut ko citu.

PDO defaultā atgriež rezultātus masīvā (gan numeric indexes, gan string keys); ja grib, lai fetcho objektā, tad skaties fetch() metožu dokumentāciju.

[waplet]

PDO::FETCH_OBJECT

[Wuu]

Njā, piekāšu šitādas datubāzes. Izrādījās, ka pie vainas poolsize, mēģināju palielināt, bet efekts bija tikai minimāli ātrāks. Aizdiršās pools un serveris, sēž gaida, kad būs brīva vieta rindā.

 

Tik un tā priecē fakts, ka parast qurey neizpildās pienācīgā laikā.

select * from users where email = 'xxx@xxx.lv'   izpildās ~50ms / tb pings līdz serverim ir ap 45-55ms.

Bet kā lieto prepare select * from users where email = $1, ['xxx@xxx.lv'] izplidās ~100ms, līdz pat ~150ms, nopietni? 

Kas par čerņu? Kas tā pa miskastes datubāzi, kas find one nevar izpildīt bez aizķeršanās. Es pat uzliku uz digitalocena jaunu serveri, un uzstādīju tīru nekonfigurētu jaunāko PostgreSQL versiju. Un tas pats!

 

Vai arī tas ir normāli? Varbūt es ar mongo pārāk salīdzinu. 

 

Testu veicu ar ~1000 pieprasījumiem pēc kārtas. ~50 paralēli.  Labprāt uzklausītu viedokli par līkajām rokā, ar norādi, kur varētu būt problēma. 

 

Papildinājums

Ar prepere nodefinētu ātrums ir ok, vienīga problemā, ka nevar prepare nodefinēt vissam poolam uzreiz. Nācās loopot katram savienojumam cauri un nosūtīt prepare, līdz brīdim kad tas atkal atslēgsies, tad atkal. 

Edited July 11, 2016 by Wuu

[jurchiks]

Ja tev bremzē nets, tad pie tā nav vainīgs kods.

[briedis]

Kur atrodas db? Man, teiksim no LV, kvērijam nebūs mazāk par 300ms, jo jāslēdzas ASV amazones DB :D

[Wuu]

Nav vainīgs nets, pings ir ierēķināts. "izpildās ~50ms / tb pings līdz serverim ir ap 45-55ms." 

Bet ar šādu ātrumu izpildās tikai plain text queriji, kā  prepare, tā 100ms-150ms.

[jurchiks]

Kas tas par neoptimizētu kveriju, kas izpildās 50ms?? Vai varbūt vnk datu baigi daudz?

[Wuu]

Nē, 50ms ir pings, izpildās 1-2ms, stulbais gaismas ātrums. "select * from users where email = 'xxx@xxx.lv'" <- Viss! uz email ir index. 

Bet kā prepare, tad +~100ms pie pinga.

[jurchiks]

Prepare izpilda vairākus kverijus, cik zinu. Vismaz teorētiski tā vajadzētu būt.

[Wuu]

Uzlauzu, pārrakstīju ORM draiveri un izpildes loģiku. Tagad ORM pats seko līdzi vai prepare ir uz pool clienta vai nav. Ātruma ziņā, iespaidīgi. Tas pie 1k clientu spama.

 

[F3llony]

Pirmkārt, gar DBMS setupu vajadzētu gramstīties tikai DBA, nevis kaut kādiem node-istiem. Pings, ibio rio...

 

Otrkārt, servera specifikācijas, network layout, kur atrodas serveris, kur atrodas klients, un pilnu query plan/explainu - galdā. Te nav tantes Ljubovnas zīlēšanas salons, tie tavi skaitļi nezinot setupu, cik daudz dati, kādi indeksi, kāds konfigs utt. pilnīgi un absolūti neko neizsaka.

 

Kas tur ar tām konekcijām un connection pool?

 

 

Testu veicu ar ~1000 pieprasījumiem pēc kārtas. ~50 paralēli.

 

Ugh? Tev ir aplikācija ar 50 sim. paralēlismu un tevi laiž pie DB? :D Bet ja nopietni, 50 paralēlisms un 1000 top, tas ir 20 pieprasījumi uz konekciju. WTF kind of benchmark strategy is that? Ja tev paralēlisms ir 50, tad tas nozīmē, ka vienlaikus var tikt veikti up-to 50 pieprasījumi, rodas jautājums - no kurienes tie nāk - atsevišķas sistēmas vai arī jodelē no tā paša datora, kur tev aplikācija un postgre stāv? :D Un ja tev ir 50 paralēlisms, un teiksim, 50+50%, eg. 75 connection pool, tad kā connection pool var buut piedirsts? Kaut kā nedarbojas tā tava matemātika.

 

Pie reizes būtu svētīgi pateikt, kas par ORM. Tas arī jāuzmin?....

[Mr.Key]

Neesmu eksperts šajā ziņā, bet par pašsaprotamu uzskatu, ka:

1) ORM ir lēns. Datubāzes SELECT tur ir pati mazākā daļa, jo apkārt ir baisi daudz visa kā, kas saliek datus objektos, ņemas ar metadatiem, utt.

2) PDO prepare utt ir lēnāki par tiešu SQL. Man šķiet, ka PDO nolasa saistīto tabulu metadatus (struktūru), lai zinātu, kādi ir lauku tipi, un izveidotu statement.

3) SELECT no indeksēta lauka būtu jābūt dažām milisekundēm.

 

Kā arī man ir iespaids, ka Tu ne pārāk labi orientējies datubāzēs. Sāc ar to, ka pastrādā ar RDBMS vispār bez PHP vai jel kā cita. Piemēram, RDBMS pasaulē nav tāds "find one". Ir atlase pēc unikāla lauka, kur pēc definīcijas ir iespējams tikai viens vai neviens rezultāts, vai arī atlase ar LIMIT 1.

 

Nākošais solis ir welcome to the world of different DBs, kur katrai datubāzei un arī katras datubāzes dažādām konfigurācijām ir atšķirīgi plusi un mīnusi. Ir vesela joma, kuru sauc par performance tuning (vai performance optimization), kas ir DB pieskaņošana konkrētajai aplikācijai. Pilnīgi normāla un pašsaprotama procedūra. Pilnīgi normāli un pašsaprotami, ka ar standarta iestatījumiem veiktspēja nav ideāla.

[Roze]

2) PDO prepare utt ir lēnāki par tiešu SQL. Man šķiet, ka PDO nolasa saistīto tabulu metadatus (struktūru), lai zinātu, kādi ir lauku tipi, un izveidotu statement.

Webaplikācijām (php) prepared statementus diezgan reti kur var jēdzīgi izmantot, jo tie darbojas tikai sesijas/konekcijas ietvaros.

 

Ko standartā esmu novērojis ir, ka vai nu cilvēki cītīgi loopaa katru (vienuntopašu) kveriju "prepāro", tad izpilda (nav loģikas vai konkrētais kverijs ir iepriekš jau preparots) vai arī pieslēdzas, prepāro, izpilda, atslēdzas .. kur pa lielam tam no performances viedokļa DB ir vairāk darba nekā pārsēt un izpildīt parastu SQL.

 

Lai būtu jēga/ieguvums šādos gadījumos, tad ir jāraksta Stored procedūras, tad efektam ar "prekompilētu" kveriju būtu jābūt līdzīgi kā pēc prepared statementa (bet bez vajadzības to darīt katru reizi). https://www.postgresql.org/docs/current/static/plpgsql-overview.html#PLPGSQL-ADVANTAGES