PostgreSQL ഉം JDBC ഉം എല്ലാ ജ്യൂസും പിഴിഞ്ഞെടുക്കുന്നു. വ്ലാഡിമിർ സിറ്റ്നിക്കോവ്

വ്‌ളാഡിമിർ സിറ്റ്‌നിക്കോവിന്റെ 2016-ലെ ആദ്യകാല റിപ്പോർട്ടിന്റെ ട്രാൻസ്‌ക്രിപ്റ്റ് വായിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു "PostgreSQL ഉം JDBC ഉം എല്ലാ നീരും പിഴിഞ്ഞെടുക്കുന്നു"

ഗുഡ് ആഫ്റ്റർനൂൺ എന്റെ പേര് വ്ലാഡിമിർ സിറ്റ്നിക്കോവ്. ഞാൻ 10 വർഷമായി നെറ്റ്ക്രാക്കറിൽ ജോലി ചെയ്യുന്നു. ഞാൻ കൂടുതലും ഉൽപ്പാദനക്ഷമതയിലാണ്. ജാവയുമായി ബന്ധപ്പെട്ട എല്ലാം, SQL-മായി ബന്ധപ്പെട്ട എല്ലാം എനിക്ക് ഇഷ്ടമാണ്.

ഞങ്ങൾ PostgreSQL ഒരു ഡാറ്റാബേസ് സെർവറായി ഉപയോഗിക്കാൻ തുടങ്ങിയപ്പോൾ കമ്പനിയിൽ ഞങ്ങൾ നേരിട്ടതിനെക്കുറിച്ച് ഇന്ന് ഞാൻ സംസാരിക്കും. ഞങ്ങൾ കൂടുതലും ജാവയിൽ പ്രവർത്തിക്കുന്നു. എന്നാൽ ഇന്ന് ഞാൻ നിങ്ങളോട് പറയാൻ പോകുന്നത് ജാവയെ കുറിച്ച് മാത്രമല്ല. പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, ഇത് മറ്റ് ഭാഷകളിലും സംഭവിക്കുന്നു.

ഞങ്ങൾ സംസാരിക്കും:

• ഡാറ്റ സാമ്പിളിനെക്കുറിച്ച്.
• ഡാറ്റ സംരക്ഷിക്കുന്നതിനെക്കുറിച്ച്.
• കൂടാതെ പ്രകടനത്തെക്കുറിച്ചും.
• അവിടെ കുഴിച്ചിട്ടിരിക്കുന്ന അണ്ടർവാട്ടർ റേക്കുകളെക്കുറിച്ചും.

ലളിതമായ ഒരു ചോദ്യത്തിൽ നിന്ന് തുടങ്ങാം. പ്രാഥമിക കീയെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ പട്ടികയിൽ നിന്ന് ഒരു വരി തിരഞ്ഞെടുക്കുന്നു.

ഡാറ്റാബേസ് ഒരേ ഹോസ്റ്റിലാണ് സ്ഥിതി ചെയ്യുന്നത്. ഈ കൃഷിയെല്ലാം 20 മില്ലിസെക്കൻഡ് എടുക്കും.

ഈ 20 മില്ലിസെക്കൻഡുകൾ ധാരാളം. നിങ്ങൾക്ക് അത്തരം 100 അഭ്യർത്ഥനകൾ ഉണ്ടെങ്കിൽ, ഈ അഭ്യർത്ഥനകളിലൂടെ സ്ക്രോൾ ചെയ്യാൻ നിങ്ങൾ സെക്കൻഡിൽ സമയം ചെലവഴിക്കുന്നു, അതായത് ഞങ്ങൾ സമയം പാഴാക്കുകയാണ്.

ഇത് ചെയ്യാൻ ഞങ്ങൾ ഇഷ്ടപ്പെടുന്നില്ല, ഇതിനായി അടിസ്ഥാനം എന്താണ് വാഗ്ദാനം ചെയ്യുന്നതെന്ന് നോക്കുക. ഡാറ്റാബേസ് ചോദ്യങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നതിന് രണ്ട് ഓപ്ഷനുകൾ വാഗ്ദാനം ചെയ്യുന്നു.

ആദ്യ ഓപ്ഷൻ ഒരു ലളിതമായ അഭ്യർത്ഥനയാണ്. അതിൽ എന്താണ് നല്ലത്? ഞങ്ങൾ അത് എടുത്ത് അയയ്ക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല.

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

ഡാറ്റാബേസിന് ഒരു വിപുലമായ അന്വേഷണവും ഉണ്ട്, അത് കൂടുതൽ തന്ത്രപരവും എന്നാൽ കൂടുതൽ പ്രവർത്തനപരവുമാണ്. പാഴ്‌സിംഗ്, എക്‌സിക്യൂഷൻ, വേരിയബിൾ ബൈൻഡിംഗ് മുതലായവയ്‌ക്കായി നിങ്ങൾക്ക് പ്രത്യേകമായി ഒരു അഭ്യർത്ഥന അയയ്‌ക്കാൻ കഴിയും.

നിലവിലെ റിപ്പോർട്ടിൽ ഞങ്ങൾ ഉൾപ്പെടുത്താത്ത ഒന്നാണ് സൂപ്പർ എക്സ്റ്റൻഡഡ് ചോദ്യം. ഞങ്ങൾക്ക്, ഒരുപക്ഷേ, ഡാറ്റാബേസിൽ നിന്ന് എന്തെങ്കിലും വേണം, ചില രൂപത്തിൽ രൂപപ്പെട്ട ഒരു ആഗ്രഹ പട്ടികയുണ്ട്, അതായത്, ഇതാണ് ഞങ്ങൾക്ക് വേണ്ടത്, എന്നാൽ ഇപ്പോളും അടുത്ത വർഷവും അത് അസാധ്യമാണ്. അതിനാൽ ഞങ്ങൾ ഇത് റെക്കോർഡുചെയ്‌തു, പ്രധാന ആളുകളെ വിറപ്പിച്ച് ഞങ്ങൾ ചുറ്റിക്കറങ്ങും.

നമുക്ക് ചെയ്യാൻ കഴിയുന്നത് സിമ്പിൾ ക്വറിയും എക്സ്റ്റൻഡഡ് ക്വറിയുമാണ്.

ഓരോ സമീപനത്തിന്റെയും പ്രത്യേകത എന്താണ്?

ഒറ്റത്തവണ നിർവ്വഹണത്തിന് ഒരു ലളിതമായ ചോദ്യം നല്ലതാണ്. ഒരിക്കൽ ചെയ്തു മറന്നു. ബൈനറി ഡാറ്റ ഫോർമാറ്റിനെ പിന്തുണയ്ക്കുന്നില്ല എന്നതാണ് പ്രശ്നം, അതായത് ഉയർന്ന പ്രകടനമുള്ള ചില സിസ്റ്റങ്ങൾക്ക് ഇത് അനുയോജ്യമല്ല.

വിപുലീകൃത അന്വേഷണം - പാഴ്‌സിംഗിൽ സമയം ലാഭിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഇതാണ് ഞങ്ങൾ ചെയ്തതും ഉപയോഗിക്കാൻ തുടങ്ങിയതും. ഇത് ശരിക്കും ഞങ്ങളെ സഹായിച്ചു. പാഴ്‌സിംഗിൽ മാത്രമല്ല സമ്പാദ്യം. ഡാറ്റ കൈമാറ്റത്തിൽ ലാഭമുണ്ട്. ബൈനറി ഫോർമാറ്റിൽ ഡാറ്റ കൈമാറുന്നത് കൂടുതൽ കാര്യക്ഷമമാണ്.

നമുക്ക് പരിശീലനത്തിലേക്ക് പോകാം. ഒരു സാധാരണ ആപ്ലിക്കേഷൻ ഇങ്ങനെയാണ്. ഇത് ജാവ മുതലായവ ആകാം.

ഞങ്ങൾ പ്രസ്താവന സൃഷ്ടിച്ചു. കമാൻഡ് നിർവഹിച്ചു. അടുത്ത് സൃഷ്ടിച്ചു. ഇവിടെ എവിടെയാണ് തെറ്റ്? എന്താണ് പ്രശ്നം? ഒരു പ്രശ്നവുമില്ല. എല്ലാ പുസ്തകങ്ങളിലും പറയുന്നത് ഇതാണ്. ഇങ്ങനെയാണ് എഴുതേണ്ടത്. നിങ്ങൾക്ക് പരമാവധി പ്രകടനം വേണമെങ്കിൽ, ഇതുപോലെ എഴുതുക.

എന്നാൽ ഇത് ഫലപ്രദമല്ലെന്ന് പ്രാക്ടീസ് തെളിയിച്ചിട്ടുണ്ട്. എന്തുകൊണ്ട്? കാരണം നമുക്ക് ഒരു "അടുത്ത" രീതിയുണ്ട്. ഞങ്ങൾ ഇത് ചെയ്യുമ്പോൾ, ഡാറ്റാബേസ് വീക്ഷണകോണിൽ നിന്ന് ഇത് ഒരു ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുന്ന ഒരു പുകവലിക്കാരനെപ്പോലെയാണെന്ന് മാറുന്നു. ഞങ്ങൾ പറഞ്ഞു "പാഴ്‌സ് എക്‌സിക്യൂട്ട് ഡീലോക്കേറ്റ്".

എന്തിനാണ് ഈ അധിക സൃഷ്ടിയും പ്രസ്താവനകൾ ഇറക്കലും? ആർക്കും അവരെ ആവശ്യമില്ല. എന്നാൽ സാധാരണയായി PreparedStatements ൽ സംഭവിക്കുന്നത് നമ്മൾ അവയെ ക്ലോസ് ചെയ്യുമ്പോൾ അവ ഡാറ്റാബേസിലെ എല്ലാം ക്ലോസ് ചെയ്യുന്നതാണ്. ഇതല്ല ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്.

ആരോഗ്യമുള്ള ആളുകളെപ്പോലെ, അടിത്തറയിൽ പ്രവർത്തിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ ഞങ്ങളുടെ പ്രസ്താവന ഒരിക്കൽ എടുത്ത് തയ്യാറാക്കി, പിന്നീട് ഞങ്ങൾ അത് പലതവണ നടപ്പിലാക്കുന്നു. വാസ്തവത്തിൽ, നിരവധി തവണ - ഇത് ആപ്ലിക്കേഷനുകളുടെ മുഴുവൻ ജീവിതത്തിലും ഒരിക്കൽ - അവ പാഴ്‌സ് ചെയ്‌തു. വ്യത്യസ്ത REST-കളിൽ ഞങ്ങൾ ഒരേ പ്രസ്താവന ഐഡി ഉപയോഗിക്കുന്നു. ഇതാണ് ഞങ്ങളുടെ ലക്ഷ്യം.

നമുക്ക് ഇത് എങ്ങനെ നേടാനാകും?

ഇത് വളരെ ലളിതമാണ് - പ്രസ്താവനകൾ അടയ്ക്കേണ്ട ആവശ്യമില്ല. ഞങ്ങൾ ഇത് ഇതുപോലെ എഴുതുന്നു: "തയ്യാറുക" "എക്സിക്യൂട്ട്".

ഞങ്ങൾ ഇതുപോലെ എന്തെങ്കിലും വിക്ഷേപിച്ചാൽ, എവിടെയെങ്കിലും എന്തെങ്കിലും കവിഞ്ഞൊഴുകുമെന്ന് വ്യക്തമാണ്. ഇത് വ്യക്തമല്ലെങ്കിൽ, നിങ്ങൾക്ക് ഇത് പരീക്ഷിക്കാം. ഈ ലളിതമായ രീതി ഉപയോഗിക്കുന്ന ഒരു ബെഞ്ച്മാർക്ക് എഴുതാം. ഒരു പ്രസ്താവന സൃഷ്ടിക്കുക. ഡ്രൈവറിന്റെ ചില പതിപ്പുകളിൽ ഞങ്ങൾ ഇത് സമാരംഭിക്കുകയും അതിന്റെ മെമ്മറി മുഴുവൻ നഷ്‌ടപ്പെടുമ്പോൾ അത് വളരെ വേഗത്തിൽ ക്രാഷാകുകയും ചെയ്യുന്നു.

അത്തരം പിശകുകൾ എളുപ്പത്തിൽ തിരുത്തപ്പെടുമെന്ന് വ്യക്തമാണ്. ഞാൻ അവരെക്കുറിച്ച് സംസാരിക്കില്ല. എന്നാൽ പുതിയ പതിപ്പ് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുമെന്ന് ഞാൻ പറയും. രീതി മണ്ടത്തരമാണ്, പക്ഷേ ഇപ്പോഴും.

എങ്ങനെ ശരിയായി പ്രവർത്തിക്കാം? ഇതിനായി നമ്മൾ എന്താണ് ചെയ്യേണ്ടത്?

വാസ്തവത്തിൽ, ആപ്ലിക്കേഷനുകൾ എല്ലായ്പ്പോഴും പ്രസ്താവനകൾ അടയ്ക്കുന്നു. എല്ലാ പുസ്തകങ്ങളിലും അവർ അത് അടച്ചുപൂട്ടാൻ പറയുന്നു, അല്ലെങ്കിൽ മെമ്മറി ചോർന്നുപോകും.

കൂടാതെ ചോദ്യങ്ങൾ എങ്ങനെ കാഷെ ചെയ്യണമെന്ന് PostgreSQL-ന് അറിയില്ല. ഓരോ സെഷനും ഈ കാഷെ സൃഷ്ടിക്കേണ്ടത് ആവശ്യമാണ്.

പാഴ്‌സിംഗിൽ സമയം കളയാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല.

പിന്നെ പതിവുപോലെ രണ്ടു വഴികളുണ്ട്.

ആദ്യത്തെ ഓപ്ഷൻ നമ്മൾ അത് എടുത്ത് എല്ലാം PgSQL-ൽ പൊതിയാം എന്ന് പറയുക എന്നതാണ്. അവിടെ ഒരു കാഷെ ഉണ്ട്. ഇത് എല്ലാം ക്യാഷ് ചെയ്യുന്നു. അത് ഗംഭീരമായി മാറും. ഞങ്ങൾ ഇത് കണ്ടു. ഞങ്ങൾക്ക് 100500 അഭ്യർത്ഥനകളുണ്ട്. പ്രവർത്തിക്കുന്നില്ല. അഭ്യർത്ഥനകൾ സ്വമേധയാ നടപടിക്രമങ്ങളാക്കി മാറ്റാൻ ഞങ്ങൾ സമ്മതിക്കുന്നില്ല. ഇല്ല ഇല്ല.

ഞങ്ങൾക്ക് രണ്ടാമത്തെ ഓപ്ഷൻ ഉണ്ട് - അത് എടുത്ത് സ്വയം മുറിക്കുക. ഞങ്ങൾ ഉറവിടങ്ങൾ തുറന്ന് മുറിക്കാൻ തുടങ്ങുന്നു. ഞങ്ങൾ കണ്ടു കണ്ടു. ഇത് ചെയ്യാൻ അത്ര ബുദ്ധിമുട്ടുള്ള കാര്യമല്ലെന്ന് മനസ്സിലായി.

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

ഇത് 2015 ഓഗസ്റ്റിൽ പ്രത്യക്ഷപ്പെട്ടു. ഇപ്പോൾ കൂടുതൽ ആധുനിക പതിപ്പ് ഉണ്ട്. പിന്നെ എല്ലാം ഗംഭീരം. ഇത് വളരെ നന്നായി പ്രവർത്തിക്കുന്നു, ഞങ്ങൾ ആപ്ലിക്കേഷനിൽ ഒന്നും മാറ്റില്ല. ഞങ്ങൾ PgSQL-ന്റെ ദിശയിൽ ചിന്തിക്കുന്നത് പോലും നിർത്തി, അതായത് എല്ലാ ഓവർഹെഡ് ചെലവുകളും ഏതാണ്ട് പൂജ്യമായി കുറയ്ക്കാൻ ഇത് ഞങ്ങൾക്ക് മതിയായിരുന്നു.

അതനുസരിച്ച്, ഓരോ ഒറ്റത്തവണ അഭ്യർത്ഥനയിലും ഡാറ്റാബേസിൽ മെമ്മറി പാഴാകാതിരിക്കാൻ സെർവർ തയ്യാറാക്കിയ പ്രസ്താവനകൾ അഞ്ചാമത്തെ എക്സിക്യൂഷനിൽ സജീവമാക്കുന്നു.

നിങ്ങൾക്ക് ചോദിച്ചേക്കാം - അക്കങ്ങൾ എവിടെയാണ്? നിങ്ങൾക്ക് എന്താണ് ലഭിക്കുന്നത്? ഇവിടെ ഞാൻ നമ്പറുകൾ നൽകില്ല, കാരണം ഓരോ അഭ്യർത്ഥനയ്ക്കും അതിന്റേതായ ഉണ്ട്.

ഞങ്ങളുടെ അന്വേഷണങ്ങൾ OLTP ചോദ്യങ്ങളിൽ പാഴ്‌സിംഗിനായി ഏകദേശം 20 മില്ലിസെക്കൻഡ് ചെലവഴിച്ചു. നിർവ്വഹണത്തിന് 0,5 മില്ലിസെക്കൻഡും പാഴ്സിങ്ങിന് 20 മില്ലിസെക്കൻഡും ഉണ്ടായിരുന്നു. അഭ്യർത്ഥന - 10 കിബി ടെക്സ്റ്റ്, 170 ലൈനുകൾ പ്ലാൻ. ഇതൊരു OLTP അഭ്യർത്ഥനയാണ്. ഇത് 1, 5, 10 വരികൾ അഭ്യർത്ഥിക്കുന്നു, ചിലപ്പോൾ കൂടുതൽ.

എന്നാൽ 20 മില്ലിസെക്കൻഡ് പാഴാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല. ഞങ്ങൾ അത് 0 ആയി കുറച്ചു. എല്ലാം ഗംഭീരം.

നിങ്ങൾക്ക് ഇവിടെ നിന്ന് എന്താണ് കൊണ്ടുപോകാൻ കഴിയുക? നിങ്ങൾക്ക് ജാവ ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഡ്രൈവറിന്റെ ആധുനിക പതിപ്പ് എടുത്ത് സന്തോഷിക്കുക.

നിങ്ങൾ മറ്റൊരു ഭാഷ സംസാരിക്കുകയാണെങ്കിൽ, ചിന്തിക്കുക - ഒരുപക്ഷേ നിങ്ങൾക്കും ഇത് ആവശ്യമുണ്ടോ? കാരണം, അന്തിമ ഭാഷയുടെ വീക്ഷണകോണിൽ, ഉദാഹരണത്തിന്, PL 8 അല്ലെങ്കിൽ നിങ്ങൾക്ക് LibPQ ഉണ്ടെങ്കിൽ, നിങ്ങൾ സമയം ചെലവഴിക്കുന്നത് നിർവ്വഹണത്തിലോ പാഴ്‌സിംഗിലോ അല്ലെന്ന് നിങ്ങൾക്ക് വ്യക്തമല്ല, ഇത് പരിശോധിക്കേണ്ടതാണ്. എങ്ങനെ? എല്ലാം സൗജന്യമാണ്.

തെറ്റുകളും ചില പ്രത്യേകതകളും ഉണ്ടെന്നതൊഴിച്ചാൽ. ഞങ്ങൾ ഇപ്പോൾ അവരെക്കുറിച്ച് സംസാരിക്കും. അതിൽ ഭൂരിഭാഗവും വ്യാവസായിക പുരാവസ്തുഗവേഷണത്തെക്കുറിച്ചായിരിക്കും, ഞങ്ങൾ കണ്ടെത്തിയതിനെക്കുറിച്ചാണ്, നമ്മൾ കണ്ടതിനെക്കുറിച്ചായിരിക്കും.

അഭ്യർത്ഥന ചലനാത്മകമായി ജനറേറ്റുചെയ്യുകയാണെങ്കിൽ. അത് സംഭവിക്കുന്നു. ആരോ സ്ട്രിംഗുകൾ ഒരുമിച്ച് ഒട്ടിക്കുന്നു, അതിന്റെ ഫലമായി ഒരു SQL അന്വേഷണം.

എന്തുകൊണ്ടാണ് അവൻ മോശമായത്? ഇത് മോശമാണ്, കാരണം ഓരോ തവണയും ഞങ്ങൾ വ്യത്യസ്ത സ്ട്രിംഗിൽ അവസാനിക്കുന്നു.

ഈ വ്യത്യസ്ത സ്‌ട്രിംഗിന്റെ ഹാഷ്‌കോഡ് വീണ്ടും വായിക്കേണ്ടതുണ്ട്. ഇത് ശരിക്കും ഒരു CPU ടാസ്‌ക് ആണ് - നിലവിലുള്ള ഒരു ഹാഷിൽ പോലും ഒരു നീണ്ട അഭ്യർത്ഥന ടെക്‌സ്‌റ്റ് കണ്ടെത്തുന്നത് അത്ര എളുപ്പമല്ല. അതിനാൽ, നിഗമനം ലളിതമാണ് - അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കരുത്. അവയെ ഒരു വേരിയബിളിൽ സംഭരിക്കുക. സന്തോഷിക്കുക.

അടുത്ത പ്രശ്നം. ഡാറ്റ തരങ്ങൾ പ്രധാനമാണ്. ഏതുതരം NULL ഉണ്ട് എന്നത് പ്രശ്നമല്ല, ഏതെങ്കിലും തരത്തിലുള്ളതായിരിക്കട്ടെ എന്ന് പറയുന്ന ORM-കൾ ഉണ്ട്. Int ആണെങ്കിൽ നമ്മൾ setInt എന്ന് പറയുന്നു. NULL ആണെങ്കിൽ, അത് എപ്പോഴും VARCHAR ആയിരിക്കട്ടെ. NULL ഉള്ളതിൽ അവസാനം എന്ത് വ്യത്യാസമാണ് ഉണ്ടാക്കുന്നത്? ഡാറ്റാബേസ് തന്നെ എല്ലാം മനസ്സിലാക്കും. കൂടാതെ ഈ ചിത്രം പ്രവർത്തിക്കുന്നില്ല.

പ്രായോഗികമായി, ഡാറ്റാബേസ് ഒട്ടും ശ്രദ്ധിക്കുന്നില്ല. ഇത് ഒരു സംഖ്യയാണെന്ന് നിങ്ങൾ ആദ്യമായി പറയുകയും രണ്ടാം തവണ ഇത് ഒരു VARCHAR ആണെന്ന് പറയുകയും ചെയ്താൽ, സെർവർ തയ്യാറാക്കിയ പ്രസ്താവനകൾ വീണ്ടും ഉപയോഗിക്കാൻ കഴിയില്ല. ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾ ഞങ്ങളുടെ പ്രസ്താവന വീണ്ടും സൃഷ്ടിക്കേണ്ടതുണ്ട്.

നിങ്ങൾ ഒരേ ചോദ്യം നടപ്പിലാക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ കോളത്തിലെ ഡാറ്റ തരങ്ങൾ ആശയക്കുഴപ്പത്തിലല്ലെന്ന് ഉറപ്പാക്കുക. NULL-നായി നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. ഞങ്ങൾ PreparedStatements ഉപയോഗിക്കാൻ തുടങ്ങിയതിന് ശേഷം ഞങ്ങൾക്കുണ്ടായ ഒരു സാധാരണ പിശകാണിത്

ശരി, ഓണാക്കി. ഒരുപക്ഷേ അവർ ഡ്രൈവറെ കൊണ്ടുപോയി. ഒപ്പം ഉത്പാദനക്ഷമത കുറഞ്ഞു. കാര്യങ്ങൾ മോശമായി.

ഇത് എങ്ങനെ സംഭവിക്കുന്നു? ഇതൊരു ബഗാണോ അതോ ഫീച്ചറാണോ? നിർഭാഗ്യവശാൽ, ഇതൊരു ബഗാണോ ഫീച്ചറാണോ എന്ന് മനസ്സിലാക്കാൻ കഴിഞ്ഞില്ല. എന്നാൽ ഈ പ്രശ്നം പുനർനിർമ്മിക്കുന്നതിന് വളരെ ലളിതമായ ഒരു സാഹചര്യമുണ്ട്. അവൾ തികച്ചും അപ്രതീക്ഷിതമായി ഞങ്ങളെ പതിയിരുന്ന് ആക്രമിച്ചു. ഒരു ടേബിളിൽ നിന്ന് അക്ഷരാർത്ഥത്തിൽ സാമ്പിൾ എടുക്കുന്നത് ഇതിൽ അടങ്ങിയിരിക്കുന്നു. തീർച്ചയായും, ഞങ്ങൾക്ക് അത്തരം കൂടുതൽ അഭ്യർത്ഥനകൾ ഉണ്ടായിരുന്നു. ചട്ടം പോലെ, അവർ രണ്ടോ മൂന്നോ പട്ടികകൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, എന്നാൽ അത്തരമൊരു പ്ലേബാക്ക് സാഹചര്യമുണ്ട്. നിങ്ങളുടെ ഡാറ്റാബേസിൽ നിന്ന് ഏതെങ്കിലും പതിപ്പ് എടുത്ത് പ്ലേ ചെയ്യുക.

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

നമുക്ക് രണ്ട് നിരകളുണ്ട്, അവയിൽ ഓരോന്നും സൂചികയിലാക്കിയിരിക്കുന്നു എന്നതാണ് കാര്യം. ഒരു NULL കോളത്തിൽ ഒരു ദശലക്ഷം വരികളുണ്ട്. രണ്ടാമത്തെ നിരയിൽ 20 വരികൾ മാത്രമേ ഉള്ളൂ. ബൗണ്ട് വേരിയബിളുകൾ ഇല്ലാതെ നമ്മൾ എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, എല്ലാം നന്നായി പ്രവർത്തിക്കുന്നു.

ബൗണ്ട് വേരിയബിളുകൾ ഉപയോഗിച്ച് നമ്മൾ എക്സിക്യൂട്ട് ചെയ്യാൻ തുടങ്ങിയാൽ, അതായത് നമ്മൾ "?" അല്ലെങ്കിൽ ഞങ്ങളുടെ അഭ്യർത്ഥനയ്‌ക്ക് "$1", നമുക്ക് എന്ത് ലഭിക്കും?

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

ആദ്യ വധശിക്ഷ പ്രതീക്ഷിച്ചതുപോലെ തന്നെ. രണ്ടാമത്തേത് അൽപ്പം വേഗതയുള്ളതാണ്. എന്തോ ക്യാഷ് ചെയ്തു. മൂന്നാമത്തേത്, നാലാമത്തേത്, അഞ്ചാമത്തേത്. പിന്നെ ബാംഗ് - അതു പോലെ എന്തെങ്കിലും. ആറാമത്തെ വധശിക്ഷയിൽ ഇത് സംഭവിക്കുന്നു എന്നതാണ് ഏറ്റവും മോശം കാര്യം. യഥാർത്ഥ നിർവ്വഹണ പദ്ധതി എന്താണെന്ന് മനസിലാക്കാൻ കൃത്യമായി ആറ് വധശിക്ഷകൾ ചെയ്യേണ്ടത് അത്യാവശ്യമാണെന്ന് ആർക്കറിയാം?

ആരാണ് കുറ്റക്കാരൻ? എന്ത് സംഭവിച്ചു? ഡാറ്റാബേസിൽ ഒപ്റ്റിമൈസേഷൻ അടങ്ങിയിരിക്കുന്നു. കൂടാതെ ഇത് ജനറിക് കേസിൽ ഒപ്റ്റിമൈസ് ചെയ്തതായി തോന്നുന്നു. അതനുസരിച്ച്, ചില ഘട്ടങ്ങളിൽ തുടങ്ങി, അവൾ ഒരു പൊതു പദ്ധതിയിലേക്ക് മാറുന്നു, അത് നിർഭാഗ്യവശാൽ, വ്യത്യസ്തമായി മാറിയേക്കാം. അത് ഒന്നായി മാറിയേക്കാം, അല്ലെങ്കിൽ അത് വ്യത്യസ്തമായിരിക്കാം. ഈ സ്വഭാവത്തിലേക്ക് നയിക്കുന്ന ഒരുതരം പരിധി മൂല്യമുണ്ട്.

അതിനെക്കുറിച്ച് നിങ്ങൾക്ക് എന്തു ചെയ്യാൻ കഴിയും? ഇവിടെ, തീർച്ചയായും, എന്തെങ്കിലും അനുമാനിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്. ഞങ്ങൾ ഉപയോഗിക്കുന്ന ഒരു ലളിതമായ പരിഹാരമുണ്ട്. ഇത് +0 ആണ്, OFFSET 0. തീർച്ചയായും നിങ്ങൾക്ക് അത്തരം പരിഹാരങ്ങൾ അറിയാം. ഞങ്ങൾ അത് എടുത്ത് അഭ്യർത്ഥനയിലേക്ക് “+0” ചേർക്കുക, എല്ലാം ശരിയാണ്. ഞാൻ പിന്നീട് കാണിച്ചുതരാം.

മറ്റൊരു ഓപ്ഷൻ ഉണ്ട് - പദ്ധതികൾ കൂടുതൽ ശ്രദ്ധയോടെ നോക്കുക. ഡെവലപ്പർ ഒരു അഭ്യർത്ഥന എഴുതുക മാത്രമല്ല, "വിശദീകരിക്കുക വിശകലനം ചെയ്യുക" എന്ന് 6 തവണ പറയുകയും വേണം. ഇത് 5 ആണെങ്കിൽ, അത് പ്രവർത്തിക്കില്ല.

മൂന്നാമതൊരു ഓപ്ഷൻ ഉണ്ട് - pgsql-ഹാക്കർമാർക്ക് ഒരു കത്ത് എഴുതുക. ഞാൻ എഴുതി, എന്നിരുന്നാലും, ഇതൊരു ബഗ് ആണോ ഫീച്ചർ ആണോ എന്ന് ഇതുവരെ വ്യക്തമല്ല.

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

ഇതൊരു ബഗ്ഗാണോ അതോ ഫീച്ചറാണോ എന്ന് നമ്മൾ ചിന്തിക്കുമ്പോൾ, നമുക്ക് ഇത് പരിഹരിക്കാം. നമുക്ക് നമ്മുടെ അഭ്യർത്ഥന എടുത്ത് "+0" ചേർക്കാം. എല്ലാം നന്നായി. രണ്ട് ചിഹ്നങ്ങൾ, അത് എങ്ങനെയാണെന്നോ എന്താണെന്നോ നിങ്ങൾ ചിന്തിക്കേണ്ടതില്ല. വളരെ ലളിതം. ഈ കോളത്തിൽ ഒരു സൂചിക ഉപയോഗിക്കുന്നതിൽ നിന്ന് ഞങ്ങൾ ഡാറ്റാബേസിനെ വിലക്കി. "+0" നിരയിൽ ഞങ്ങൾക്ക് ഒരു സൂചിക ഇല്ല, അത്രയേയുള്ളൂ, ഡാറ്റാബേസ് സൂചിക ഉപയോഗിക്കുന്നില്ല, എല്ലാം ശരിയാണ്.

ഇതാണ് 6-ന്റെ നിയമം വിശദീകരിക്കുക. ഇപ്പോൾ നിലവിലുള്ള പതിപ്പുകളിൽ നിങ്ങൾക്ക് ബൗണ്ട് വേരിയബിളുകൾ ഉണ്ടെങ്കിൽ 6 തവണ ചെയ്യണം. നിങ്ങൾക്ക് ബന്ധിത വേരിയബിളുകൾ ഇല്ലെങ്കിൽ, ഇതാണ് ഞങ്ങൾ ചെയ്യുന്നത്. അവസാനം ഈ അഭ്യർത്ഥനയാണ് പരാജയപ്പെടുന്നത്. അതൊരു ചങ്കൂറ്റമുള്ള കാര്യമല്ല.

എത്രത്തോളം സാധ്യമാണെന്ന് തോന്നുന്നു? ഇവിടെ ഒരു ബഗ്, അവിടെ ഒരു ബഗ്. യഥാർത്ഥത്തിൽ, ബഗ് എല്ലായിടത്തും ഉണ്ട്.

നമുക്ക് സൂക്ഷ്മമായി നോക്കാം. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് രണ്ട് സ്കീമകളുണ്ട്. പട്ടിക എസ് ഉള്ള സ്കീം എ, പട്ടിക എസ് ഉള്ള ഡയഗ്രം ബി. ചോദ്യം - ഒരു പട്ടികയിൽ നിന്ന് ഡാറ്റ തിരഞ്ഞെടുക്കുക. ഈ സാഹചര്യത്തിൽ നമുക്ക് എന്ത് ലഭിക്കും? ഞങ്ങൾക്ക് ഒരു പിശക് ഉണ്ടാകും. മുകളിൽ പറഞ്ഞവയെല്ലാം നമുക്ക് ലഭിക്കും. നിയമം ഇതാണ് - എല്ലായിടത്തും ഒരു ബഗ് ഉണ്ട്, മുകളിൽ പറഞ്ഞവയെല്ലാം നമുക്കുണ്ടാകും.

ഇപ്പോൾ ചോദ്യം ഇതാണ്: "എന്തുകൊണ്ട്?" ഞങ്ങൾക്ക് ഒരു സ്കീമ ഉണ്ടെങ്കിൽ, പട്ടിക എവിടെയാണ് തിരയേണ്ടതെന്ന് പറയുന്ന ഒരു "സെർച്ച്_പാത്ത്" വേരിയബിൾ ഉണ്ടെന്ന് ഡോക്യുമെന്റേഷൻ ഉണ്ടെന്ന് തോന്നുന്നു. ഒരു വേരിയബിൾ ഉണ്ടെന്ന് തോന്നുന്നു.

എന്താണ് പ്രശ്നം? സെർവർ തയ്യാറാക്കിയ പ്രസ്താവനകൾ ആരെങ്കിലും തിരയൽ_പാത്ത് മാറ്റാൻ കഴിയുമെന്ന് സംശയിക്കുന്നില്ല എന്നതാണ് പ്രശ്നം. ഈ മൂല്യം ഡാറ്റാബേസിനായി സ്ഥിരമായി തുടരുന്നു. ചില ഭാഗങ്ങൾ പുതിയ അർത്ഥങ്ങൾ എടുത്തേക്കില്ല.

തീർച്ചയായും, ഇത് നിങ്ങൾ പരീക്ഷിക്കുന്ന പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു. നിങ്ങളുടെ പട്ടികകൾ എത്രത്തോളം വ്യത്യാസപ്പെട്ടിരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. കൂടാതെ പതിപ്പ് 9.1 പഴയ അന്വേഷണങ്ങൾ ലളിതമായി നടപ്പിലാക്കും. പുതിയ പതിപ്പുകൾ ബഗ് പിടിക്കുകയും നിങ്ങൾക്ക് ഒരു ബഗ് ഉണ്ടെന്ന് പറയുകയും ചെയ്തേക്കാം.

സെർച്ച്_പാത്ത് + സെർവർ തയ്യാറാക്കിയ പ്രസ്താവനകൾ = സജ്ജമാക്കുക
കാഷെ ചെയ്ത പ്ലാൻ ഫല തരം മാറ്റാൻ പാടില്ല

എങ്ങനെ ചികിത്സിക്കാം? ഒരു ലളിതമായ പാചകക്കുറിപ്പ് ഉണ്ട് - അത് ചെയ്യരുത്. ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുമ്പോൾ തിരയൽ_പാത്ത് മാറ്റേണ്ട ആവശ്യമില്ല. നിങ്ങൾ മാറുകയാണെങ്കിൽ, ഒരു പുതിയ കണക്ഷൻ സൃഷ്ടിക്കുന്നതാണ് നല്ലത്.

നിങ്ങൾക്ക് ചർച്ച ചെയ്യാം, അതായത് തുറക്കുക, ചർച്ച ചെയ്യുക, ചേർക്കുക. ആരെങ്കിലും ഒരു മൂല്യം മാറ്റുമ്പോൾ, ഡാറ്റാബേസ് ഇതിനെക്കുറിച്ച് ക്ലയന്റിനോട് പറയണമെന്ന് ഡാറ്റാബേസ് ഡെവലപ്പർമാരെ ഞങ്ങൾക്ക് ബോധ്യപ്പെടുത്താൻ കഴിയും: “നോക്കൂ, നിങ്ങളുടെ മൂല്യം ഇവിടെ അപ്‌ഡേറ്റ് ചെയ്‌തു. ഒരുപക്ഷേ നിങ്ങൾ പ്രസ്താവനകൾ പുനഃസജ്ജീകരിച്ച് അവ പുനഃസൃഷ്ടിക്കേണ്ടതുണ്ടോ? ഇപ്പോൾ ഡാറ്റാബേസ് രഹസ്യമായി പെരുമാറുന്നു, പ്രസ്താവനകൾ ഉള്ളിൽ എവിടെയോ മാറിയതായി ഒരു തരത്തിലും റിപ്പോർട്ട് ചെയ്യുന്നില്ല.

ഞാൻ വീണ്ടും ഊന്നിപ്പറയുന്നു - ഇത് ജാവയ്ക്ക് സാധാരണമല്ലാത്ത ഒരു കാര്യമാണ്. PL/pgSQL ഒന്ന് മുതൽ ഒന്ന് വരെ നമ്മൾ ഇതേ കാര്യം കാണും. എന്നാൽ അത് അവിടെ പുനർനിർമ്മിക്കും.

നമുക്ക് കുറച്ച് ഡാറ്റ തിരഞ്ഞെടുക്കാൻ ശ്രമിക്കാം. ഞങ്ങൾ തിരഞ്ഞെടുക്കുകയും തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു. ഞങ്ങൾക്ക് ഒരു ദശലക്ഷം വരികളുള്ള ഒരു മേശയുണ്ട്. ഓരോ വരിയും ഒരു കിലോബൈറ്റ് ആണ്. ഏകദേശം ഒരു ജിഗാബൈറ്റ് ഡാറ്റ. 128 മെഗാബൈറ്റിന്റെ ജാവ മെഷീനിൽ ഞങ്ങൾക്ക് പ്രവർത്തന മെമ്മറിയുണ്ട്.

ഞങ്ങൾ, എല്ലാ പുസ്തകങ്ങളിലും ശുപാർശ ചെയ്യുന്നതുപോലെ, സ്ട്രീം പ്രോസസ്സിംഗ് ഉപയോഗിക്കുന്നു. അതായത്, ഞങ്ങൾ റിസൾട്ട് സെറ്റ് തുറന്ന് അവിടെ നിന്നുള്ള ഡാറ്റ കുറച്ച് കുറച്ച് വായിക്കുന്നു. ഇത് പ്രവർത്തിക്കുമോ? ഓർമ്മയിൽ നിന്ന് വീഴുമോ? കുറച്ചു വായിക്കുമോ? നമുക്ക് ഡാറ്റാബേസിൽ വിശ്വസിക്കാം, നമുക്ക് പോസ്റ്റ്ഗ്രെസിൽ വിശ്വസിക്കാം. ഞങ്ങൾ അത് വിശ്വസിക്കുന്നില്ല. നമ്മൾ ഔട്ട്ഓഫ് മെമ്മറിയിൽ വീഴുമോ? ആരാണ് OutOfMemory അനുഭവിച്ചത്? അതിനു ശേഷം ആരാണ് ശരിയാക്കിയത്? അത് ശരിയാക്കാൻ ഒരാൾക്ക് കഴിഞ്ഞു.

നിങ്ങൾക്ക് ഒരു ദശലക്ഷം വരികൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാനും തിരഞ്ഞെടുക്കാനും കഴിയില്ല. OFFSET/LIMIT ആവശ്യമാണ്. ഈ ഓപ്ഷന് ആരാണ്? ഓട്ടോകമ്മിറ്റിനൊപ്പം കളിക്കുന്നതിനെ ആരാണ് അനുകൂലിക്കുന്നത്?

ഇവിടെ, പതിവുപോലെ, ഏറ്റവും അപ്രതീക്ഷിതമായ ഓപ്ഷൻ ശരിയായതായി മാറുന്നു. നിങ്ങൾ പെട്ടെന്ന് ഓട്ടോകമ്മിറ്റ് ഓഫാക്കുകയാണെങ്കിൽ, അത് സഹായിക്കും. എന്തുകൊണ്ടാണത്? ശാസ്ത്രത്തിന് ഇതിനെക്കുറിച്ച് അറിയില്ല.

എന്നാൽ സ്ഥിരസ്ഥിതിയായി, ഒരു Postgres ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്യുന്ന എല്ലാ ക്ലയന്റുകളും മുഴുവൻ ഡാറ്റയും ലഭ്യമാക്കുന്നു. PgJDBC ഇക്കാര്യത്തിൽ ഒരു അപവാദമല്ല; അത് എല്ലാ വരികളും തിരഞ്ഞെടുക്കുന്നു.

FetchSize തീമിൽ ഒരു വ്യതിയാനമുണ്ട്, അതായത്, ഒരു പ്രത്യേക പ്രസ്താവനയുടെ തലത്തിൽ നിങ്ങൾക്ക് ഇവിടെ പറയാനാകും, ദയവായി 10, 50 പ്രകാരം ഡാറ്റ തിരഞ്ഞെടുക്കുക. എന്നാൽ നിങ്ങൾ ഓട്ടോകമ്മിറ്റ് ഓഫാക്കുന്നതുവരെ ഇത് പ്രവർത്തിക്കില്ല. ഓട്ടോകമ്മിറ്റ് ഓഫാക്കി - ഇത് പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു.

എന്നാൽ കോഡ് പരിശോധിച്ച് എല്ലായിടത്തും setFetchSize സജ്ജീകരിക്കുന്നത് അസൗകര്യമാണ്. അതിനാൽ, മുഴുവൻ കണക്ഷനുമുള്ള ഡിഫോൾട്ട് മൂല്യം പറയുന്ന ഒരു ക്രമീകരണം ഞങ്ങൾ ഉണ്ടാക്കി.

അതാണ് ഞങ്ങൾ പറഞ്ഞത്. പരാമീറ്റർ ക്രമീകരിച്ചു. പിന്നെ നമുക്ക് എന്ത് കിട്ടി? ഞങ്ങൾ ചെറിയ തുകകൾ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, ഞങ്ങൾ ഒരു സമയം 10 ​​വരികൾ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് വളരെ വലിയ ഓവർഹെഡ് ചെലവുകൾ ഉണ്ടാകും. അതിനാൽ, ഈ മൂല്യം ഏകദേശം നൂറായി സജ്ജീകരിക്കണം.

എബൌട്ട്, തീർച്ചയായും, ബൈറ്റുകളിൽ ഇത് എങ്ങനെ പരിമിതപ്പെടുത്താമെന്ന് നിങ്ങൾ ഇപ്പോഴും പഠിക്കേണ്ടതുണ്ട്, എന്നാൽ പാചകക്കുറിപ്പ് ഇതാണ്: defaultRowFetchSize നൂറിലധികം ആയി സജ്ജീകരിച്ച് സന്തോഷവാനായിരിക്കുക.

നമുക്ക് ഡാറ്റ ചേർക്കുന്നതിലേക്ക് പോകാം. ഉൾപ്പെടുത്തൽ എളുപ്പമാണ്, വ്യത്യസ്ത ഓപ്ഷനുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, INSERT, VALUES. ഇതൊരു നല്ല ഓപ്ഷനാണ്. "തിരഞ്ഞെടുക്കുക ചേർക്കുക" എന്ന് നിങ്ങൾക്ക് പറയാം. പ്രായോഗികമായി അത് ഒന്നുതന്നെയാണ്. പ്രകടനത്തിൽ വ്യത്യാസമില്ല.

നിങ്ങൾ ഒരു ബാച്ച് സ്റ്റേറ്റ്മെന്റ് എക്സിക്യൂട്ട് ചെയ്യണമെന്ന് പുസ്തകങ്ങൾ പറയുന്നു, നിരവധി പരാൻതീസിസുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് കൂടുതൽ സങ്കീർണ്ണമായ കമാൻഡുകൾ എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയുമെന്ന് പുസ്തകങ്ങൾ പറയുന്നു. കൂടാതെ പോസ്റ്റ്‌ഗ്രേസിന് അതിശയകരമായ ഒരു സവിശേഷതയുണ്ട് - നിങ്ങൾക്ക് COPY ചെയ്യാൻ കഴിയും, അതായത് അത് വേഗത്തിൽ ചെയ്യുക.

നിങ്ങൾ അത് അളക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് വീണ്ടും രസകരമായ ചില കണ്ടെത്തലുകൾ നടത്താൻ കഴിയും. ഇത് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു? അനാവശ്യ കമാൻഡുകൾ പാഴ്‌സ് ചെയ്യരുതെന്നും എക്സിക്യൂട്ട് ചെയ്യരുതെന്നും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

പ്രായോഗികമായി, ഇത് ചെയ്യാൻ ടിസിപി ഞങ്ങളെ അനുവദിക്കുന്നില്ല. ക്ലയന്റ് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്ന തിരക്കിലാണെങ്കിൽ, ഞങ്ങൾക്ക് പ്രതികരണങ്ങൾ അയയ്‌ക്കാനുള്ള ശ്രമങ്ങളിൽ ഡാറ്റാബേസ് അഭ്യർത്ഥനകൾ വായിക്കില്ല. അഭ്യർത്ഥന വായിക്കാൻ ക്ലയന്റ് ഡാറ്റാബേസിനായി കാത്തിരിക്കുന്നു, കൂടാതെ ക്ലയന്റ് പ്രതികരണം വായിക്കുന്നതിനായി ഡാറ്റാബേസ് കാത്തിരിക്കുന്നു എന്നതാണ് അന്തിമഫലം.

അതിനാൽ ഇടയ്ക്കിടെ ഒരു സിൻക്രൊണൈസേഷൻ പാക്കറ്റ് അയയ്ക്കാൻ ക്ലയന്റ് നിർബന്ധിതനാകുന്നു. അധിക നെറ്റ്‌വർക്ക് ഇടപെടലുകൾ, അധിക സമയം പാഴാക്കുക.

നമ്മൾ അവരെ കൂടുതൽ ചേർക്കുന്തോറും അത് കൂടുതൽ വഷളാകുന്നു. ഡ്രൈവർ തികച്ചും അശുഭാപ്തിവിശ്വാസിയാണ്, കൂടാതെ ലൈനുകളുടെ വലുപ്പം മുതലായവയെ ആശ്രയിച്ച് ഓരോ 200 വരികളിലും ഒരിക്കൽ അവ ചേർക്കുന്നു.

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

നിങ്ങൾ ഒരു വരി മാത്രം ശരിയാക്കുകയും എല്ലാം 10 മടങ്ങ് വേഗത്തിലാക്കുകയും ചെയ്യും. അത് സംഭവിക്കുന്നു. എന്തുകൊണ്ട്? പതിവുപോലെ, ഇതുപോലുള്ള ഒരു സ്ഥിരാങ്കം ഇതിനകം എവിടെയോ ഉപയോഗിച്ചിട്ടുണ്ട്. "128" എന്ന മൂല്യം ബാച്ചിംഗ് ഉപയോഗിക്കരുതെന്നാണ് അർത്ഥമാക്കുന്നത്.

ജാവ മൈക്രോബെഞ്ച്മാർക്ക് ഹാർനെസ്

ഇത് ഔദ്യോഗിക പതിപ്പിൽ ഉൾപ്പെടുത്താതിരുന്നത് നന്നായി. റിലീസ് തുടങ്ങുന്നതിന് മുമ്പ് കണ്ടെത്തി. ഞാൻ നൽകുന്ന എല്ലാ അർത്ഥങ്ങളും ആധുനിക പതിപ്പുകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

നമുക്ക് അത് പരീക്ഷിക്കാം. ഞങ്ങൾ InsertBatch ലളിതമായി അളക്കുന്നു. ഞങ്ങൾ InsertBatch ഒന്നിലധികം തവണ അളക്കുന്നു, അതായത് ഒരേ കാര്യം, എന്നാൽ നിരവധി മൂല്യങ്ങളുണ്ട്. തന്ത്രപരമായ നീക്കം. എല്ലാവർക്കും ഇത് ചെയ്യാൻ കഴിയില്ല, എന്നാൽ ഇത് വളരെ ലളിതമായ ഒരു നീക്കമാണ്, പകർപ്പിനേക്കാൾ വളരെ എളുപ്പമാണ്.

നിങ്ങൾക്ക് COPY ചെയ്യാം.

നിങ്ങൾക്ക് ഇത് ഘടനകളിൽ ചെയ്യാൻ കഴിയും. ഉപയോക്തൃ ഡിഫോൾട്ട് തരം പ്രഖ്യാപിക്കുക, അറേ പാസ്സ് ചെയ്യുക, പട്ടികയിലേക്ക് നേരിട്ട് ചേർക്കുക.

നിങ്ങൾ ലിങ്ക് തുറക്കുകയാണെങ്കിൽ: pgjdbc/ubenchmsrk/InsertBatch.java, ഈ കോഡ് GitHub-ലാണ്. എന്തെല്ലാം അഭ്യർത്ഥനകളാണ് അവിടെ ജനറേറ്റുചെയ്യുന്നതെന്ന് നിങ്ങൾക്ക് പ്രത്യേകം കാണാൻ കഴിയും. സാരമില്ല.

ഞങ്ങൾ ലോഞ്ച് ചെയ്തു. ബാച്ച് ഉപയോഗിക്കാതിരിക്കുന്നത് അസാധ്യമാണെന്ന് ഞങ്ങൾ ആദ്യം മനസ്സിലാക്കി. എല്ലാ ബാച്ചിംഗ് ഓപ്ഷനുകളും പൂജ്യമാണ്, അതായത് ഒറ്റത്തവണ നിർവ്വഹണവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ എക്സിക്യൂഷൻ സമയം പ്രായോഗികമായി പൂജ്യമാണ്.

ഞങ്ങൾ ഡാറ്റ ചേർക്കുന്നു. വളരെ ലളിതമായ ഒരു മേശയാണ്. മൂന്ന് നിരകൾ. പിന്നെ നമ്മൾ ഇവിടെ എന്താണ് കാണുന്നത്? ഈ മൂന്ന് ഓപ്ഷനുകളും ഏകദേശം താരതമ്യപ്പെടുത്താവുന്നതാണെന്ന് ഞങ്ങൾ കാണുന്നു. കൂടാതെ, പകർപ്പ് തീർച്ചയായും മികച്ചതാണ്.

ഞങ്ങൾ കഷണങ്ങൾ തിരുകുമ്പോഴാണ് ഇത്. ഒരു VALUES മൂല്യം, രണ്ട് മൂല്യങ്ങൾ, മൂന്ന് മൂല്യങ്ങൾ, അല്ലെങ്കിൽ കോമ കൊണ്ട് വേർതിരിച്ച 10 എണ്ണം ഞങ്ങൾ സൂചിപ്പിച്ചു. ഇത് ഇപ്പോൾ തിരശ്ചീനമാണ്. 1, 2, 4, 128. നീല നിറത്തിൽ വരച്ചിരിക്കുന്ന ബാച്ച് ഇൻസേർട്ട് അവനെ വളരെയധികം സുഖപ്പെടുത്തുന്നതായി കാണാം. അതായത്, നിങ്ങൾ ഒരു സമയം ഒന്ന് തിരുകുമ്പോൾ അല്ലെങ്കിൽ ഒരു സമയം നാലെണ്ണം തിരുകുമ്പോൾ പോലും, അത് രണ്ട് മടങ്ങ് മികച്ചതായിത്തീരുന്നു, കാരണം ഞങ്ങൾ മൂല്യങ്ങളിൽ കുറച്ചുകൂടി ഞെരുങ്ങി. കുറച്ച് EXECUTE പ്രവർത്തനങ്ങൾ.

ചെറിയ വോള്യങ്ങളിൽ പകർപ്പ് ഉപയോഗിക്കുന്നത് തീർത്തും വിട്ടുവീഴ്ചയില്ലാത്തതാണ്. ആദ്യ രണ്ടിലും ഞാൻ വരച്ചില്ല. അവർ സ്വർഗത്തിലേക്ക് പോകുന്നു, അതായത്, ഈ പച്ച നമ്പറുകൾ പകർപ്പിനായി.

നിങ്ങൾക്ക് കുറഞ്ഞത് നൂറ് വരി ഡാറ്റയെങ്കിലും ഉള്ളപ്പോൾ COPY ഉപയോഗിക്കണം. ഈ കണക്ഷൻ തുറക്കുന്നതിനുള്ള ഓവർഹെഡ് വലുതാണ്. കൂടാതെ, സത്യം പറഞ്ഞാൽ, ഞാൻ ഈ ദിശയിൽ കുഴിച്ചില്ല. ഞാൻ ബാച്ച് ഒപ്റ്റിമൈസ് ചെയ്‌തു, പക്ഷേ പകർപ്പല്ല.

നമ്മൾ അടുത്തതായി എന്ത് ചെയ്യും? ഞങ്ങൾ അത് പരീക്ഷിച്ചു. ഒന്നുകിൽ ഘടനകൾ അല്ലെങ്കിൽ നിരവധി അർത്ഥങ്ങൾ സമന്വയിപ്പിക്കുന്ന ഒരു ബുദ്ധിമാനായ ബാക്ക് ഉപയോഗിക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു.

ഇന്നത്തെ റിപ്പോർട്ടിൽ നിന്ന് നിങ്ങൾ എന്താണ് എടുക്കേണ്ടത്?

• തയ്യാറാക്കിയ പ്രസ്താവനയാണ് നമ്മുടെ എല്ലാം. ഇത് ഉൽപ്പാദനക്ഷമതയ്ക്ക് ധാരാളം നൽകുന്നു. ഇത് തൈലത്തിൽ ഒരു വലിയ ഫ്ലോപ്പ് ഉണ്ടാക്കുന്നു.
• കൂടാതെ നിങ്ങൾ 6 തവണ EXPLAIN ANYZE ചെയ്യേണ്ടതുണ്ട്.
• ഞങ്ങളുടെ പ്രശ്‌നകരമായ ചോദ്യങ്ങളുടെ ശേഷിക്കുന്ന ശതമാനം ശരിയാക്കാൻ OFFSET 0 ഉം +0 പോലുള്ള തന്ത്രങ്ങളും നേർപ്പിക്കേണ്ടതുണ്ട്.

അവലംബം: www.habr.com