Jump to content
php.lv forumi

PREPARE PostgreSQL 9.3


Wuu

Recommended Posts

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 = '[email protected]'` 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 by Wuu
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 = '[email protected]'   izpildās ~50ms / tb pings līdz serverim ir ap 45-55ms.

Bet kā lieto prepare select * from users where email = $1, ['[email protected]'] 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 by Wuu
Link to comment
Share on other sites

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?....

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...