PostgreSQL እና JDBC ሁሉንም ጭማቂ ያወጡታል። ቭላድሚር ሲትኒኮቭ

በ 2016 መጀመሪያ ላይ የቭላድሚር ሲትኒኮቭን ዘገባ "PostgreSQL እና JDBC ሁሉንም ጭማቂ እየጨመቁ ነው" የሚለውን ግልባጭ እንዲያነቡ ሀሳብ አቀርባለሁ።

እንደምን አረፈድክ ስሜ ቭላድሚር ሲትኒኮቭ ነው። ለ NetCracker ለ 10 ዓመታት እየሠራሁ ነው. እና በአብዛኛው ምርታማነት ላይ ነኝ። ከጃቫ ጋር የሚዛመዱ ሁሉም ነገሮች, ከ SQL ጋር የተያያዙ ሁሉም ነገሮች እኔ የምወደው ነው.

እና ዛሬ PostgreSQL እንደ የውሂብ ጎታ አገልጋይ መጠቀም ስንጀምር በኩባንያው ውስጥ ስላጋጠመን ነገር እናገራለሁ. እና በአብዛኛው የምንሰራው ከጃቫ ጋር ነው። ዛሬ ግን የምነግርህ ስለ ጃቫ ብቻ አይደለም። እንደ ልምምድ እንደሚያሳየው, ይህ በሌሎች ቋንቋዎችም ይከሰታል.

እንነጋገራለን፡-

• ስለ የውሂብ ናሙና.
• ውሂብ ስለማስቀመጥ።
• እና ስለ አፈፃፀምም እንዲሁ።
• እና እዚያ ስለተቀበሩ የውሃ ውስጥ መሰንጠቂያዎች።

በቀላል ጥያቄ እንጀምር። በዋናው ቁልፍ መሰረት አንድ ረድፍ ከጠረጴዛው ውስጥ እንመርጣለን.

የመረጃ ቋቱ በተመሳሳይ አስተናጋጅ ላይ ይገኛል። እና ይሄ ሁሉ እርሻ 20 ሚሊሰከንዶች ይወስዳል.

እነዚህ 20 ሚሊሰከንዶች ብዙ ናቸው። 100 እንደዚህ ያሉ ጥያቄዎች ካሉዎት፣ እነዚህን ጥያቄዎች በማሸብለል በሰከንድ ጊዜ ያሳልፋሉ፣ ማለትም ጊዜ እያባከንን ነው።

ይህንን ማድረግ አንወድም እና መሰረቱ ለዚህ ምን እንደሚሰጠን ይመልከቱ። ዳታቤዙ ጥያቄዎችን ለማስፈጸም ሁለት አማራጮችን ይሰጠናል።

የመጀመሪያው አማራጭ ቀላል ጥያቄ ነው. ምን ጥሩ ነገር አለው? እኛ ወስደን እንልካለን, እና ምንም ተጨማሪ ነገር የለም.

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

የመረጃ ቋቱ የላቀ መጠይቅ አለው፣ እሱም የበለጠ ተንኮለኛ፣ ግን የበለጠ የሚሰራ። የመተንተን፣ የማስፈጸሚያ፣ ተለዋዋጭ ማሰሪያ ወዘተ ጥያቄን በተናጥል መላክ ይችላሉ።

እጅግ የተራዘመ መጠይቅ አሁን ባለው ዘገባ ላይ የማንሸፍነው ጉዳይ ነው። እኛ, ምናልባት, ከመረጃ ቋቱ ውስጥ የሆነ ነገር እንፈልጋለን እና በተወሰነ መልኩ የተፈጠረ የምኞት ዝርዝር አለ, ማለትም ይህ እኛ የምንፈልገው ነው, ግን አሁን እና በሚቀጥለው ዓመት የማይቻል ነው. ስለዚህ ዝም ብለን ቀዳነው እና ዋናዎቹን ሰዎች እያንቀጠቀጡ እንዞራለን።

እና እኛ ማድረግ የምንችለው ቀላል መጠይቅ እና የተራዘመ መጠይቅ ነው።

በእያንዳንዱ አቀራረብ ውስጥ ምን ልዩ ነገር አለ?

ቀላል መጠይቅ ለአንድ ጊዜ ማስፈጸሚያ ጥሩ ነው። አንዴ ከተሰራ እና ከተረሳ. እና ችግሩ የሁለትዮሽ ውሂብ ቅርጸትን አይደግፍም, ማለትም ለአንዳንድ ከፍተኛ አፈፃፀም ስርዓቶች ተስማሚ አይደለም.

የተራዘመ መጠይቅ - በመተንተን ጊዜ እንዲቆጥቡ ያስችልዎታል. እኛ ያደረግነው እና መጠቀም የጀመርነው ይህንን ነው። ይህ በእውነት ረድቶናል። በመተንተን ላይ ቁጠባዎች ብቻ አይደሉም. በውሂብ ማስተላለፍ ላይ ቁጠባዎች አሉ። ውሂብን በሁለትዮሽ ቅርጸት ማስተላለፍ የበለጠ ቀልጣፋ ነው።

ወደ ልምምድ እንሂድ። የተለመደው መተግበሪያ ይህን ይመስላል። ጃቫ ወዘተ ሊሆን ይችላል።

መግለጫ ፈጠርን። ትዕዛዙን ፈፀመ። ቅርብ ተፈጠረ። እዚህ ስህተቱ የት አለ? ችግሩ ምንድን ነው? ችግር የሌም. በሁሉም መጽሐፍት ውስጥ የተናገረው ይህ ነው። እንዲህ ነው መፃፍ ያለበት። ከፍተኛ አፈጻጸም ከፈለጉ, እንደዚህ ይጻፉ.

ነገር ግን ልምምድ እንደሚያሳየው ይህ አይሰራም. ለምን? ምክንያቱም "የተጠጋ" ዘዴ አለን. እና ይህን ስናደርግ ከመረጃ ቋቱ እይታ አንጻር ሲጋራ ከመረጃ ቋት ጋር እንደሚሠራ ሆኖ ይታያል። "PARSE EXECUTE DEALLOCATE" አልን።

ለምን ይሄ ሁሉ ተጨማሪ መግለጫዎችን መፍጠር እና ማውረድ? ማንም አያስፈልጋቸውም። ግን ብዙውን ጊዜ በ PreparedStatements ውስጥ የሚከሰተው እኛ በምንዘጋቸው ጊዜ ሁሉንም ነገር በመረጃ ቋቱ ውስጥ ይዘጋሉ። እኛ የምንፈልገው ይህ አይደለም።

ልክ እንደ ጤናማ ሰዎች, ከመሠረቱ ጋር ለመስራት እንፈልጋለን. መግለጫችንን አንድ ጊዜ ወስደን አዘጋጅተናል, ከዚያም ብዙ ጊዜ እናስፈጽማለን. በእውነቱ, ብዙ ጊዜ - ይህ በጠቅላላው የመተግበሪያዎች ህይወት ውስጥ አንድ ጊዜ ነው - እነሱ ተተነተኑ. እና በተለያዩ RESTs ላይ ተመሳሳይ የመግለጫ መታወቂያ እንጠቀማለን። ግባችን ይህ ነው።

ይህንን እንዴት ማሳካት እንችላለን?

በጣም ቀላል ነው - መግለጫዎችን መዝጋት አያስፈልግም. እኛ እንደሚከተለው እንጽፋለን: "አዘጋጅ" "አስፈጽም".

እንደዚህ አይነት ነገር ከጀመርን, የሆነ ነገር የሆነ ቦታ እንደሚፈስ ግልጽ ነው. ግልጽ ካልሆነ, ሊሞክሩት ይችላሉ. ይህን ቀላል ዘዴ የሚጠቀም ቤንችማርክ እንፃፍ። መግለጫ ይፍጠሩ። በአንዳንድ የሾፌሩ ሥሪት ላይ እናስጀምረዋለን እና እሱ ያለውን ማህደረ ትውስታ በሙሉ በማጣት በፍጥነት ይበላሻል።

እንደነዚህ ያሉ ስህተቶች በቀላሉ እንደሚስተካከሉ ግልጽ ነው. ስለነሱ አላወራም። እኔ ግን እላለሁ አዲሱ ስሪት በጣም በፍጥነት ይሰራል. ዘዴው ሞኝነት ነው, ግን አሁንም.

በትክክል እንዴት መሥራት እንደሚቻል? ለዚህ ምን ማድረግ አለብን?

እንደ እውነቱ ከሆነ, ማመልከቻዎች ሁልጊዜ መግለጫዎችን ይዘጋሉ. በሁሉም መጽሃፎች ውስጥ መዝጋት ይላሉ, አለበለዚያ ትውስታው ይፈስሳል.

እና PostgreSQL እንዴት መጠይቆችን መሸጎጥ እንዳለበት አያውቅም። እያንዳንዱ ክፍለ ጊዜ ይህንን መሸጎጫ ለራሱ እንዲፈጥር አስፈላጊ ነው.

እና በመተንተን ጊዜ ማባከን አንፈልግም።

እና እንደተለመደው ሁለት አማራጮች አሉን.

የመጀመሪያው አማራጭ እንወስዳለን እና ሁሉንም ነገር በ PgSQL እንጠቅልለው እንላለን። እዚያ መሸጎጫ አለ. ሁሉንም ነገር ይይዛል። በጣም ጥሩ ይሆናል. ይህንን አይተናል። 100500 ጥያቄዎች አሉን። አይሰራም. ጥያቄዎችን በእጅ ወደ ሂደት ለመቀየር አልተስማማንም። አይደለም አይደለም.

ሁለተኛ አማራጭ አለን - ይውሰዱት እና እራሳችንን ይቁረጡ. ምንጮቹን እንከፍተዋለን እና መቁረጥ እንጀምራለን. አይተናል አይተናል። ይህን ለማድረግ ያን ያህል አስቸጋሪ እንዳልሆነ ታወቀ።

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

ይህ በነሐሴ 2015 ታየ። አሁን የበለጠ ዘመናዊ ስሪት አለ. እና ሁሉም ነገር በጣም ጥሩ ነው. በመተግበሪያው ውስጥ ምንም ነገር ስለማንለውጥ በጣም ጥሩ ይሰራል። እና በPgSQL አቅጣጫ ማሰብ አቁመናል፣ ማለትም፣ ሁሉንም ወጪዎች ወደ ዜሮ ለማድረስ ይህ በቂ ነበር።

በዚህ መሠረት በእያንዳንዱ የአንድ ጊዜ ጥያቄ በዳታቤዝ ውስጥ ማህደረ ትውስታን ላለማባከን በአገልጋይ የተዘጋጁ መግለጫዎች በ 5 ኛው አፈፃፀም ላይ ይንቀሳቀሳሉ.

ሊጠይቁ ይችላሉ - ቁጥሮቹ የት ናቸው? ምን እያገኘህ ነው? እና እዚህ ቁጥሮችን አልሰጥም, ምክንያቱም እያንዳንዱ ጥያቄ የራሱ አለው.

ጥያቄዎቻችን በOLTP መጠይቆች ላይ ለመተንተን 20 ሚሊሰከንድ ያህል ወጪ አድርገናል። ለአፈፃፀም 0,5 ሚሊሰከንዶች፣ ለመተንተን 20 ሚሊ ሰከንድ ነበር። ጥያቄ - 10 ኪቢ ጽሑፍ, 170 የእቅድ መስመሮች. ይህ የOLTP ጥያቄ ነው። 1, 5, 10 መስመሮችን ይጠይቃል, አንዳንዴም ተጨማሪ.

ግን 20 ሚሊሰከንዶችን በጭራሽ ማባከን አልፈለግንም። ወደ 0 ዝቅ አድርገነዋል። ሁሉም ነገር ጥሩ ነው።

ከዚህ ምን መውሰድ ይችላሉ? ጃቫ ካለዎት የአሽከርካሪውን ዘመናዊ ስሪት ወስደህ ደስ ይበልህ።

የተለየ ቋንቋ የሚናገሩ ከሆነ ያስቡ - ምናልባት እርስዎም ያስፈልገዎታል? ምክንያቱም ከመጨረሻው ቋንቋ አንጻር ለምሳሌ፡ PL 8 ወይም LibPQ ካለህ፡ ለአፈጻጸም ሳይሆን ለመተንተን ጊዜ እንደምታጠፋ ለአንተ ግልጽ አይደለም፡ ይህ ደግሞ መፈተሽ ተገቢ ነው። እንዴት? ሁሉም ነገር ነፃ ነው።

ስህተቶች እና አንዳንድ ልዩነቶች ከመኖራቸው በስተቀር። እና አሁን ስለእነሱ እንነጋገራለን. አብዛኛው ስለ ኢንደስትሪ አርኪኦሎጂ፣ ስላገኘነው፣ ስላጋጠመን ነገር ይሆናል።

ጥያቄው በተለዋዋጭነት ከተፈጠረ። ያጋጥማል. አንድ ሰው ገመዱን አንድ ላይ በማጣበቅ የ SQL ጥያቄን ያስከትላል።

እሱ መጥፎ የሆነው ለምንድን ነው? መጥፎ ነው ምክንያቱም በእያንዳንዱ ጊዜ በተለየ ሕብረቁምፊ ስለምንጨርስ።

እና የዚህ የተለየ ሕብረቁምፊ ሃሽኮድ እንደገና መነበብ አለበት። ይህ በእውነቱ የሲፒዩ ተግባር ነው - ረጅም የጥያቄ ጽሑፍ አሁን ባለው ሃሽ ውስጥ ማግኘት ቀላል አይደለም። ስለዚህ, መደምደሚያው ቀላል ነው - ጥያቄዎችን አያመነጩ. በአንድ ተለዋዋጭ ውስጥ ያስቀምጧቸው. ደስ ይበላችሁ።

ቀጣይ ችግር. የውሂብ ዓይነቶች አስፈላጊ ናቸው. ምንም አይነት NULL ምንም ለውጥ አያመጣም የሚሉ ORMs አሉ፣ አንዳንድ አይነት ይኑር። ኢንት ከሆነ፣ ከዚያም setInt እንላለን። እና NULL ከሆነ፣ ሁሌም VARCHAR ይሁን። እና መጨረሻ ላይ NULL ምን ለውጥ ያመጣል? የውሂብ ጎታው ራሱ ሁሉንም ነገር ይረዳል. እና ይህ ስዕል አይሰራም.

በተግባር፣ የመረጃ ቋቱ ምንም ግድ አይሰጠውም። ይህ ቁጥር ነው ብለው ለመጀመሪያ ጊዜ ከተናገሩ እና ለሁለተኛ ጊዜ VARCHAR እንደሆነ ከተናገሩ በአገልጋይ የተዘጋጁ መግለጫዎችን እንደገና መጠቀም አይቻልም። እናም በዚህ ሁኔታ, የእኛን መግለጫ እንደገና መፍጠር አለብን.

ተመሳሳዩን መጠይቅ እየፈፀሙ ከሆነ በአምድዎ ውስጥ ያሉት የውሂብ አይነቶች ግራ መጋባታቸውን ያረጋግጡ። ለ NULL መጠንቀቅ አለብህ። ReadyStatements መጠቀም ከጀመርን በኋላ ይህ የተለመደ ስህተት ነው።

እሺ በርቷል ምናልባት ሹፌሩን ወስደው ይሆናል. እና ምርታማነት ቀንሷል። ነገሮች መጥፎ ሆነዋል።

ይህ እንዴት ይሆናል? ይሄ ስህተት ነው ወይስ ባህሪ? እንደ አለመታደል ሆኖ ይህ ስህተት ወይም ባህሪ መሆኑን ለመረዳት አልተቻለም። ግን ይህንን ችግር እንደገና ለማራባት በጣም ቀላል የሆነ ሁኔታ አለ. እሷ ሙሉ በሙሉ ባልተጠበቀ ሁኔታ አድፍጣለች። እና እሱ በቀጥታ ከአንድ ጠረጴዛ ላይ ናሙናዎችን ያካትታል. እኛ በእርግጥ ብዙ እንደዚህ ያሉ ጥያቄዎች ነበሩን። እንደ አንድ ደንብ ሁለት ወይም ሶስት ሰንጠረዦችን አካተዋል, ነገር ግን እንደዚህ አይነት የመልሶ ማጫወት ሁኔታ አለ. ማንኛውንም ስሪት ከውሂብ ጎታዎ ይውሰዱ እና ያጫውቱት።

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

ነጥቡ ሁለት ዓምዶች አሉን, እያንዳንዳቸው ጠቋሚዎች ናቸው. በአንድ NULL አምድ ውስጥ አንድ ሚሊዮን ረድፎች አሉ። እና ሁለተኛው አምድ 20 መስመሮችን ብቻ ይዟል. ያለገደብ ተለዋዋጮች ስንፈጽም ሁሉም ነገር በደንብ ይሰራል።

በተጠረዙ ተለዋዋጮች መፈፀም ከጀመርን ማለትም "?" ወይም "$1" ለጥያቄያችን፣ ምን እያገኘን ነው?

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

የመጀመሪያው አፈፃፀም እንደተጠበቀው ነው. ሁለተኛው ትንሽ ፈጣን ነው. የሆነ ነገር ተደብቆ ነበር። ሦስተኛ ፣ አራተኛ ፣ አምስተኛ። ከዚያ ባንግ - እና እንደዚህ ያለ ነገር። እና በጣም መጥፎው ነገር ይህ በስድስተኛው ግድያ ላይ ነው. ትክክለኛው የአፈፃፀም እቅድ ምን እንደሆነ ለመረዳት በትክክል ስድስት ግድያዎችን ማድረግ አስፈላጊ መሆኑን ማን ያውቃል?

ጥፋተኛ ማን ነው? ምን ሆነ? የመረጃ ቋቱ ማመቻቸትን ይዟል። እና ለአጠቃላይ ጉዳይ የተመቻቸ ይመስላል። እና በዚህ መሰረት፣ ከተወሰነ ጊዜ ጀምሮ፣ ወደ አጠቃላይ እቅድ ትቀይራለች፣ ይህም በሚያሳዝን ሁኔታ፣ የተለየ ሊሆን ይችላል። ወደ ተመሳሳይነት ሊለወጥ ይችላል, ወይም የተለየ ሊሆን ይችላል. እና ወደዚህ ባህሪ የሚመራ አንድ ዓይነት የመነሻ እሴት አለ።

ስለሱ ምን ማድረግ ይችላሉ? እዚህ ፣ በእርግጥ ፣ ማንኛውንም ነገር መገመት የበለጠ ከባድ ነው። የምንጠቀመው ቀላል መፍትሄ አለ. ይህ +0 ነው, OFFSET 0. በእርግጠኝነት እንደዚህ አይነት መፍትሄዎችን ያውቃሉ. እኛ ብቻ እንወስዳለን እና ወደ ጥያቄው "+0" እንጨምራለን እና ሁሉም ነገር ደህና ነው. በኋላ አሳይሃለሁ።

እና ሌላ አማራጭ አለ - እቅዶቹን በጥንቃቄ ይመልከቱ. ገንቢው ጥያቄን መጻፍ ብቻ ሳይሆን "ትንተና ማብራራት" 6 ጊዜ መናገር አለበት. 5 ከሆነ አይሰራም።

እና ሶስተኛ አማራጭ አለ - ለ pgsql-hackers ደብዳቤ ይጻፉ. ጽፌ ነበር፣ ሆኖም፣ ይህ ስህተት ወይም ባህሪ እንደሆነ እስካሁን ግልጽ አይደለም።

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

ይህ ስህተት ወይም ባህሪ መሆኑን እያሰብን ሳለ፣ እናስተካክለው። ጥያቄያችንን እንውሰድ እና "+0" እንጨምር። ሁሉ ነገር ጥሩ ነው. ሁለት ምልክቶች እና እንዴት እንደሆነ ወይም ምን እንደሆነ እንኳን ማሰብ አያስፈልግዎትም. በጣም ቀላል። የመረጃ ቋቱ በቀላሉ በዚህ አምድ ላይ ኢንዴክስ እንዳይጠቀም ከልክለናል። በ "+0" አምድ ላይ ኢንዴክስ የለንም እና ያ ነው, የውሂብ ጎታ መረጃ ጠቋሚውን አይጠቀምም, ሁሉም ነገር ጥሩ ነው.

ይህ ደንብ ነው 6 ያብራሩ. አሁን በአሁን ስሪቶች ውስጥ የታሰሩ ተለዋዋጭዎች ካሉ 6 ጊዜ ማድረግ አለብዎት. የታሰሩ ተለዋዋጮች ከሌሉዎት እኛ የምናደርገው ይህ ነው። እና በመጨረሻም ይህ ጥያቄ በትክክል አልተሳካም. ተንኮለኛ ነገር አይደለም።

የሚመስለው ምን ያህል ይቻላል? እዚህ አንድ ሳንካ፣ እዚያም ስህተት። በእውነቱ ፣ ስህተቱ በሁሉም ቦታ አለ።

እስቲ ጠለቅ ብለን እንመርምር። ለምሳሌ, ሁለት እቅዶች አሉን. እቅድ A ከሠንጠረዥ S እና ዲያግራም B ከሠንጠረዥ S ጋር። መጠይቅ - ከጠረጴዛ ላይ ውሂብ ይምረጡ. በዚህ ጉዳይ ላይ ምን ይኖረናል? ስህተት ይኖረናል። ከላይ ያሉት ሁሉ ይኖሩናል. ደንቡ - ስህተት በሁሉም ቦታ አለ, ከላይ ያሉት ሁሉ ይኖሩናል.

አሁን ጥያቄው "ለምን?" ንድፍ ካለን ሰንጠረዡን የት እንደምንፈልግ የሚነግረን "የፍለጋ_ዱካ" ተለዋዋጭ እንዳለ የሚያሳይ ሰነድ ያለ ይመስላል። ተለዋዋጭ ያለ ይመስላል።

ችግሩ ምንድን ነው? ችግሩ በአገልጋይ-የተዘጋጁ መግለጫዎች የፍለጋ_መንገድ በአንድ ሰው ሊቀየር እንደሚችል አይጠራጠሩም። ይህ ዋጋ እንደ የውሂብ ጎታ ቋሚ ሆኖ ይቆያል። እና አንዳንድ ክፍሎች አዲስ ትርጉም ላያገኙ ይችላሉ።

በእርግጥ ይህ እርስዎ በሚሞክሩበት ስሪት ላይ ይወሰናል. የእርስዎ ጠረጴዛዎች ምን ያህል በቁም ነገር እንደሚለያዩ ይወሰናል። እና ስሪት 9.1 በቀላሉ የድሮ መጠይቆችን ያስፈጽማል. አዲስ ስሪቶች ስህተቱን ሊይዙ እና ስህተት እንዳለዎት ሊነግሩዎት ይችላሉ።

የፍለጋ_ዱካ + በአገልጋይ የተዘጋጁ መግለጫዎችን ያቀናብሩ =
የተሸጎጠ እቅድ የውጤት አይነት መቀየር የለበትም

እንዴት ማከም ይቻላል? ቀላል የምግብ አዘገጃጀት መመሪያ አለ - አታድርጉ. አፕሊኬሽኑ እየሰራ እያለ የፍለጋ_ዱካ መቀየር አያስፈልግም። ከቀየሩ, አዲስ ግንኙነት መፍጠር የተሻለ ነው.

መወያየት፣ ማለትም መክፈት፣ መወያየት፣ መደመር ይችላሉ። ምናልባት አንድ ሰው እሴት ሲቀይር የውሂብ ጎታው ስለዚህ ጉዳይ ለደንበኛው መንገር እንዳለበት የውሂብ ጎታ አዘጋጆቹን ልናሳምን እንችላለን፡- “እነሆ የእርስዎ ዋጋ እዚህ ተዘምኗል። ምናልባት መግለጫዎቹን እንደገና ማቀናበር እና እንደገና መፍጠር ያስፈልግዎታል? አሁን የመረጃ ቋቱ በድብቅ ይሠራል እና መግለጫዎቹ በውስጣቸው የሆነ ቦታ እንደተቀየሩ በምንም መንገድ አይዘግብም።

እና እንደገና አፅንዖት እሰጣለሁ - ይህ ለጃቫ የተለመደ ያልሆነ ነገር ነው. በPL/pgSQL አንድ ለአንድ እናያለን። ግን እዚያ ይራባል.

አንዳንድ ተጨማሪ የውሂብ ምርጫን እንሞክር። እንመርጣለን እና እንመርጣለን. አንድ ሚሊዮን ረድፎች ያለው ጠረጴዛ አለን። እያንዳንዱ መስመር ኪሎባይት ነው። በግምት አንድ ጊጋባይት ውሂብ። እና በ 128 ሜጋባይት በጃቫ ማሽን ውስጥ የሚሰራ ማህደረ ትውስታ አለን.

እኛ በሁሉም መጽሃፎች ላይ እንደተመከርነው የዥረት ሂደትን እንጠቀማለን። ማለትም resultSet ን ከፍተን ውሂቡን በጥቂቱ እናነባለን። ይሠራ ይሆን? ከማስታወስ ይወድቃል? ትንሽ ታነባለህ? በዳታቤዝ እንታመን፣ በፖስትግሬስ እንታመን። አናምንም። ከሜሞሪ ውጪ እንወድቃለን? OutOfMemory ማን አጋጠመው? ከዚያ በኋላ ማነው ማስተካከል የቻለው? አንድ ሰው ማስተካከል ችሏል።

አንድ ሚሊዮን ረድፎች ካሉዎት መምረጥ እና መምረጥ ብቻ አይችሉም። OFFSET/LIMIT ያስፈልጋል። ለዚህ አማራጭ ማን ነው? እና በአውቶኮሚት መጫወት የሚደግፈው ማነው?

እዚህ ፣ እንደተለመደው ፣ በጣም ያልተጠበቀው አማራጭ ትክክል ይሆናል። እና በድንገት autoCommit ን ካጠፉት ይረዳል። ለምንድነው? ሳይንስ ስለዚህ ጉዳይ አያውቅም።

ነገር ግን በነባሪነት ከፖስትግሬስ ዳታቤዝ ጋር የሚገናኙ ሁሉም ደንበኞች ሙሉውን ውሂብ ያመጣሉ. PgJDBC በዚህ ረገድ የተለየ አይደለም, ሁሉንም ረድፎች ይመርጣል.

በFetchSize ጭብጥ ላይ ልዩነት አለ፣ ማለትም በተለየ መግለጫ ደረጃ ማለት ትችላለህ እዚህ፣ እባክህ ውሂብ በ 10፣ 50 ምረጥ። ግን አውቶኮሚቲንን እስክታጠፋ ድረስ ይሄ አይሰራም። AutoCommit ጠፍቷል - መስራት ይጀምራል።

ግን በኮዱ ውስጥ ማለፍ እና setFetchSizeን በየቦታው ማዋቀር የማይመች ነው። ስለዚህ፣ ለግንኙነቱ በሙሉ ነባሪ ዋጋ የሚገልጽ ቅንብር አደረግን።

ነው ያልነው። መለኪያው ተዋቅሯል። እና ምን አገኘን? አነስተኛ መጠን ከመረጥን, ለምሳሌ, በአንድ ጊዜ 10 ረድፎችን ከመረጥን, ከዚያም በጣም ትልቅ የትርፍ ወጪዎች አሉን. ስለዚህ, ይህ ዋጋ ወደ አንድ መቶ ገደማ መቀመጥ አለበት.

በሐሳብ ደረጃ ፣ በእርግጥ ፣ አሁንም በባይት እንዴት እንደሚገድቡ መማር አለብዎት ፣ ግን የምግብ አዘገጃጀቱ ይህ ነው፡ ነባሪ RowFetchSize ን ከአንድ መቶ በላይ ያዘጋጁ እና ደስተኛ ይሁኑ።

ወደ ውሂብ ማስገባት እንሂድ። ማስገባት ቀላል ነው, የተለያዩ አማራጮች አሉ. ለምሳሌ፣ INSERT፣ VALUES። ይህ ጥሩ አማራጭ ነው። "ምረጥ አስገባ" ማለት ትችላለህ። በተግባር ግን ተመሳሳይ ነገር ነው. በአፈፃፀም ውስጥ ምንም ልዩነት የለም.

መጽሐፍት የባች መግለጫን ማስፈጸም እንደሚያስፈልግዎ ይናገራሉ፡ መጽሃፍቶች ብዙ ውስብስብ ትዕዛዞችን በበርካታ ቅንፍ መፈፀም እንደሚችሉ ይናገራሉ። እና Postgres በጣም ጥሩ ባህሪ አለው - COPY ማድረግ ይችላሉ ፣ ማለትም በፍጥነት ያድርጉት።

ከለካው, እንደገና አንዳንድ አስደሳች ግኝቶችን ማድረግ ትችላለህ. ይህ እንዴት እንዲሠራ እንፈልጋለን? ለመተንተን እና አላስፈላጊ ትዕዛዞችን ላለመፈጸም እንፈልጋለን.

በተግባር፣ TCP ይህንን እንድናደርግ አይፈቅድልንም። ደንበኛው ጥያቄ በመላክ ከተጠመደ፣ ዳታቤዙ ለእኛ ምላሾችን ለመላክ ሲሞክር ጥያቄዎቹን አያነብም። የመጨረሻው ውጤት ደንበኛው ጥያቄውን ለማንበብ የውሂብ ጎታውን ይጠብቃል, እና የውሂብ ጎታው ደንበኛው ምላሹን እንዲያነብ ይጠብቃል.

እና ስለዚህ ደንበኛው በየጊዜው የማመሳሰል ፓኬት ለመላክ ይገደዳል። ተጨማሪ የአውታረ መረብ መስተጋብር፣ ተጨማሪ ጊዜ ማባከን።

እና እነሱን በጨመርን መጠን, እየባሰ ይሄዳል. ሹፌሩ በጣም ተስፋ አስቆራጭ ነው እና ብዙ ጊዜ ያክላቸዋል፣ በየ200 መስመሮች አንድ ጊዜ፣ እንደ የመስመሮቹ መጠን፣ ወዘተ.

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

አንድ መስመር ብቻ ካረሙ እና ሁሉም ነገር 10 ጊዜ ያፋጥነዋል። ያጋጥማል. ለምን? እንደተለመደው, እንደዚህ ያለ ቋሚ የሆነ ቦታ አስቀድሞ ጥቅም ላይ ውሏል. እና እሴቱ "128" ማለት ድፍን አለመጠቀም ማለት ነው.

የጃቫ ማይክሮቤንችማርክ ማሰሪያ

ይህ በይፋዊው ስሪት ውስጥ አለመካተቱ ጥሩ ነው። መለቀቅ ከመጀመሩ በፊት ተገኝቷል። እኔ የምሰጣቸው ሁሉም ትርጉሞች በዘመናዊ ስሪቶች ላይ የተመሰረቱ ናቸው.

እስቲ እንሞክረው። InsertBatch በቀላል እንለካለን። InsertBatchን ብዙ ጊዜ እንለካለን፣ ማለትም ተመሳሳይ ነገር፣ ግን ብዙ እሴቶች አሉ። ተንኮለኛ እንቅስቃሴ። ሁሉም ሰው ይህን ማድረግ አይችልም, ነገር ግን በጣም ቀላል እንቅስቃሴ ነው, ከ COPY በጣም ቀላል ነው.

COPY ማድረግ ይችላሉ።

እና ይህንን በመዋቅሮች ላይ ማድረግ ይችላሉ. የተጠቃሚውን ነባሪ አይነት፣ ድርድርን ማለፍ እና በቀጥታ ወደ ጠረጴዛው አስገባ።

ሊንኩን ከከፈቱ፡ pgjdbc/ubenchmsrk/InsertBatch.java፡ ይህ ኮድ በ GitHub ላይ ነው። በተለይ እዚያ ምን ጥያቄዎች እንደሚፈጠሩ ማየት ይችላሉ። ምንም ችግር የለውም.

ጀመርን። እና በመጀመሪያ የተገነዘብነው ባች አለመጠቀም በቀላሉ የማይቻል ነው። ሁሉም የማጣቀሚያ አማራጮች ዜሮ ናቸው, ማለትም የማስፈጸሚያ ጊዜ ከአንድ ጊዜ አፈፃፀም ጋር ሲነጻጸር በተግባር ዜሮ ነው.

ውሂብ አስገባን. በጣም ቀላል ጠረጴዛ ነው. ሶስት ዓምዶች. እና እዚህ ምን እናያለን? እነዚህ ሦስቱም አማራጮች በግምት ተመጣጣኝ መሆናቸውን እናያለን። እና COPY በእርግጥ የተሻለ ነው።

ቁርጥራጮችን ስናስገባ ነው። አንድ VALUES እሴት፣ ሁለት ቫልዩኤስ እሴቶች፣ ሶስት ቫልዩኤስ እሴቶች ስንል ወይም 10 ቱን በነጠላ ሰረዝ ጠቁመናል። ይህ አሁን አግድም ነው። 1, 2, 4, 128. በሰማያዊ ቀለም የተቀዳው ባች ኢንሰርት በጣም ጥሩ ስሜት እንዲሰማው እንደሚያደርግ ማየት ይቻላል. ማለትም፣ አንድ በአንድ ስታስገቡ ወይም አራት በአንድ ስታስገቡ እንኳን በእጥፍ ይበልጣል፣ ምክንያቱም ትንሽ ተጨማሪ ወደ VALUES ስለጨበጥን ብቻ ነው። ያነሱ EXECUTE ስራዎች።

COPYን በትናንሽ ጥራዞች መጠቀም እጅግ በጣም ተስፋ ሰጪ ነው። በመጀመሪያዎቹ ሁለቱ ላይ እንኳን አልሳልኩም። ወደ መንግሥተ ሰማያት ይሄዳሉ፣ ማለትም፣ እነዚህ አረንጓዴ ቁጥሮች ለ COPY።

ቢያንስ መቶ ረድፎች ውሂብ ሲኖርዎት COPY ጥቅም ላይ መዋል አለበት። ይህንን ግንኙነት የመክፈቱ የላይኛው ጫፍ ትልቅ ነው. እና, እውነቱን ለመናገር, በዚህ አቅጣጫ አልቆፈርኩም. ባች አመቻችቻለሁ፣ ግን ኮፒ አይደለም።

ቀጥሎ ምን እናደርጋለን? ሞክረነዋል። ብዙ ትርጉሞችን የሚያጣምር አወቃቀሮችን ወይም ብልህ መታጠቢያን መጠቀም እንዳለብን እንረዳለን።

ከዛሬ ዘገባ ምን መውሰድ አለቦት?

• የተዘጋጀ መግለጫ የሁላችንም ነገር ነው። ይህ ለምርታማነት ብዙ ይሰጣል. በቅባት ውስጥ ትልቅ ፍሎፕ ይፈጥራል.
• እና 6 ጊዜ ማብራራት ያስፈልግዎታል።
• እና የቀረውን የችግር መጠይቆቻችንን በመቶኛ ለማስተካከል OFFSET 0ን እና እንደ +0 ያሉ ዘዴዎችን ማደብዘዝ አለብን።

ምንጭ: hab.com