ഞങ്ങൾ സബ്‌ലൈറ്റിൽ PostgreSQL-ൽ എഴുതുന്നു: 1 ഹോസ്റ്റ്, 1 ദിവസം, 1TB

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

#1. സെക്ഷനിംഗ്

എങ്ങനെ, എന്തുകൊണ്ട് ഇത് സംഘടിപ്പിക്കുന്നത് മൂല്യവത്താണ് എന്നതിനെക്കുറിച്ചുള്ള ഒരു ലേഖനം പ്രയോഗിച്ച പാർട്ടീഷനിംഗ് "സിദ്ധാന്തത്തിൽ" ഇതിനകം ഉണ്ടായിട്ടുണ്ട്, ഇവിടെ നമ്മുടെ ഉള്ളിൽ ചില സമീപനങ്ങൾ പ്രയോഗിക്കുന്ന രീതിയെക്കുറിച്ച് സംസാരിക്കും നൂറുകണക്കിന് PostgreSQL സെർവറുകളുടെ നിരീക്ഷണ സേവനം.

"നാളുകൾ പിന്നിട്ട കാര്യങ്ങൾ..."

തുടക്കത്തിൽ, ഏതൊരു എംവിപിയെയും പോലെ, ഞങ്ങളുടെ പ്രോജക്റ്റ് വളരെ കുറഞ്ഞ ലോഡിലാണ് ആരംഭിച്ചത് - ഏറ്റവും നിർണായകമായ പത്ത് സെർവറുകളിൽ മാത്രമാണ് നിരീക്ഷണം നടത്തിയത്, എല്ലാ ടേബിളുകളും താരതമ്യേന ഒതുക്കമുള്ളവയായിരുന്നു... എന്നാൽ സമയം കടന്നുപോകുന്തോറും നിരീക്ഷിക്കപ്പെടുന്ന ഹോസ്റ്റുകളുടെ എണ്ണം കൂടിക്കൊണ്ടിരുന്നു. , ഒരിക്കൽ കൂടി ഞങ്ങൾ ഒരാളുമായി എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിച്ചു 1.5TB വലിപ്പമുള്ള പട്ടികകൾ, ഇങ്ങനെ ജീവിതം തുടരാൻ പറ്റുമെങ്കിലും അത് വളരെ അസൗകര്യമാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.

സമയങ്ങൾ ഏതാണ്ട് ഇതിഹാസ സമയങ്ങൾ പോലെയായിരുന്നു, PostgreSQL 9.x-ന്റെ വ്യത്യസ്ത പതിപ്പുകൾ പ്രസക്തമായിരുന്നു, അതിനാൽ എല്ലാ പാർട്ടീഷനുകളും "മാനുവലായി" ചെയ്യേണ്ടതുണ്ട് - വഴി പട്ടിക പാരമ്പര്യവും ട്രിഗറുകളും ഡൈനാമിക് ഉപയോഗിച്ച് റൂട്ടിംഗ് EXECUTE.

തത്ഫലമായുണ്ടാകുന്ന പരിഹാരം എല്ലാ പട്ടികകളിലേക്കും വിവർത്തനം ചെയ്യാൻ കഴിയുന്നത്ര സാർവത്രികമായി മാറി:

• ഒരു ശൂന്യമായ "ഹെഡർ" പേരന്റ് ടേബിൾ പ്രഖ്യാപിച്ചു, അത് എല്ലാം വിവരിച്ചു ആവശ്യമായ സൂചികകളും ട്രിഗറുകളും.
• ഉപഭോക്താവിന്റെ വീക്ഷണകോണിൽ നിന്നുള്ള റെക്കോർഡ് "റൂട്ട്" പട്ടികയിൽ ഉണ്ടാക്കി, ആന്തരികമായി ഉപയോഗിക്കുന്നു റൂട്ടിംഗ് ട്രിഗർ BEFORE INSERT ആവശ്യമായ വിഭാഗത്തിൽ റെക്കോർഡ് "ശാരീരികമായി" ചേർത്തു. ഇതുവരെ അങ്ങനെയൊന്നും ഇല്ലെങ്കിൽ, ഞങ്ങൾ ഒരു അപവാദം കണ്ടെത്തി...
• … ഉപയോഗിച്ച് CREATE TABLE ... (LIKE ... INCLUDING ...) പാരന്റ് ടേബിളിന്റെ ടെംപ്ലേറ്റിനെ അടിസ്ഥാനമാക്കി സൃഷ്ടിച്ചതാണ് ആവശ്യമുള്ള തീയതിയിൽ നിയന്ത്രണമുള്ള വിഭാഗംഅതിനാൽ ഡാറ്റ വീണ്ടെടുക്കുമ്പോൾ, അതിൽ മാത്രമേ വായന നടത്തൂ.

PG10: ആദ്യ ശ്രമം

എന്നാൽ പാരമ്പര്യത്തിലൂടെയുള്ള വിഭജനം ചരിത്രപരമായി സജീവമായ ഒരു എഴുത്ത് സ്ട്രീം അല്ലെങ്കിൽ ധാരാളം ചൈൽഡ് പാർട്ടീഷനുകൾ കൈകാര്യം ചെയ്യുന്നതിന് അനുയോജ്യമല്ല. ഉദാഹരണത്തിന്, ആവശ്യമായ വിഭാഗം തിരഞ്ഞെടുക്കുന്നതിനുള്ള അൽഗോരിതം ഉണ്ടായിരുന്നതായി നിങ്ങൾക്ക് ഓർക്കാം ചതുരാകൃതിയിലുള്ള സങ്കീർണ്ണത, ഇത് 100+ വിഭാഗങ്ങളിൽ പ്രവർത്തിക്കുന്നു, എങ്ങനെയെന്ന് നിങ്ങൾ തന്നെ മനസ്സിലാക്കുന്നു...

PG10-ൽ പിന്തുണ നടപ്പിലാക്കുന്നതിലൂടെ ഈ സാഹചര്യം വളരെയധികം ഒപ്റ്റിമൈസ് ചെയ്തു നേറ്റീവ് പാർട്ടീഷനിംഗ്. അതിനാൽ, സംഭരണം മൈഗ്രേറ്റ് ചെയ്‌ത ഉടൻ തന്നെ ഇത് പ്രയോഗിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു, പക്ഷേ...

മാനുവൽ കുഴിച്ചതിനുശേഷം, ഈ പതിപ്പിലെ നേറ്റീവ് പാർട്ടീഷൻ ചെയ്ത പട്ടിക ഇതാണ്:

• സൂചിക വിവരണങ്ങളെ പിന്തുണയ്ക്കുന്നില്ല
• അതിലെ ട്രിഗറുകൾ പിന്തുണയ്ക്കുന്നില്ല
• ആരുടെയും "സന്തതി" ആകാൻ കഴിയില്ല
• പിന്തുണയ്ക്കരുത് INSERT ... ON CONFLICT
• ഒരു വിഭാഗം സ്വയമേവ സൃഷ്ടിക്കാൻ കഴിയില്ല

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

PG10: രണ്ടാമത്തെ അവസരം

അതിനാൽ, ഉയർന്നുവന്ന പ്രശ്നങ്ങൾ ഓരോന്നായി ഞങ്ങൾ പരിഹരിക്കാൻ തുടങ്ങി:

1. കാരണം ട്രിഗറുകളും ON CONFLICT ഞങ്ങൾക്ക് അവ ഇപ്പോഴും അവിടെയും ഇവിടെയും ആവശ്യമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി, അതിനാൽ അവ പരിഹരിക്കുന്നതിന് ഞങ്ങൾ ഒരു ഇന്റർമീഡിയറ്റ് ഘട്ടം ഉണ്ടാക്കി പ്രോക്സി ടേബിൾ.
2. "റൂട്ടിംഗ്" ഒഴിവാക്കി ട്രിഗറുകളിൽ - അതായത്, മുതൽ EXECUTE.
3. അവർ അത് പ്രത്യേകം എടുത്തു എല്ലാ സൂചികകളുമുള്ള ടെംപ്ലേറ്റ് പട്ടികഅതിനാൽ അവ പ്രോക്സി ടേബിളിൽ പോലും ഇല്ല.

അവസാനം, ഇതെല്ലാം കഴിഞ്ഞ്, ഞങ്ങൾ പ്രധാന പട്ടിക നേറ്റീവ് ആയി വിഭജിച്ചു. ഒരു പുതിയ വിഭാഗം സൃഷ്ടിക്കുന്നത് ഇപ്പോഴും ആപ്ലിക്കേഷന്റെ മനസ്സാക്ഷിക്ക് വിട്ടിരിക്കുന്നു.

"സോവിംഗ്" നിഘണ്ടുക്കൾ

ഏതൊരു വിശകലന സംവിധാനത്തിലെയും പോലെ, ഞങ്ങൾക്കും ഉണ്ടായിരുന്നു "വസ്തുതകൾ", "വെട്ടലുകൾ" (നിഘണ്ടുക്കൾ). ഞങ്ങളുടെ കാര്യത്തിൽ, ഈ ശേഷിയിൽ അവർ പ്രവർത്തിച്ചു, ഉദാഹരണത്തിന്, ടെംപ്ലേറ്റ് ബോഡി സമാനമായ മന്ദഗതിയിലുള്ള ചോദ്യങ്ങൾ അല്ലെങ്കിൽ ചോദ്യത്തിന്റെ വാചകം.

“വസ്തുതകൾ” വളരെക്കാലമായി പകൽ തോറും വിഭജിച്ചിരിക്കുന്നു, അതിനാൽ കാലഹരണപ്പെട്ട വിഭാഗങ്ങൾ ഞങ്ങൾ ശാന്തമായി ഇല്ലാതാക്കി, അവ ഞങ്ങളെ ശല്യപ്പെടുത്തിയില്ല (ലോഗുകൾ!). എന്നാൽ നിഘണ്ടുവിൽ ഒരു പ്രശ്നമുണ്ടായിരുന്നു...

അവയിൽ ധാരാളം ഉണ്ടെന്ന് പറയേണ്ടതില്ല, പക്ഷേ ഏകദേശം 100TB "വസ്തുതകൾ" 2.5TB നിഘണ്ടുവിന് കാരണമായി. അത്തരമൊരു പട്ടികയിൽ നിന്ന് നിങ്ങൾക്ക് സൗകര്യപ്രദമായി ഒന്നും ഇല്ലാതാക്കാൻ കഴിയില്ല, നിങ്ങൾക്ക് അത് മതിയായ സമയത്ത് കംപ്രസ് ചെയ്യാൻ കഴിയില്ല, അതിലേക്ക് എഴുതുന്നത് ക്രമേണ മന്ദഗതിയിലായി.

ഒരു നിഘണ്ടു പോലെ... അതിൽ, ഓരോ എൻട്രിയും കൃത്യമായി ഒരു പ്രാവശ്യം അവതരിപ്പിക്കണം... ഇത് ശരിയാണ്, പക്ഷേ!.. ആരും ഞങ്ങളെ തടയുന്നില്ല ഓരോ ദിവസത്തിനും ഒരു പ്രത്യേക നിഘണ്ടു! അതെ, ഇത് ഒരു നിശ്ചിത ആവർത്തനം കൊണ്ടുവരുന്നു, പക്ഷേ ഇത് അനുവദിക്കുന്നു:

• വേഗത്തിൽ എഴുതുക/വായിക്കുക ചെറിയ ഭാഗത്തിന്റെ വലിപ്പം കാരണം
• കുറഞ്ഞ മെമ്മറി ഉപഭോഗം കൂടുതൽ ഒതുക്കമുള്ള സൂചികകളിൽ പ്രവർത്തിക്കുന്നതിലൂടെ
• കുറച്ച് ഡാറ്റ സംഭരിക്കുക കാലഹരണപ്പെട്ടവ വേഗത്തിൽ നീക്കംചെയ്യാനുള്ള കഴിവ് കാരണം

നടപടികളുടെ മുഴുവൻ സങ്കീർണ്ണതയുടെയും ഫലമായി സിപിയു ലോഡ് ~30% കുറഞ്ഞു, ഡിസ്ക് ലോഡ് ~50% കുറഞ്ഞു:

അതേ സമയം, ഞങ്ങൾ ഡാറ്റാബേസിലേക്ക് അതേ കാര്യം തന്നെ എഴുതുന്നത് തുടർന്നു, കുറഞ്ഞ ലോഡ് ഉപയോഗിച്ച്.

#2. ഡാറ്റാബേസ് പരിണാമവും പുനർനിർമ്മാണവും

അങ്ങനെ ഉള്ളതിൽ ഞങ്ങൾ തീർപ്പാക്കി ഓരോ ദിവസത്തിനും അതിന്റേതായ വിഭാഗമുണ്ട് ഡാറ്റ ഉപയോഗിച്ച്. യഥാർത്ഥത്തിൽ, CHECK (dt = '2018-10-12'::date) — കൂടാതെ ഒരു പാർട്ടീഷനിംഗ് കീയും ഒരു പ്രത്യേക വിഭാഗത്തിൽ രേഖപ്പെടുത്തുന്നതിനുള്ള വ്യവസ്ഥയും ഉണ്ട്.

ഞങ്ങളുടെ സേവനത്തിലെ എല്ലാ റിപ്പോർട്ടുകളും ഒരു നിർദ്ദിഷ്‌ട തീയതിയുടെ പശ്ചാത്തലത്തിൽ നിർമ്മിച്ചിരിക്കുന്നതിനാൽ, "വിഭജനം ചെയ്യാത്ത സമയം" മുതലുള്ള സൂചികകൾ എല്ലാ തരത്തിലുമുള്ളതാണ് (സെർവർ, തീയതി, പ്ലാൻ ടെംപ്ലേറ്റ്), (സെർവർ, തീയതി, പ്ലാൻ നോഡ്), (തീയതി, പിശക് ക്ലാസ്, സെർവർ), ...

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

ഒപ്റ്റിമൈസേഷന്റെ ദിശ വ്യക്തമാണ് - ലളിതമാണ് എല്ലാ സൂചികകളിൽ നിന്നും തീയതി ഫീൽഡ് നീക്കം ചെയ്യുക വിഭജിച്ച പട്ടികകളിൽ. ഞങ്ങളുടെ വോള്യങ്ങൾ കണക്കിലെടുക്കുമ്പോൾ, നേട്ടം ഏകദേശം 1TB/ആഴ്ച!

ഇനി ഈ ടെറാബൈറ്റ് എങ്ങനെയെങ്കിലും റെക്കോർഡ് ചെയ്യേണ്ടി വന്നു എന്നത് ശ്രദ്ധിക്കാം. അതായത് ഞങ്ങളും ഡിസ്ക് ഇപ്പോൾ കുറച്ച് ലോഡ് ചെയ്യണം! ഞങ്ങൾ ഒരാഴ്ച നീക്കിവച്ച ക്ലീനിംഗിൽ നിന്ന് ലഭിച്ച പ്രഭാവം ഈ ചിത്രം വ്യക്തമായി കാണിക്കുന്നു:

#3. പീക്ക് ലോഡ് "സ്പ്രെഡിംഗ്"

ലോഡ് ചെയ്ത സിസ്റ്റങ്ങളുടെ വലിയ കുഴപ്പങ്ങളിലൊന്നാണ് അനാവശ്യമായ സമന്വയം ആവശ്യമില്ലാത്ത ചില പ്രവർത്തനങ്ങൾ. ചിലപ്പോൾ "അവർ ശ്രദ്ധിക്കാത്തതിനാൽ", ചിലപ്പോൾ "അത് എളുപ്പമായിരുന്നു", എന്നാൽ താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് നിങ്ങൾ അത് ഒഴിവാക്കണം.

മുമ്പത്തെ ചിത്രം സൂം ഇൻ ചെയ്‌ത് നമുക്ക് ഒരു ഡിസ്‌ക് ഉണ്ടെന്ന് നോക്കാം ഇരട്ട വ്യാപ്തിയുള്ള ലോഡിന് കീഴിൽ "പമ്പുകൾ" അടുത്തുള്ള സാമ്പിളുകൾക്കിടയിൽ, അത്തരം നിരവധി പ്രവർത്തനങ്ങളിൽ വ്യക്തമായി "സ്ഥിതിവിവരക്കണക്ക്" സംഭവിക്കരുത്:

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

setInterval(sendToDB, interval)

ഇവിടെ പ്രശ്നം കൃത്യമായി കിടക്കുന്നു എല്ലാ ത്രെഡുകളും ഏകദേശം ഒരേ സമയം ആരംഭിക്കുന്നു, അതിനാൽ അവരുടെ അയയ്‌ക്കുന്ന സമയം മിക്കവാറും എല്ലായ്‌പ്പോഴും "ബിന്ദുവിലേക്ക്" പൊരുത്തപ്പെടുന്നു. ശ്ശോ #2...

ഭാഗ്യവശാൽ, ഇത് പരിഹരിക്കാൻ വളരെ എളുപ്പമാണ്, ഒരു "റാൻഡം" റൺ-അപ്പ് ചേർക്കുന്നു സമയത്തിനനുസരിച്ച്:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. നമുക്ക് ആവശ്യമുള്ളത് ഞങ്ങൾ കാഷെ ചെയ്യുന്നു

മൂന്നാമത്തെ പരമ്പരാഗത ഹൈലോഡ് പ്രശ്നം കാഷെ ഇല്ല അവൻ എവിടെയാണ് കഴിയുമായിരുന്നു ആയിരിക്കും.

ഉദാഹരണത്തിന്, പ്ലാൻ നോഡുകളുടെ അടിസ്ഥാനത്തിൽ വിശകലനം ചെയ്യുന്നത് ഞങ്ങൾ സാധ്യമാക്കി (ഇവയെല്ലാം Seq Scan on users), എന്നാൽ ഉടനടി ചിന്തിക്കുക, അവർ മിക്കവാറും ഒന്നാണെന്ന് - അവർ മറന്നു.

ഇല്ല, തീർച്ചയായും, ഡാറ്റാബേസിലേക്ക് വീണ്ടും ഒന്നും എഴുതിയിട്ടില്ല, ഇത് ട്രിഗർ ഇല്ലാതാക്കുന്നു INSERT ... ON CONFLICT DO NOTHING. എന്നാൽ ഈ ഡാറ്റ ഇപ്പോഴും ഡാറ്റാബേസിൽ എത്തുന്നു, അത് അനാവശ്യമാണ് വൈരുദ്ധ്യം പരിശോധിക്കാൻ വായന ചെയ്യേണ്ടതുണ്ട്. ശ്ശോ #3...

കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പോ ശേഷമോ ഡാറ്റാബേസിലേക്ക് അയച്ച റെക്കോർഡുകളുടെ എണ്ണത്തിലെ വ്യത്യാസം വ്യക്തമാണ്:

സ്‌റ്റോറേജ് ലോഡിലെ ഡ്രോപ്പ് ഇതാണ്:

ആകെ

"ടെറാബൈറ്റ്-പെർ-ഡേ" എന്നത് ഭയപ്പെടുത്തുന്നതായി തോന്നുന്നു. നിങ്ങൾ എല്ലാം ശരിയായി ചെയ്യുകയാണെങ്കിൽ, ഇത് ന്യായമാണ് 2^40 ബൈറ്റുകൾ / 86400 സെക്കൻഡ് = ~12.5MB/sഡെസ്‌ക്‌ടോപ്പ് ഐഡിഇ സ്ക്രൂകൾ പോലും പിടിച്ചിരിക്കുന്നു. 🙂

എന്നാൽ ഗൗരവമായി, പകൽസമയത്ത് ലോഡ് ഒരു പത്തിരട്ടി "സ്കേവ്" ഉപയോഗിച്ച് പോലും, നിങ്ങൾക്ക് ആധുനിക എസ്എസ്ഡികളുടെ കഴിവുകൾ എളുപ്പത്തിൽ നേരിടാൻ കഴിയും.

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