Abdi nyarankeun anjeun maca transkrip laporan awal 2016 Vladimir Sitnikov "PostgreSQL sareng JDBC nyerep sadaya jus"
Wilujeng sonten Nami abdi Vladimir Sitnikov. Kuring geus digawé pikeun NetCracker pikeun 10 taun. Sareng kuring lolobana kana produktivitas. Sadayana anu aya hubunganana sareng Java, sadayana anu aya hubunganana sareng SQL mangrupikeun anu kuring resep.
Sareng dinten ayeuna kuring bakal nyarioskeun naon anu urang tepang di perusahaan nalika urang ngamimitian nganggo PostgreSQL salaku server database. Sarta kami lolobana gawé bareng Java. Tapi naon anu kuring badé terangkeun ayeuna sanés ngan ukur ngeunaan Jawa. Salaku prakték geus ditémbongkeun, ieu ogé lumangsung dina basa séjén.
Urang bakal ngobrol:
- ngeunaan sampling data.
- Ngeunaan nyimpen data.
- Sarta ogé ngeunaan kinerja.
- Jeung ngeunaan rakes jero cai anu dikubur di dinya.
Hayu urang mimitian ku patarosan basajan. Urang milih hiji baris tina tabel dumasar kana konci primér.
Pangkalan data aya dina host anu sami. Sareng sadaya pertanian ieu butuh 20 milliseconds.
20 milidetik ieu seueur pisan. Upami anjeun gaduh 100 pamundut sapertos kitu, teras anjeun nyéépkeun waktos per detik pikeun ngagulung pamundut ieu, nyaéta kami ngabuang waktos.
Kami henteu resep ngalakukeun ieu sareng ningali naon dasarna nawiskeun kami pikeun ieu. Pangkalan data nawiskeun kami dua pilihan pikeun ngaéksekusi patarosan.
Pilihan kahiji nyaéta pamundut basajan. Naon anu hadé ngeunaan éta? Kanyataan yén urang nyandak eta sarta ngirimkeunana, jeung sia leuwih.
Pangkalan data ogé ngagaduhan pamundut canggih, anu langkung rumit, tapi langkung fungsional. Anjeun tiasa misah ngirim pamundut pikeun parsing, palaksanaan, variabel mengikat, jsb.
Paménta super ngalegaan mangrupikeun hal anu urang moal nutupan dina laporan ayeuna. Urang, meureun, hayang hiji hal ti database jeung aya hiji wishlist nu geus kabentuk dina sababaraha bentuk, i.e. ieu naon urang hayang, tapi teu mungkin ayeuna jeung taun saterusna. Janten urang ngan ukur ngarékam éta sareng urang bakal ngurilingan jalma utama.
Jeung naon bisa urang pigawé nyaéta query basajan tur query nambahan.
Naon husus ngeunaan unggal pendekatan?
A query basajan téh alus pikeun hiji-waktos palaksanaan. Sakali rengse jeung poho. Sareng masalahna nyaéta yén éta henteu ngadukung format data binér, nyaéta henteu cocog pikeun sababaraha sistem kinerja tinggi.
Paménta anu diperpanjang - ngamungkinkeun anjeun ngahémat waktos dina parsing. Ieu anu urang laksanakeun sareng mimitian nganggo. Ieu bener-bener mantuan kami. Aya henteu ngan tabungan dina parsing. Aya tabungan dina mindahkeun data. Mindahkeun data dina format binér leuwih efisien.
Hayu urang teraskeun latihan. Ieu mangrupikeun aplikasi anu biasa. Bisa jadi Jawa, jsb.
Kami nyiptakeun pernyataan. Dilaksanakeun paréntah. Kacipta deukeut. Dimana kasalahan di dieu? Naon masalahna? Henteu masalah. Ieu naon nyebutkeun dina sakabéh buku. Ieu kumaha kudu ditulis. Upami anjeun hoyong prestasi anu maksimal, nyerat sapertos kieu.
Tapi prakték nunjukkeun yén ieu henteu jalan. Naha? Kusabab urang gaduh metode "deukeut". Sareng nalika urang ngalakukeun ieu, tina sudut pandang database tétéla yén éta sapertos perokok damel sareng database. Kami nyarios "PARSE EXECUTE DEALLOCATE".
Naha sadaya kreasi tambahan ieu sareng ngabongkar pernyataan? Teu aya anu peryogi aranjeunna. Tapi anu biasana kajadian dina PreparedStatements nyaéta nalika urang nutup aranjeunna, aranjeunna nutup sadayana dina pangkalan data. Ieu teu naon urang hayang.
Kami hoyong, sapertos jalma séhat, damel sareng dasarna. Kami nyandak sareng nyiapkeun pernyataan kami sakali, teras kami laksanakeun sababaraha kali. Kanyataanna, sababaraha kali - ieu sakali dina sakabéh kahirupan aplikasi - aranjeunna geus parsed. Sareng kami nganggo id pernyataan anu sami dina REST anu béda. Ieu tujuan urang.
Kumaha urang tiasa ngahontal ieu?
Éta saderhana pisan - henteu kedah nutup pernyataan. Kami nyerat sapertos kieu: "nyiapkeun" "ngalaksanakeun".
Upami urang ngaluncurkeun anu sapertos kieu, maka jelas yén aya anu bakal ngabahekeun dimana waé. Upami teu jelas, anjeun tiasa nyobian éta. Hayu urang nulis patokan anu ngagunakeun métode basajan ieu. Jieun hiji pernyataan. Urang ngajalankeun eta dina sababaraha versi supir jeung manggihan yén éta ngadat rada gancang jeung leungitna sakabeh memori nu tadi.
Ieu jelas yén kasalahan sapertos gampang dilereskeun. Kuring moal ngobrol ngeunaan aranjeunna. Tapi kuring bakal nyebutkeun yén versi anyar jalan leuwih gancang. Metoda ieu bodo, tapi tetep.
Kumaha carana dianggo leres? Naon anu kudu urang pigawé pikeun ieu?
Dina kanyataanana, aplikasi sok nutup pernyataan. Dina sagala buku maranéhna ngomong nutup eta, disebutkeun memori bakal bocor.
Jeung PostgreSQL teu nyaho kumaha carana cache queries. Perlu unggal sési nyiptakeun cache ieu nyalira.
Sareng urang ogé henteu hoyong miceunan waktos dina parsing.
Sareng sapertos biasa urang gaduh dua pilihan.
Pilihan kahiji nyaeta urang nyandak eta sarta nyebutkeun yén hayu urang mungkus sagalana di PgSQL. Aya cache di dinya. Ieu caches sagalana. Bakal tétéla hébat. Urang nempo ieu. Simkuring gaduh 100500 requests. Teu hasil. Kami henteu satuju pikeun ngarobih pamundut kana prosedur sacara manual. Henteu henteu.
Kami gaduh pilihan kadua - nyandak sareng motong nyalira. Urang buka sumber tur mimitian motong. Urang nempo jeung nempo. Tétéla éta teu jadi hésé ngalakukeun.
Ieu muncul dina Agustus 2015. Ayeuna aya versi anu langkung modern. Jeung sagalana hébat. Gawéna saé pisan sahingga urang henteu ngarobih nanaon dina aplikasi. Sarta kami malah dieureunkeun pamikiran dina arah PgSQL, i.e. ieu rada cukup pikeun urang ngurangan sagala waragad overhead ampir enol.
Sasuai, pernyataan Server-disiapkeun diaktipkeun dina palaksanaan 5th guna ngahindarkeun wasting memori dina database dina unggal pamundut hiji-waktos.
Anjeun tiasa naros - dimana nomerna? Naon anu anjeun kéngingkeun? Sarta di dieu kuring moal masihan angka, sabab unggal pamundut boga sorangan.
Patarosan kami sapertos kitu urang nyéépkeun sakitar 20 milidetik pikeun nga-parsing patarosan OLTP. Aya 0,5 milidetik pikeun palaksanaan, 20 milidetik pikeun parsing. Paménta - 10 KiB téks, 170 garis rencana. Ieu mangrupikeun pamundut OLTP. Ieu requests 1, 5, 10 garis, kadang leuwih.
Tapi urang teu hayang runtah 20 milliseconds pisan. Urang ngurangan kana 0. Sagalana hébat.
Naon anu anjeun tiasa angkat ti dieu? Upami Anjeun gaduh Java, mangka anjeun nyokot versi modern tina supir jeung girang.
Upami anjeun nyarios basa anu sanés, teras pikir - panginten anjeun ogé peryogi ieu? Kusabab tina sudut pandang basa final, contona, lamun PL 8 atawa anjeun boga LibPQ, lajeng teu atra ka anjeun nu méakkeun waktu teu on palaksanaan, on parsing, sarta ieu patut dipariksa. Kumaha? Sadayana gratis.
Iwal yén aya kasalahan sarta sababaraha peculiarities. Sarta kami bakal ngobrol ngeunaan aranjeunna ayeuna. Kalolobaan eta bakal ngeunaan arkeologi industri, ngeunaan naon urang kapanggih, naon urang datang di sakuliah.
Lamun pamundut dihasilkeun dinamis. Eta kajadian. Batur glues string babarengan, hasilna query SQL.
Naha anjeunna goréng? Éta goréng sabab unggal waktos urang mungkas ku senar anu béda.
Sareng kode hash tina senar anu béda ieu kedah dibaca deui. Ieu leres-leres tugas CPU - milarian téks pamundut anu panjang bahkan dina hash anu tos aya henteu gampang. Ku alatan éta, kacindekan basajan - ulah ngahasilkeun requests. Simpen aranjeunna dina hiji variabel. Jeung girang.
Masalah salajengna. Jinis data penting. Aya ORM anu nyarios yén henteu masalah naon waé NULL anu aya, hayu waé aya nanaon. Lamun Int, lajeng urang nyebutkeun setInt. Sareng upami NULL, teras janten VARCHAR. Sareng naon bédana dina tungtungna naon NULL anu aya? Database sorangan bakal ngartos sadayana. Jeung gambar ieu teu jalan.
Dina prakna, pangkalan data henteu paduli pisan. Upami anjeun nyarios pertama kalina yén ieu mangrupikeun nomer, sareng kadua kalina anjeun nyarios yén éta mangrupikeun VARCHAR, maka mustahil pikeun nganggo deui pernyataan anu disusun ku Server. Sareng dina hal ieu, urang kedah nyiptakeun deui pernyataan urang.
Upami anjeun ngalaksanakeun pamundut anu sami, pastikeun yén jinis data dina kolom anjeun henteu bingung. Anjeun kedah awas pikeun NULL. Ieu kasalahan umum urang tadi sanggeus urang mimitian nganggo PreparedStatements
Oké, dihurungkeun. Meureun maranéhna nyokot supir. Sareng produktivitas turun. Hal jadi goréng.
Kumaha ieu kajadian? Naha ieu bug atanapi fitur? Hanjakalna, éta henteu mungkin ngartos naha ieu bug atanapi fitur. Tapi aya hiji skenario basajan pisan pikeun reproducing masalah ieu. Manehna sagemblengna disangka ambushed kami. Sarta eta diwangun ku sampling sacara harfiah tina hiji méja. Kami, tangtosna, ngagaduhan langkung seueur paménta sapertos kitu. Sakumaha aturan, aranjeunna kalebet dua atanapi tilu méja, tapi aya skenario playback sapertos kitu. Candak versi mana wae tina database anjeun sarta maénkeun éta.
Intina nyaéta urang gaduh dua kolom, anu masing-masing diindeks. Aya sajuta baris dina hiji kolom NULL. Jeung kolom kadua ngandung ukur 20 garis. Nalika urang ngaéksekusi tanpa variabel kabeungkeut, sadayana tiasa dianggo.
Lamun urang mimitian executing kalawan variabel kabeungkeut, ie urang ngaéksekusi "?" atawa "$ 1" pikeun pamundut urang, naon urang tungtungna meunang?
Palaksanaan munggaran sapertos anu dipiharep. Anu kadua rada gancang. Aya anu di-cache. Katilu, kaopat, kalima. Lajeng bang - sarta hal kawas éta. Jeung hal awon éta ieu kajadian dina palaksanaan kagenep. Saha anu terang yén perlu ngalakukeun persis genep eksekusi pikeun ngartos naon rencana palaksanaan anu saleresna?
Saha nu salah? Aya naon? Database ngandung optimasi. Sareng sigana dioptimalkeun pikeun kasus umum. Sareng, sasuai, dimimitian dina sababaraha waktos, anjeunna ngalih ka rencana umum, anu, hanjakalna, tiasa janten béda. Bisa jadi sarua, atawa bisa jadi béda. Tur aya sababaraha jenis nilai bangbarung nu ngakibatkeun kabiasaan ieu.
Naon anu anjeun tiasa lakukeun ngeunaan éta? Di dieu, tangtosna, leuwih hese nganggap nanaon. Aya solusi saderhana anu kami anggo. Ieu +0, OFFSET 0. Pasti anjeun terang solusi sapertos kitu. Kami ngan ukur nyandak sareng nambihan "+0" kana pamundut sareng sadayana henteu kunanaon. Kuring gé nunjukkeun anjeun engké.
Sareng aya pilihan sanés - tingali rencanana langkung ati-ati. Pamekar henteu ngan ukur kedah nyerat pamundut, tapi ogé nyarios "ngajelaskeun nganalisa" 6 kali. Upami éta 5, éta moal jalan.
Sareng aya pilihan katilu - nyerat surat ka pgsql-hacker. Kuring nyerat, kumaha ogé, éta henteu acan écés naha ieu mangrupikeun bug atanapi fitur.
Nalika urang mikir naha ieu bug atanapi fitur, hayu urang ngalereskeunana. Hayu urang nyandak pamundut urang jeung tambahkeun "+0". Sagalana geus rupa. Dua simbol jeung anjeun malah teu kudu mikir ngeunaan kumaha éta atawa naon éta. Basajan pisan. Urang ngan ukur ngalarang pangkalan data ngagunakeun indéks dina kolom ieu. Kami henteu gaduh indéks dina kolom "+0" sareng éta, pangkalan data henteu nganggo indéks, sadayana henteu kunanaon.
Ieu aturan 6 ngajelaskeun. Ayeuna dina vérsi ayeuna anjeun kedah ngalakukeunana 6 kali upami anjeun gaduh variabel kabeungkeut. Upami anjeun teu gaduh variabel anu terikat, ieu anu urang laksanakeun. Sarta pamustunganana éta persis pamundut ieu nu gagal. Ieu lain hal tricky.
Ieu bakal sigana, sabaraha mungkin? Kutu di dieu, kutu di ditu. Sabenerna, bug aya dimana-mana.
Hayu urang nempo leuwih deukeut. Contona, urang boga dua schemas. Skéma A kalawan tabél S jeung diagram B kalawan tabel S. Query - pilih data tina tabel. Naon anu bakal urang gaduh dina hal ieu? Urang bakal boga kasalahan. Urang bakal gaduh sadayana di luhur. Aturanna nyaéta - bug aya dimana-mana, urang bakal ngagaduhan sadayana di luhur.
Ayeuna patarosan anu: "Naha?" Ieu bakal sigana nu aya dokuméntasi yén lamun urang boga schema a, lajeng aya variabel "search_path" nu ngabejaan urang dimana néangan tabél. Ieu bakal sigana nu aya variabel a.
Naon masalahna? Masalahna nyaeta pernyataan server-disiapkeun teu nyangka yén search_path bisa dirobah ku batur. Nilai ieu tetep konstan pikeun pangkalan data. Jeung sababaraha bagian bisa jadi teu nyokot harti anyar.
Tangtosna, ieu gumantung kana versi anu anjeun uji. Gumantung kana kumaha serius tabel anjeun béda. Sareng versi 9.1 ngan saukur bakal ngaéksekusi pamundut anu lami. Versi anyar tiasa nangkep bug sareng nyarioskeun yén anjeun gaduh bug.
Kumaha ngubaranana? Aya resep basajan - ulah ngalakukeun eta. Henteu kedah ngarobih search_path nalika aplikasi dijalankeun. Upami anjeun robih, langkung saé ngadamel sambungan énggal.
Anjeun tiasa ngabahas, nyaéta muka, ngabahas, nambahan. Panginten urang tiasa ngayakinkeun pamekar database yén nalika aya anu ngarobih nilai, pangkalan data kedah nyarioskeun ka klien ngeunaan ieu: "Tingali, nilai anjeun parantos diropéa di dieu. Panginten anjeun kedah ngareset pernyataan sareng nyiptakeun deui?" Ayeuna database behaves cicingeun jeung teu ngalaporkeun sagala cara nu pernyataan geus robah wae di jero.
Sareng kuring bakal ngantebkeun deui - ieu mangrupikeun hal anu henteu khas pikeun Java. Urang bakal ningali hal anu sami dina PL / pgSQL hiji-hiji. Tapi bakal dihasilkeun di dinya.
Hayu urang cobaan sababaraha pilihan data deui. Urang milih jeung milih. Simkuring gaduh méja kalayan sajuta jajar. Unggal garis nyaéta kilobyte. Kira-kira gigabyte data. Sarta kami boga memori gawe dina mesin Java 128 megabyte.
Kami, sakumaha anu disarankeun dina sadaya buku, nganggo pamrosésan aliran. Hartina, urang muka resultSet jeung maca data ti dinya saeutik-saeutik. Dupi éta dianggo? Naha bakal murag tina mémori? Naha anjeun badé maca sakedik? Hayu urang percanten kana pangkalan data, hayu urang percanten ka Postgres. Kami henteu percanten. Naha urang bakal kaluar OutOFMemory? Saha anu ngalaman OutOfMemory? Anu junun ngalereskeun eta sanggeus éta? Batur junun ngalereskeun eta.
Upami Anjeun gaduh sajuta jajar, Anjeun teu bisa ngan nyokot tur milih. OFFSET / LIMIT diperlukeun. Saha pikeun pilihan ieu? Sareng saha anu resep maén sareng autoCommit?
Di dieu, sapertos biasa, pilihan anu paling teu kaduga tétéla leres. Sareng upami anjeun ujug-ujug mareuman autoCommit, éta bakal ngabantosan. Kunaon éta? Élmu henteu terang ngeunaan ieu.
Tapi sacara standar, sadaya klien anu nyambung ka database Postgres nyandak sadayana data. PgJDBC teu aya pengecualian dina hal ieu; éta milih sadaya baris.
Aya variasi dina téma FetchSize, nyaéta anjeun tiasa nyarios dina tingkat pernyataan anu misah di dieu, mangga pilih data ku 10, 50. Tapi ieu henteu jalan dugi ka mareuman autocommit. Pareuman autocommit - éta mimiti jalan.
Tapi ngaliwat kode sareng netepkeun setFetchSize di mana waé henteu pikaresepeun. Kituna, urang nyieun setelan nu bakal nyebutkeun nilai standar pikeun sakabéh sambungan.
Kitu ceuk urang. Parameter parantos dikonpigurasikeun. Sareng naon anu urang kéngingkeun? Upami urang milih jumlah leutik, upami, contona, urang milih 10 baris sakaligus, maka urang gaduh biaya overhead anu ageung pisan. Ku alatan éta, nilai ieu kudu disetel ka kira saratus.
Ideally, tangtosna, anjeun masih kudu diajar kumaha carana ngawatesan eta dina bait, tapi resep ieu: set defaultRowFetchSize ka leuwih ti saratus sarta jadi senang.
Hayu urang ngaléngkah ka inserting data. Selapkeun langkung gampang, aya pilihan anu béda. Contona, INSERT, VALUE. Ieu pilihan alus. Anjeun tiasa ngucapkeun "INSERT SELECT". Dina prakték éta hal anu sarua. Henteu aya bédana dina pagelaran.
Buku nyarios yén anjeun kedah ngaéksekusi pernyataan Batch, buku nyarios yén anjeun tiasa ngalaksanakeun paréntah anu langkung rumit kalayan sababaraha kurung. Sareng Postgres gaduh fitur anu saé - anjeun tiasa ngalakukeun COPY, nyaéta ngalakukeunana langkung gancang.
Lamun ngukur eta, anjeun bisa deui nyieun sababaraha pamanggihan metot. Kumaha urang hoyong ieu jalan? Kami hoyong henteu nga-parse sareng henteu ngalaksanakeun paréntah anu teu perlu.
Dina prakték, TCP teu ngidinan urang ngalakukeun ieu. Lamun klien sibuk ngirim pamundut a, lajeng database teu maca requests dina usaha pikeun ngirim kami réspon. Hasil ahir nyaéta yén klien ngantosan database pikeun maca pamundut, sareng pangkalan data ngantosan klien maca réspon.
Ku kituna klien kapaksa périodik ngirim pakét sinkronisasi. Interaksi jaringan tambahan, runtah tambahan waktos.
Sareng langkung seueur urang nambihanana, langkung parah. Supirna rada pesimis sareng sering nambihanana, sakitar sakali unggal 200 jalur, gumantung kana ukuran jalur, jsb.
Éta kajadian yén anjeun ngabenerkeun ngan hiji garis sareng sadayana bakal nyepetkeun 10 kali. Eta kajadian. Naha? Sakumaha biasa, konstanta sapertos kieu parantos dianggo dimana waé. Jeung nilai "128" dimaksudkan teu make batching.
Ieu alus nu ieu teu kaasup dina versi resmi. Kapanggih saméméh release dimimitian. Sadaya hartos anu kuring masihan dumasar kana versi modéren.
Hayu urang coba eta on. Urang ngukur InsertBatch basajan. Urang ngukur InsertBatch sababaraha kali, nyaéta hal anu sarua, tapi aya loba nilai. Lengkah licik. Henteu sadayana tiasa ngalakukeun ieu, tapi éta saderhana pisan, langkung gampang tibatan COPY.
Anjeun tiasa ngalakukeun COPY.
Sareng anjeun tiasa ngalakukeun ieu dina struktur. Nyatakeun tipe standar pamaké, lulus Asép Sunandar Sunarya na INSERT langsung kana tabél.
Upami anjeun muka tautan: pgjdbc/ubenchmsrk/InsertBatch.java, teras kode ieu aya dina GitHub. Anjeun tiasa ningali husus requests naon dihasilkeun aya. Henteu masalah.
Urang dibuka. Sareng hal anu munggaran urang sadar yén henteu nganggo bets ngan saukur teu mungkin. Sadaya pilihan batching enol, nyaéta waktos palaksanaan praktis enol dibandingkeun sareng palaksanaan hiji waktos.
Urang ngasupkeun data. Ieu tabel basajan pisan. Tilu kolom. Sareng naon anu urang tingali di dieu? Urang nempo yén sakabéh tilu pilihan ieu kasarna comparable. Sareng COPY, tangtosna, langkung saé.
Ieu nalika urang nyelapkeun potongan. Nalika urang nyarios yén hiji nilai VALUES, dua nilai VALUES, tilu nilai VALUES, atanapi urang nunjukkeun 10 di antarana dipisahkeun ku koma. Ieu ngan horisontal ayeuna. 1, 2, 4, 128. Ieu bisa ditempo yén bets sisipan, nu digambar dina bulao, ngajadikeun anjeunna ngarasa leuwih hadé. Hartina, mun anjeun ngasupkeun hiji-hiji atawa malah mun anjeun ngasupkeun opat dina hiji waktu, eta janten dua kali alus, ngan kusabab urang crammed saeutik leuwih kana NILAI. Pangsaeutikna operasi EXECUTE.
Ngagunakeun COPY dina jilid leutik pisan unpromising. Kuring malah teu ngagambar dina dua kahiji. Aranjeunna angkat ka surga, nyaéta, nomer héjo ieu pikeun COPY.
COPY kedah dianggo upami anjeun gaduh sahenteuna saratus jajar data. Overhead pikeun muka sambungan ieu ageung. Sareng, jujur, kuring henteu ngali arah ieu. Kuring dioptimalkeun bets, tapi teu COPY.
Naon anu urang lakukeun salajengna? Urang diusahakeun eta on. Urang ngarti yén urang kudu make boh struktur atawa bacth palinter nu ngagabungkeun sababaraha harti.
Naon anu anjeun kedahkeun tina laporan dinten ayeuna?
- PreparedStatement mangrupikeun sadayana urang. Ieu méré loba pikeun produktivitas. Ieu ngahasilkeun flop badag dina salep nu.
- Sareng anjeun kedah ngalakukeun NERANGKEUN ANALISIS 6 kali.
- Sareng urang kedah éncér OFFSET 0, sareng trik sapertos +0 pikeun ngabenerkeun persentase sésana tina patarosan masalah urang.
sumber: www.habr.com