PostgreSQL અને JDBC બધો જ્યુસ સ્ક્વિઝ કરે છે. વ્લાદિમીર સિટનીકોવ

હું સૂચન કરું છું કે તમે વ્લાદિમીર સિટનીકોવના પ્રારંભિક 2016ના અહેવાલની ટ્રાંસ્ક્રિપ્ટ વાંચો "PostgreSQL અને JDBC બધો જ રસ કાઢી રહ્યા છે"

શુભ બપોર મારું નામ વ્લાદિમીર સિટનીકોવ છે. હું NetCracker માટે 10 વર્ષથી કામ કરું છું. અને હું મોટે ભાગે ઉત્પાદકતામાં છું. જાવા થી સંબંધિત દરેક વસ્તુ, SQL ને લગતી દરેક વસ્તુ મને ગમે છે.

અને આજે હું વાત કરીશ કે જ્યારે અમે PostgreSQL નો ડેટાબેઝ સર્વર તરીકે ઉપયોગ કરવાનું શરૂ કર્યું ત્યારે કંપનીમાં અમને શું મળ્યું. અને અમે મોટે ભાગે જાવા સાથે કામ કરીએ છીએ. પરંતુ આજે હું તમને જે કહેવા જઈ રહ્યો છું તે માત્ર જાવા વિશે નથી. પ્રેક્ટિસ બતાવે છે તેમ, આ અન્ય ભાષાઓમાં પણ થાય છે.

આપણે વાત કરીશુ:

• ડેટા સેમ્પલિંગ વિશે.
• ડેટા બચાવવા વિશે.
• અને કામગીરી વિશે પણ.
• અને પાણીની અંદરના રેક્સ વિશે જે ત્યાં દફનાવવામાં આવ્યા છે.

ચાલો એક સરળ પ્રશ્નથી શરૂઆત કરીએ. અમે પ્રાથમિક કીના આધારે કોષ્ટકમાંથી એક પંક્તિ પસંદ કરીએ છીએ.

ડેટાબેઝ એ જ હોસ્ટ પર સ્થિત છે. અને આ બધી ખેતી 20 મિલીસેકન્ડ લે છે.

આ 20 મિલીસેકન્ડ ઘણો છે. જો તમારી પાસે આવી 100 વિનંતીઓ છે, તો તમે આ વિનંતીઓ દ્વારા સ્ક્રોલ કરવામાં પ્રતિ સેકન્ડ સમય પસાર કરો છો, એટલે કે અમે સમયનો બગાડ કરી રહ્યા છીએ.

અમને આ કરવાનું પસંદ નથી અને આધાર અમને આ માટે શું ઑફર કરે છે તે જોવું. ડેટાબેઝ અમને પ્રશ્નો ચલાવવા માટે બે વિકલ્પો પ્રદાન કરે છે.

પ્રથમ વિકલ્પ એ એક સરળ વિનંતી છે. તે વિશે શું સારું છે? હકીકત એ છે કે અમે તેને લઈએ છીએ અને તેને મોકલીએ છીએ, અને વધુ કંઈ નથી.

https://github.com/pgjdbc/pgjdbc/pull/478

ડેટાબેઝમાં અદ્યતન ક્વેરી પણ છે, જે વધુ મુશ્કેલ છે, પરંતુ વધુ કાર્યાત્મક છે. તમે પાર્સિંગ, એક્ઝેક્યુશન, વેરીએબલ બાઈન્ડિંગ વગેરે માટે અલગથી વિનંતી મોકલી શકો છો.

સુપર વિસ્તૃત ક્વેરી એવી વસ્તુ છે જેને અમે વર્તમાન રિપોર્ટમાં આવરીશું નહીં. આપણે, કદાચ, ડેટાબેઝમાંથી કંઈક જોઈએ છે અને ત્યાં એક વિશ લિસ્ટ છે જે કોઈને કોઈ સ્વરૂપમાં બનાવવામાં આવ્યું છે, એટલે કે આ તે છે જે આપણે જોઈએ છે, પરંતુ તે હવે અને આગામી વર્ષમાં અશક્ય છે. તેથી અમે હમણાં જ તેને રેકોર્ડ કર્યું છે અને અમે મુખ્ય લોકોને હલાવીને આસપાસ જઈશું.

અને આપણે શું કરી શકીએ છીએ તે સરળ ક્વેરી અને વિસ્તૃત ક્વેરી છે.

દરેક અભિગમમાં વિશેષ શું છે?

એક સરળ ક્વેરી એક વખતના અમલ માટે સારી છે. એકવાર થઈ ગયું અને ભૂલી ગયા. અને સમસ્યા એ છે કે તે બાઈનરી ડેટા ફોર્મેટને સપોર્ટ કરતું નથી, એટલે કે તે કેટલીક ઉચ્ચ-પ્રદર્શન સિસ્ટમ્સ માટે યોગ્ય નથી.

વિસ્તૃત ક્વેરી - તમને પાર્સિંગ પર સમય બચાવવા માટે પરવાનગી આપે છે. આ અમે કર્યું અને ઉપયોગ કરવાનું શરૂ કર્યું. આ ખરેખર, ખરેખર અમને મદદ કરી. પાર્સિંગ પર માત્ર બચત નથી. ડેટા ટ્રાન્સફર પર બચત છે. બાઈનરી ફોર્મેટમાં ડેટા ટ્રાન્સફર કરવાનું વધુ કાર્યક્ષમ છે.

ચાલો પ્રેક્ટિસ તરફ આગળ વધીએ. આ એક લાક્ષણિક એપ્લિકેશન જેવો દેખાય છે. તે જાવા વગેરે હોઈ શકે છે.

અમે નિવેદન બનાવ્યું. આદેશનો અમલ કર્યો. નજીક બનાવ્યું. અહીં ભૂલ ક્યાં છે? શું સમસ્યા છે? કોઇ વાંધો નહી. આ બધા પુસ્તકોમાં તે કહે છે. આ રીતે લખવું જોઈએ. જો તમે મહત્તમ પ્રદર્શન કરવા માંગો છો, તો આ રીતે લખો.

પરંતુ પ્રેક્ટિસ દર્શાવે છે કે આ કામ કરતું નથી. શા માટે? કારણ કે અમારી પાસે "બંધ" પદ્ધતિ છે. અને જ્યારે આપણે આ કરીએ છીએ, ત્યારે ડેટાબેઝના દૃષ્ટિકોણથી તે તારણ આપે છે કે તે ડેટાબેઝ સાથે કામ કરતા ધૂમ્રપાન જેવું છે. અમે કહ્યું "પાર્સ એક્ઝિક્યુટ ડિલલોકેટ".

શા માટે આ બધી વધારાની રચના અને નિવેદનો અનલોડિંગ? કોઈને તેમની જરૂર નથી. પરંતુ સામાન્ય રીતે PreparedStatements માં જે થાય છે તે એ છે કે જ્યારે આપણે તેને બંધ કરીએ છીએ, ત્યારે તેઓ ડેટાબેઝ પરની દરેક વસ્તુ બંધ કરીએ છીએ. આ આપણે ઇચ્છતા નથી.

અમે તંદુરસ્ત લોકોની જેમ, આધાર સાથે કામ કરવા માંગીએ છીએ. અમે અમારું નિવેદન એકવાર લીધું અને તૈયાર કર્યું, પછી અમે તેને ઘણી વખત ચલાવીએ છીએ. વાસ્તવમાં, ઘણી વખત - આ એપ્લીકેશનના સમગ્ર જીવનમાં એક જ વાર છે - તેનું વિશ્લેષણ કરવામાં આવ્યું છે. અને અમે વિવિધ RESTs પર સમાન સ્ટેટમેન્ટ આઈડીનો ઉપયોગ કરીએ છીએ. આ અમારું લક્ષ્ય છે.

આપણે આ કેવી રીતે હાંસલ કરી શકીએ?

તે ખૂબ જ સરળ છે - નિવેદનો બંધ કરવાની જરૂર નથી. અમે તેને આ રીતે લખીએ છીએ: "તૈયાર કરો" "એક્ઝિક્યુટ કરો".

જો આપણે આના જેવું કંઈક લોન્ચ કરીએ છીએ, તો તે સ્પષ્ટ છે કે કંઈક ક્યાંક ઓવરફ્લો થશે. જો તે સ્પષ્ટ નથી, તો તમે તેને અજમાવી શકો છો. ચાલો એક બેન્ચમાર્ક લખીએ જે આ સરળ પદ્ધતિનો ઉપયોગ કરે છે. નિવેદન બનાવો. અમે તેને ડ્રાઇવરના અમુક વર્ઝન પર લૉન્ચ કરીએ છીએ અને શોધી કાઢીએ છીએ કે તે તેની પાસે રહેલી બધી મેમરી ગુમાવવા સાથે ખૂબ જ ઝડપથી ક્રેશ થાય છે.

તે સ્પષ્ટ છે કે આવી ભૂલો સરળતાથી સુધારી શકાય છે. હું તેમના વિશે વાત નહીં કરું. પરંતુ હું કહીશ કે નવું સંસ્કરણ ખૂબ ઝડપથી કામ કરે છે. પદ્ધતિ મૂર્ખ છે, પરંતુ હજુ પણ.

કેવી રીતે યોગ્ય રીતે કામ કરવું? આ માટે આપણે શું કરવાની જરૂર છે?

વાસ્તવમાં, એપ્લિકેશન હંમેશા નિવેદનો બંધ કરે છે. બધા પુસ્તકોમાં તેઓ કહે છે કે તેને બંધ કરો, નહીં તો મેમરી લીક થઈ જશે.

અને PostgreSQL ક્વેરી કેવી રીતે કેશ કરવી તે જાણતું નથી. તે જરૂરી છે કે દરેક સત્ર પોતાના માટે આ કેશ બનાવે.

અને અમે પાર્સિંગ પર પણ સમય બગાડવા માંગતા નથી.

અને હંમેશની જેમ અમારી પાસે બે વિકલ્પો છે.

પહેલો વિકલ્પ એ છે કે આપણે તેને લઈએ અને કહીએ કે ચાલો બધું PgSQL માં લપેટીએ. ત્યાં એક કળશ છે. તે બધું જ કેશ કરે છે. તે મહાન બહાર ચાલુ કરશે. અમે આ જોયું. અમારી પાસે 100500 વિનંતીઓ છે. કામ કરતું નથી. અમે વિનંતીઓને મેન્યુઅલી પ્રક્રિયાઓમાં ફેરવવા માટે સંમત થતા નથી. ના ના.

અમારી પાસે બીજો વિકલ્પ છે - તેને લો અને તેને જાતે કાપી નાખો. અમે સ્ત્રોતો ખોલીએ છીએ અને કાપવાનું શરૂ કરીએ છીએ. અમે જોયું અને જોયું. તે બહાર આવ્યું છે કે તે કરવું એટલું મુશ્કેલ નથી.

https://github.com/pgjdbc/pgjdbc/pull/319

આ ઓગસ્ટ 2015 માં દેખાયું હતું. હવે વધુ આધુનિક સંસ્કરણ છે. અને બધું મહાન છે. તે એટલું સારું કામ કરે છે કે અમે એપ્લિકેશનમાં કંઈપણ બદલતા નથી. અને અમે PgSQL ની દિશામાં વિચારવાનું પણ બંધ કરી દીધું છે, એટલે કે આ અમારા માટે તમામ ઓવરહેડ ખર્ચને લગભગ શૂન્ય સુધી ઘટાડવા માટે પૂરતું હતું.

તદનુસાર, દરેક એક વખતની વિનંતી પર ડેટાબેઝમાં મેમરીનો બગાડ ટાળવા માટે સર્વર-તૈયાર નિવેદનો 5મી એક્ઝિક્યુશન પર સક્રિય થાય છે.

તમે પૂછી શકો છો - નંબરો ક્યાં છે? તમે શું મેળવી રહ્યા છો? અને અહીં હું નંબરો આપીશ નહીં, કારણ કે દરેક વિનંતીની પોતાની હોય છે.

અમારી ક્વેરીઝ એવી હતી કે અમે OLTP ક્વેરીઝ પર પાર્સિંગ કરવા માટે લગભગ 20 મિલિસેકન્ડનો ખર્ચ કર્યો. એક્ઝેક્યુશન માટે 0,5 મિલિસેકન્ડ્સ, પાર્સિંગ માટે 20 મિલિસેકન્ડ્સ હતા. વિનંતી – 10 KiB ટેક્સ્ટ, 170 લાઇનની યોજના. આ એક OLTP વિનંતી છે. તે 1, 5, 10 લાઇનની વિનંતી કરે છે, ક્યારેક વધુ.

પરંતુ અમે 20 મિલીસેકંડ બગાડવા માંગતા ન હતા. અમે તેને ઘટાડીને 0 કર્યો. બધું જ સરસ છે.

તમે અહીંથી શું લઈ જઈ શકો? જો તમારી પાસે જાવા છે, તો પછી તમે ડ્રાઇવરનું આધુનિક સંસ્કરણ લો અને આનંદ કરો.

જો તમે કોઈ અલગ ભાષા બોલો છો, તો પછી વિચારો - કદાચ તમને પણ આની જરૂર છે? કારણ કે અંતિમ ભાષાના દૃષ્ટિકોણથી, ઉદાહરણ તરીકે, જો PL 8 અથવા તમારી પાસે LibPQ છે, તો તે તમારા માટે સ્પષ્ટ નથી કે તમે અમલમાં નહીં, પદચ્છેદન પર સમય પસાર કરી રહ્યાં છો, અને આ તપાસવા યોગ્ય છે. કેવી રીતે? બધું મફત છે.

સિવાય કે તેમાં ભૂલો અને કેટલીક ખાસિયતો છે. અને અમે હમણાં તેમના વિશે વાત કરીશું. તેમાંથી મોટા ભાગના ઔદ્યોગિક પુરાતત્વ વિશે હશે, અમને શું મળ્યું છે, અમે શું જોયું છે.

જો વિનંતી ગતિશીલ રીતે જનરેટ થાય છે. તે થાય છે. કોઈ વ્યક્તિ તારોને એકસાથે ગુંદર કરે છે, પરિણામે SQL ક્વેરી થાય છે.

તે શા માટે ખરાબ છે? તે ખરાબ છે કારણ કે દરેક વખતે આપણે એક અલગ શબ્દમાળા સાથે અંત કરીએ છીએ.

અને આ અલગ-અલગ સ્ટ્રિંગના હેશકોડને ફરીથી વાંચવાની જરૂર છે. આ ખરેખર એક CPU કાર્ય છે - હાલની હેશમાં પણ લાંબી વિનંતી લખાણ શોધવાનું એટલું સરળ નથી. તેથી, નિષ્કર્ષ સરળ છે - વિનંતીઓ જનરેટ કરશો નહીં. તેમને એક ચલમાં સંગ્રહિત કરો. અને આનંદ કરો.

આગામી સમસ્યા. ડેટા પ્રકારો મહત્વપૂર્ણ છે. એવા ORMs છે જે કહે છે કે કયા પ્રકારનું NULL છે તેનાથી કોઈ ફરક પડતો નથી, કોઈ પ્રકારનો રહેવા દો. જો Int, તો અમે setInt કહીએ છીએ. અને જો NULL, તો તેને હંમેશા VARCHAR રહેવા દો. અને અંતે NULL શું છે તેનાથી શું ફરક પડે છે? ડેટાબેઝ પોતે જ બધું સમજી જશે. અને આ ચિત્ર કામ કરતું નથી.

વ્યવહારમાં, ડેટાબેઝને બિલકુલ પરવા નથી. જો તમે પહેલી વાર કહ્યું કે આ નંબર છે, અને બીજી વાર તમે કહ્યું કે તે VARCHAR છે, તો સર્વર-તૈયાર સ્ટેટમેન્ટનો ફરીથી ઉપયોગ કરવો અશક્ય છે. અને આ કિસ્સામાં, આપણે અમારું નિવેદન ફરીથી બનાવવું પડશે.

જો તમે સમાન ક્વેરી ચલાવી રહ્યાં છો, તો ખાતરી કરો કે તમારી કૉલમમાંના ડેટા પ્રકારો મૂંઝવણમાં નથી. તમારે NULL માટે ધ્યાન રાખવાની જરૂર છે. અમે PreparedStatements નો ઉપયોગ કરવાનું શરૂ કર્યા પછી આ એક સામાન્ય ભૂલ છે

ઓકે, ચાલુ કર્યું. કદાચ તેઓ ડ્રાઈવરને લઈ ગયા. અને ઉત્પાદકતા ઘટી. વસ્તુઓ ખરાબ થઈ ગઈ.

આ કેવી રીતે થાય છે? શું આ બગ છે કે ફીચર? કમનસીબે, તે સમજવું શક્ય નહોતું કે આ બગ છે કે ફીચર. પરંતુ આ સમસ્યાને પુનઃઉત્પાદિત કરવા માટે એક ખૂબ જ સરળ દૃશ્ય છે. તેણીએ સંપૂર્ણપણે અણધારી રીતે અમારા પર હુમલો કર્યો. અને તેમાં શાબ્દિક રીતે એક ટેબલમાંથી નમૂના લેવાનો સમાવેશ થાય છે. અમારી પાસે, અલબત્ત, આવી વધુ વિનંતીઓ હતી. એક નિયમ તરીકે, તેમાં બે અથવા ત્રણ કોષ્ટકો શામેલ છે, પરંતુ આવા પ્લેબેક દૃશ્ય છે. તમારા ડેટાબેઝમાંથી કોઈપણ સંસ્કરણ લો અને તેને ચલાવો.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

મુદ્દો એ છે કે અમારી પાસે બે કૉલમ છે, જેમાંથી દરેક અનુક્રમિત છે. એક NULL કૉલમમાં દસ લાખ પંક્તિઓ છે. અને બીજી કોલમમાં માત્ર 20 લીટીઓ છે. જ્યારે આપણે બાઉન્ડ વેરીએબલ વગર એક્ઝીક્યુટ કરીએ છીએ, ત્યારે બધું જ સારી રીતે કામ કરે છે.

જો આપણે બાઉન્ડ વેરીએબલ સાથે એક્ઝિક્યુટ કરવાનું શરૂ કરીએ, એટલે કે આપણે "?" અથવા અમારી વિનંતિ માટે "$1", અમે શું મેળવીશું?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

પ્રથમ અમલ અપેક્ષા મુજબ છે. બીજો થોડો ઝડપી છે. કંઈક કેશ કરવામાં આવ્યું હતું. ત્રીજો, ચોથો, પાંચમો. પછી બેંગ - અને તે કંઈક. અને સૌથી ખરાબ બાબત એ છે કે આ છઠ્ઠા ફાંસી પર થાય છે. કોણ જાણતું હતું કે અમલની વાસ્તવિક યોજના શું છે તે સમજવા માટે બરાબર છ ફાંસી કરવી જરૂરી છે?

દોષિત કોણ? શું થયું? ડેટાબેઝ ઓપ્ટિમાઇઝેશન સમાવે છે. અને તે સામાન્ય કેસ માટે ઑપ્ટિમાઇઝ થયેલું જણાય છે. અને, તે મુજબ, અમુક સમયે શરૂ કરીને, તેણી એક સામાન્ય યોજના પર સ્વિચ કરે છે, જે, કમનસીબે, અલગ હોઈ શકે છે. તે સમાન હોઈ શકે છે, અથવા તે અલગ હોઈ શકે છે. અને ત્યાં અમુક પ્રકારનું થ્રેશોલ્ડ મૂલ્ય છે જે આ વર્તન તરફ દોરી જાય છે.

તમે તેના વિશે શું કરી શકો? અહીં, અલબત્ત, કંઈપણ ધારવું વધુ મુશ્કેલ છે. એક સરળ ઉપાય છે જેનો આપણે ઉપયોગ કરીએ છીએ. આ +0 છે, ઑફસેટ 0. ચોક્કસ તમે આવા ઉકેલો જાણો છો. અમે ફક્ત તેને લઈએ છીએ અને વિનંતીમાં "+0" ઉમેરીએ છીએ અને બધું બરાબર છે. હું તમને પછી બતાવીશ.

અને બીજો વિકલ્પ છે - યોજનાઓને વધુ કાળજીપૂર્વક જુઓ. વિકાસકર્તાએ માત્ર વિનંતી લખવી જ જોઈએ નહીં, પરંતુ 6 વખત "એક્પ્લેન વિશ્લેષણ" પણ કહેવું જોઈએ. જો તે 5 છે, તો તે કામ કરશે નહીં.

અને ત્રીજો વિકલ્પ છે - pgsql-hackers ને પત્ર લખો. મેં લખ્યું, જો કે, તે હજી સ્પષ્ટ નથી કે આ બગ છે કે ફીચર.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

જ્યારે આપણે વિચારી રહ્યા છીએ કે આ બગ છે કે ફીચર, ચાલો તેને ઠીક કરીએ. ચાલો અમારી વિનંતી લઈએ અને "+0" ઉમેરીએ. બધું બરાબર છે. બે પ્રતીકો અને તમારે તે કેવી રીતે છે અથવા તે શું છે તે વિશે વિચારવાની પણ જરૂર નથી. ખૂબ જ સરળ. અમે ફક્ત ડેટાબેઝને આ કૉલમ પર અનુક્રમણિકાનો ઉપયોગ કરવા માટે પ્રતિબંધિત કર્યો છે. અમારી પાસે “+0” કૉલમ પર ઇન્ડેક્સ નથી અને બસ, ડેટાબેઝ ઇન્ડેક્સનો ઉપયોગ કરતું નથી, બધું બરાબર છે.

આ 6 નો નિયમ છે સમજાવો. જો તમારી પાસે બાઉન્ડ વેરિયેબલ હોય તો હવે વર્તમાન સંસ્કરણોમાં તમારે તેને 6 વખત કરવું પડશે. જો તમારી પાસે બાઉન્ડ ચલો નથી, તો આ અમે કરીએ છીએ. અને અંતે તે ચોક્કસપણે આ વિનંતી છે જે નિષ્ફળ જાય છે. તે કોઈ મુશ્કેલ બાબત નથી.

એવું લાગે છે, કેટલું શક્ય છે? અહીં એક ભૂલ, ત્યાં એક ભૂલ. વાસ્તવમાં, બગ દરેક જગ્યાએ છે.

ચાલો નજીકથી નજર કરીએ. ઉદાહરણ તરીકે, અમારી પાસે બે સ્કીમા છે. કોષ્ટક S સાથે યોજના A અને કોષ્ટક S સાથે રેખાકૃતિ B. ક્વેરી - કોષ્ટકમાંથી ડેટા પસંદ કરો. આ કિસ્સામાં આપણી પાસે શું હશે? અમારી પાસે ભૂલ હશે. અમારી પાસે ઉપરોક્ત તમામ હશે. નિયમ છે - બગ દરેક જગ્યાએ છે, આપણી પાસે ઉપરોક્ત તમામ હશે.

હવે પ્રશ્ન એ છે: "શા માટે?" એવું લાગે છે કે ત્યાં દસ્તાવેજીકરણ છે કે જો અમારી પાસે સ્કીમા હોય, તો ત્યાં એક "સર્ચ_પાથ" ચલ છે જે અમને કહે છે કે ટેબલ ક્યાં શોધવું. એવું લાગે છે કે ત્યાં એક ચલ છે.

શું સમસ્યા છે? સમસ્યા એ છે કે સર્વર-તૈયાર નિવેદનો શંકા નથી કરતા કે શોધ_પથ કોઈ વ્યક્તિ દ્વારા બદલી શકાય છે. આ મૂલ્ય ડેટાબેઝ માટે સ્થિર રહે છે. અને કેટલાક ભાગો નવા અર્થ પસંદ કરી શકતા નથી.

અલબત્ત, આ તમે જે સંસ્કરણનું પરીક્ષણ કરી રહ્યાં છો તેના પર આધાર રાખે છે. તમારી કોષ્ટકો કેટલી ગંભીરતાથી અલગ છે તેના પર આધાર રાખે છે. અને સંસ્કરણ 9.1 ફક્ત જૂની ક્વેરીઝને એક્ઝિક્યુટ કરશે. નવી આવૃત્તિઓ બગને પકડી શકે છે અને તમને કહી શકે છે કે તમારી પાસે બગ છે.

શોધ_પથ + સર્વર-તૈયાર નિવેદનો = સેટ કરો
કેશ્ડ પ્લાન પરિણામ પ્રકાર બદલવો જોઈએ નહીં

તેની સારવાર કેવી રીતે કરવી? ત્યાં એક સરળ રેસીપી છે - તે કરશો નહીં. જ્યારે એપ્લિકેશન ચાલી રહી હોય ત્યારે search_path બદલવાની જરૂર નથી. જો તમે બદલો છો, તો નવું કનેક્શન બનાવવું વધુ સારું છે.

તમે ચર્ચા કરી શકો છો, એટલે કે ખોલો, ચર્ચા કરો, ઉમેરો. કદાચ અમે ડેટાબેઝ ડેવલપર્સને ખાતરી આપી શકીએ કે જ્યારે કોઈ વ્યક્તિ મૂલ્યમાં ફેરફાર કરે છે, ત્યારે ડેટાબેસે ક્લાયન્ટને આ વિશે જણાવવું જોઈએ: “જુઓ, તમારું મૂલ્ય અહીં અપડેટ કરવામાં આવ્યું છે. કદાચ તમારે નિવેદનોને ફરીથી સેટ કરવાની અને તેને ફરીથી બનાવવાની જરૂર છે?" હવે ડેટાબેઝ ગુપ્ત રીતે વર્તે છે અને કોઈપણ રીતે જાણ કરતું નથી કે નિવેદનો અંદર ક્યાંક બદલાઈ ગયા છે.

અને હું ફરીથી ભાર આપીશ - આ એવી વસ્તુ છે જે જાવા માટે લાક્ષણિક નથી. આપણે PL/pgSQL માં એક થી એક સમાન વસ્તુ જોઈશું. પરંતુ તે ત્યાં પુનઃઉત્પાદન કરવામાં આવશે.

ચાલો કેટલાક વધુ ડેટા પસંદગીનો પ્રયાસ કરીએ. અમે પસંદ કરીએ છીએ અને પસંદ કરીએ છીએ. અમારી પાસે એક મિલિયન પંક્તિઓ સાથેનું ટેબલ છે. દરેક લાઇન એક કિલોબાઇટ છે. આશરે એક ગીગાબાઈટ ડેટા. અને અમારી પાસે જાવા મશીનમાં 128 મેગાબાઈટની વર્કિંગ મેમરી છે.

અમે, તમામ પુસ્તકોમાં ભલામણ કર્યા મુજબ, સ્ટ્રીમ પ્રોસેસિંગનો ઉપયોગ કરીએ છીએ. એટલે કે, આપણે રિઝલ્ટસેટ ખોલીએ છીએ અને ત્યાંથી ધીમે ધીમે ડેટા વાંચીએ છીએ. તે કામ કરશે? શું તે સ્મૃતિમાંથી પડી જશે? થોડું વાંચશો? ચાલો ડેટાબેઝમાં વિશ્વાસ કરીએ, ચાલો પોસ્ટગ્રેસમાં વિશ્વાસ કરીએ. અમે તેને માનતા નથી. શું આપણે આઉટઓફમેમરી પડીશું? કોણે OutOfMemory નો અનુભવ કર્યો? તે પછી તેને ઠીક કરવામાં કોણ વ્યવસ્થાપિત થયું? કોઈએ તેને ઠીક કરવામાં વ્યવસ્થાપિત કર્યું.

જો તમારી પાસે એક મિલિયન પંક્તિઓ છે, તો તમે ફક્ત પસંદ અને પસંદ કરી શકતા નથી. OFFSET/LIMIT જરૂરી છે. આ વિકલ્પ માટે કોણ છે? અને ઓટોકમિટ સાથે રમવાની તરફેણમાં કોણ છે?

અહીં, હંમેશની જેમ, સૌથી અણધારી વિકલ્પ સાચો નીકળે છે. અને જો તમે અચાનક ઓટોકમિટ બંધ કરો છો, તો તે મદદ કરશે. તે શા માટે છે? વિજ્ઞાન આ વિશે જાણતું નથી.

પરંતુ ડિફૉલ્ટ રૂપે, પોસ્ટગ્રેસ ડેટાબેઝ સાથે કનેક્ટ થતા તમામ ક્લાયંટ સમગ્ર ડેટા મેળવે છે. PgJDBC આ બાબતમાં અપવાદ નથી; તે બધી પંક્તિઓ પસંદ કરે છે.

FetchSize થીમ પર ભિન્નતા છે, એટલે કે તમે એક અલગ નિવેદનના સ્તરે કહી શકો છો કે અહીં, કૃપા કરીને 10, 50 સુધીમાં ડેટા પસંદ કરો. પરંતુ જ્યાં સુધી તમે સ્વતઃ કમિટીને બંધ ન કરો ત્યાં સુધી આ કામ કરતું નથી. ઓટોકમિટ બંધ કર્યું - તે કામ કરવાનું શરૂ કરે છે.

પરંતુ કોડમાંથી પસાર થવું અને દરેક જગ્યાએ setFetchSize સેટ કરવું અસુવિધાજનક છે. તેથી, અમે એક સેટિંગ બનાવી છે જે સમગ્ર કનેક્શન માટે ડિફોલ્ટ મૂલ્ય કહેશે.

તે અમે કહ્યું છે. પરિમાણ ગોઠવેલ છે. અને અમને શું મળ્યું? જો આપણે નાની રકમ પસંદ કરીએ, જો, ઉદાહરણ તરીકે, આપણે એક સમયે 10 પંક્તિઓ પસંદ કરીએ, તો આપણી પાસે ઓવરહેડ ખર્ચ ઘણો મોટો છે. તેથી, આ મૂલ્ય લગભગ સો પર સેટ કરવું જોઈએ.

આદર્શ રીતે, અલબત્ત, તમારે તેને બાઈટમાં કેવી રીતે મર્યાદિત કરવું તે શીખવું પડશે, પરંતુ રેસીપી આ છે: defaultRowFetchSize સો કરતાં વધુ પર સેટ કરો અને ખુશ રહો.

ચાલો ડેટા દાખલ કરવા પર આગળ વધીએ. નિવેશ સરળ છે, ત્યાં વિવિધ વિકલ્પો છે. ઉદાહરણ તરીકે, INSERT, VALUES. આ એક સારો વિકલ્પ છે. તમે "ઇનસર્ટ સિલેક્ટ" કહી શકો છો. વ્યવહારમાં તે જ વસ્તુ છે. કામગીરીમાં કોઈ તફાવત નથી.

પુસ્તકો કહે છે કે તમારે બેચ સ્ટેટમેન્ટ ચલાવવાની જરૂર છે, પુસ્તકો કહે છે કે તમે ઘણા કૌંસ સાથે વધુ જટિલ આદેશો ચલાવી શકો છો. અને પોસ્ટગ્રેસમાં એક અદ્ભુત સુવિધા છે - તમે કોપી કરી શકો છો, એટલે કે તે ઝડપથી કરી શકો છો.

જો તમે તેને માપો છો, તો તમે ફરીથી કેટલીક રસપ્રદ શોધ કરી શકો છો. અમે આ કેવી રીતે કામ કરવા માંગીએ છીએ? અમે બિનજરૂરી આદેશોને પાર્સ કરવા અને એક્ઝિક્યુટ ન કરવા માંગીએ છીએ.

વ્યવહારમાં, TCP અમને આ કરવાની મંજૂરી આપતું નથી. જો ક્લાયંટ વિનંતી મોકલવામાં વ્યસ્ત છે, તો ડેટાબેઝ અમને જવાબો મોકલવાના પ્રયાસોમાં વિનંતીઓ વાંચતું નથી. અંતિમ પરિણામ એ છે કે ક્લાયંટ વિનંતી વાંચવા માટે ડેટાબેઝની રાહ જુએ છે, અને ડેટાબેઝ ક્લાયંટ પ્રતિભાવ વાંચવા માટે રાહ જુએ છે.

અને તેથી ક્લાયંટને સમયાંતરે સિંક્રનાઇઝેશન પેકેટ મોકલવાની ફરજ પાડવામાં આવે છે. વધારાની નેટવર્ક ક્રિયાપ્રતિક્રિયાઓ, સમયનો વધારાનો બગાડ.

અને આપણે તેને જેટલું ઉમેરીએ છીએ, તેટલું ખરાબ થાય છે. ડ્રાઈવર એકદમ નિરાશાવાદી છે અને લાઈનોના કદ વગેરેને આધારે દર 200 લાઈનમાં લગભગ એક વાર તેમને ઉમેરે છે.

https://github.com/pgjdbc/pgjdbc/pull/380

એવું બને છે કે તમે માત્ર એક લીટીને સુધારી લો અને બધું 10 ગણી ઝડપે વધશે. તે થાય છે. શા માટે? હંમેશની જેમ, આના જેવો સતત ઉપયોગ ક્યાંક પહેલેથી જ કરવામાં આવ્યો છે. અને મૂલ્ય "128" નો અર્થ બેચિંગનો ઉપયોગ ન કરવાનો હતો.

જાવા માઇક્રોબેન્ચમાર્ક હાર્નેસ

તે સારું છે કે આ સત્તાવાર સંસ્કરણમાં શામેલ નથી. પ્રકાશન શરૂ થાય તે પહેલાં શોધાયેલ. હું જે અર્થ આપું છું તે બધા આધુનિક સંસ્કરણો પર આધારિત છે.

ચાલો તેને અજમાવીએ. અમે InsertBatch સરળ માપીએ છીએ. અમે InsertBatch ઘણી વખત માપીએ છીએ, એટલે કે એક જ વસ્તુ, પરંતુ ત્યાં ઘણી કિંમતો છે. કપટી ચાલ. દરેક જણ આ કરી શકતું નથી, પરંતુ આ એક સરળ ચાલ છે, જે COPY કરતાં ઘણી સરળ છે.

તમે COPY કરી શકો છો.

અને તમે આ રચનાઓ પર કરી શકો છો. વપરાશકર્તા ડિફોલ્ટ પ્રકાર જાહેર કરો, એરે પાસ કરો અને સીધા ટેબલ પર દાખલ કરો.

જો તમે લિંક ખોલો છો: pgjdbc/ubenchmsrk/InsertBatch.java, તો આ કોડ GitHub પર છે. તમે ખાસ જોઈ શકો છો કે ત્યાં કઈ વિનંતીઓ જનરેટ થાય છે. કોઈ વાંધો નથી.

અમે લોન્ચ કર્યું. અને અમને પ્રથમ વસ્તુ એ સમજાયું કે બેચનો ઉપયોગ ન કરવો એ ફક્ત અશક્ય છે. બધા બેચિંગ વિકલ્પો શૂન્ય છે, એટલે કે એક વખતના અમલની સરખામણીમાં એક્ઝેક્યુશનનો સમય વ્યવહારીક રીતે શૂન્ય છે.

અમે ડેટા દાખલ કરીએ છીએ. તે ખૂબ જ સરળ ટેબલ છે. ત્રણ કૉલમ. અને આપણે અહીં શું જોઈએ છીએ? આપણે જોઈએ છીએ કે આ ત્રણેય વિકલ્પો લગભગ તુલનાત્મક છે. અને કોપી, અલબત્ત, વધુ સારી છે.

આ તે છે જ્યારે આપણે ટુકડાઓ દાખલ કરીએ છીએ. જ્યારે અમે કહ્યું કે એક VALUES મૂલ્ય, બે VALUES મૂલ્યો, ત્રણ VALUES મૂલ્યો, અથવા અમે તેમાંથી 10 ને અલ્પવિરામ વડે અલગ કર્યા છે. આ હવે માત્ર આડું છે. 1, 2, 4, 128. તે જોઈ શકાય છે કે બેચ ઇન્સર્ટ, જે વાદળી રંગમાં દોરવામાં આવે છે, તેને ઘણું સારું લાગે છે. એટલે કે, જ્યારે તમે એક સમયે એક દાખલ કરો છો અથવા જ્યારે તમે એક સમયે ચાર દાખલ કરો છો, ત્યારે તે બમણું સારું બની જાય છે, ફક્ત એટલા માટે કે અમે VALUES માં થોડું વધારે ખેંચ્યું છે. ઓછા EXECUTE ઓપરેશન્સ.

નાના વોલ્યુમો પર COPY નો ઉપયોગ કરવો અત્યંત અનિશ્ચિત છે. હું પણ પ્રથમ બે પર દોરવામાં ન હતી. તેઓ સ્વર્ગમાં જાય છે, એટલે કે, COPY માટે આ લીલા નંબરો.

જ્યારે તમારી પાસે ડેટાની ઓછામાં ઓછી સો પંક્તિઓ હોય ત્યારે કૉપીનો ઉપયોગ કરવો જોઈએ. આ કનેક્શન ખોલવાનું ઓવરહેડ મોટું છે. અને, સાચું કહું તો, મેં આ દિશામાં ખોદકામ કર્યું નથી. મેં બેચને ઑપ્ટિમાઇઝ કર્યું, પણ કૉપી નહીં.

આપણે આગળ શું કરીએ? અમે તેના પર પ્રયાસ કર્યો. અમે સમજીએ છીએ કે અમારે ક્યાં તો સ્ટ્રક્ચર્સ અથવા એક ચપળ બેકથનો ઉપયોગ કરવાની જરૂર છે જે ઘણા અર્થોને જોડે છે.

આજના અહેવાલમાંથી તમારે શું દૂર કરવું જોઈએ?

• તૈયાર નિવેદન આપણું બધું છે. આ ઉત્પાદકતા માટે ઘણું આપે છે. તે મલમમાં મોટી ફ્લોપ પેદા કરે છે.
• અને તમારે 6 વખત એક્સપ્લેન એનાલિઝ કરવાની જરૂર છે.
• અને અમારે અમારી સમસ્યારૂપ ક્વેરીઝની બાકીની ટકાવારી સુધારવા માટે OFFSET 0 અને +0 જેવી યુક્તિઓને પાતળી કરવાની જરૂર છે.

સોર્સ: www.habr.com