ഡാറ്റാബേസുകൾക്ക് ബിൽ ചെയ്യുന്നത് അവ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്നതിന് അനുസരിച്ച്

ഡാറ്റ സൂക്ഷിക്കേണ്ട ഓരോ Mythex ആപ്പിനും സ്വന്തമായി ഒരു Postgres ഡാറ്റാബേസ് കിട്ടും, പ്രസിദ്ധീകരിച്ച ആപ്പിന്റെ ഡാറ്റാബേസ് ഉപയോഗം നിർമ്മാണത്തിന്റെ അതേ ക്രെഡിറ്റ് ബാലൻസിൽ നിന്നാണ് കുറയുന്നത്. സെപ്റ്റംബർ അവസാനം വരെ ഈ ഉപയോഗം ആപ്പിന്റെ സെർവർ എത്ര നേരം പ്രവർത്തിച്ചു എന്നതിൽ നിന്ന് ഞങ്ങൾ കണക്കാക്കുകയായിരുന്നു. ആ കണക്ക് പ്രധാനപ്പെട്ട രീതിയിൽ തെറ്റായി എന്ന് കണ്ടതിനാൽ അത് മാറ്റി: ഇപ്പോൾ ഓരോ ഡാറ്റാബേസും അതിന്റെ provider യഥാർത്ഥത്തിൽ അളന്ന കമ്പ്യൂട്ട് അനുസരിച്ച്, ഒരു പൂർത്തിയായ മണിക്കൂർ വീതം ബിൽ ചെയ്യുന്നു, ഓരോ മണിക്കൂറിനും ഒരിക്കൽ മാത്രമേ ചാർജ് ചെയ്യാൻ കഴിയൂ.

ഡാറ്റാബേസുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഓരോ ഡാറ്റാബേസും scales to zero ആയ serverless Postgres-ൽ പ്രവർത്തിക്കുന്നു: കുറച്ച് മിനിറ്റ് നിഷ്‌ക്രിയമായാൽ അത് ഉറങ്ങുന്നു, അടുത്ത query വന്നാൽ ഉണരുന്നു. ഉണർന്നിരിക്കുമ്പോൾ അതിന്റെ compute ലോഡിനനുസരിച്ച് കൂട്ടാനും കുറയ്ക്കാനും കഴിയും. "ഓരോ ആപ്പിനും ഒരു ഡാറ്റാബേസ്" എന്നത് താങ്ങാവുന്നതാക്കുന്നത് ഇതാണ് — മിക്ക ആപ്പുകളും മിക്കപ്പോഴും നിശബ്ദമാണ്, ഉറങ്ങുന്ന ഡാറ്റാബേസിന് ഏതാണ്ട് ചെലവൊന്നുമില്ല.

അതിനർത്ഥം ഡാറ്റാബേസിന്റെ ചെലവ് പുറമേ നിന്ന് നമുക്ക് കാണാൻ കഴിയാത്ത രണ്ട് കാര്യങ്ങളെ ആശ്രയിക്കുന്നു: അത് എത്ര നേരം ഉണർന്നിരുന്നു, ഉണർന്നിരുന്നപ്പോൾ അത് എത്ര വലുതായിരുന്നു.

കണക്ക് തെറ്റിയത് എവിടെ

ഞങ്ങളുടെ ആദ്യത്തെ മീറ്ററിന് ഒരു അനുമാനം ഉണ്ടായിരുന്നു: പ്രസിദ്ധീകരിച്ച ആപ്പിന്റെ സെർവർ പ്രവർത്തിച്ച ഓരോ മണിക്കൂറിനും, ഏറ്റവും ചെറിയ compute വലുപ്പത്തിൽ ഒരു ഡാറ്റാബേസിന് ചാർജ് ചെയ്യുക.

അത് മൂന്ന് വിധത്തിൽ തെറ്റായിരുന്നു:

1. വലുപ്പം തെറ്റായിരുന്നു. കണക്കിൽ കരുതിയതിനേക്കാൾ വലിയ സ്ഥിര വലുപ്പത്തിലാണ് ഡാറ്റാബേസുകൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിച്ചിരുന്നത്.
2. ഡാറ്റാബേസുകൾ സ്വയം സ്കെയിൽ ചെയ്യുന്നു. ലോഡ് വരുമ്പോൾ അവ വളരുന്നു, അത് കണക്ക് ഒരിക്കലും കണ്ടില്ല.
3. ഡാറ്റാബേസുകൾ ആപ്പ് സെർവറിനെ പിന്തുടരുന്നില്ല. ആപ്പ്, ഷെഡ്യൂൾ ചെയ്ത ജോലി, അല്ലെങ്കിൽ പതിവായി പരിശോധിക്കുന്ന ഒരു സ്ക്രിപ്റ്റ് — ആപ്പ് സെർവർ പ്രവർത്തിച്ചില്ലെങ്കിലും ആരെങ്കിലും ഡാറ്റാബേസിനെ query ചെയ്താൽ അത് ഉണർന്നിരിക്കും.

ആകെ ഫലം: കണക്ക് ഉപയോക്താക്കളിൽ നിന്ന് ഡാറ്റാബേസുകൾക്ക് യഥാർത്ഥത്തിൽ വരുന്ന ചെലവിന്റെ ഏകദേശം പകുതി മാത്രമാണ് ഈടാക്കിയത്. അത് ഞങ്ങൾക്ക് സുസ്ഥിരമല്ല, ആപ്പിലെ ഉപയോഗ സംഖ്യകൾ ആളുകൾ കരുതുന്ന അർത്ഥം നൽകുന്നുമില്ലായിരുന്നു.

ഊഹിക്കുന്നതിന് പകരം അളക്കുക

ഞങ്ങളുടെ ഡാറ്റാബേസ് provider ഓരോ പ്രോജക്റ്റിന്റെയും compute-unit-seconds per hour റിപ്പോർട്ട് ചെയ്യുന്നു — വലുപ്പം ഉൾപ്പെടെ, അത് യഥാർത്ഥത്തിൽ എത്ര compute ഉപയോഗിച്ചു എന്ന്. അതുകൊണ്ട് മീറ്റർ ഇപ്പോൾ ഇങ്ങനെ പ്രവർത്തിക്കുന്നു:

1. ഡാറ്റാബേസുള്ള ഓരോ പ്രസിദ്ധീകരിച്ച ആപ്പിനും, അത് ലൈവായതു മുതൽ ഓരോ പൂർത്തിയായ മണിക്കൂറിലെയും അളന്ന ഉപയോഗം എടുക്കുന്നു.
2. ആ ഉപയോഗം provider-ന്റെ വിലയിൽ ചെലവായി മാറ്റി, പ്ലാനിന്റെ നിരക്ക് ബാധകമാക്കി, ആപ്പിന്റെ ഉടമയുടെ ക്രെഡിറ്റിൽ നിന്ന് ഈടാക്കുന്നു.
3. ഓരോ തവണയും ഒരു ദിവസം വരെ പിന്നോട്ട് നോക്കുന്നു, അതിനാൽ ഞങ്ങളുടെ API പുനരാരംഭിക്കുമ്പോൾ നഷ്ടപ്പെട്ട മണിക്കൂറുകൾ പിന്നീടും ബിൽ ചെയ്യപ്പെടും.

സംഭരണം (storage) പ്രവർത്തനത്തെ ആശ്രയിക്കാത്തതിനാൽ വലുപ്പം അനുസരിച്ച് വേറെ ബിൽ ചെയ്യുന്നു.

ഒരു മണിക്കൂർ ഒരിക്കലും രണ്ടുതവണ ചാർജ് ചെയ്യാതിരിക്കുക

ഒന്നിലധികം സെർവറുകളിൽ പ്രവർത്തിക്കുകയും crash ആയി വീണ്ടും ശ്രമിക്കുകയും ചെയ്യാവുന്ന ഒരു ബില്ലിംഗ് മീറ്ററിന് ഇരട്ടി ചാർജ് ചെയ്യാതിരിക്കാൻ ശ്രദ്ധ വേണം. ഡാറ്റാബേസിന്റെ ഓരോ മണിക്കൂറും ചാർജ് ചെയ്യുന്നതിന് മുമ്പ് സ്വന്തം database row-ൽ claim ചെയ്യപ്പെടുന്നു, (database, hour) ജോഡിയിൽ ഒരു uniqueness constraint ഉണ്ട്. രണ്ട് സെർവറുകളോ ഒരു വീണ്ടുമുള്ള ശ്രമമോ ഒരേ മണിക്കൂർ ബിൽ ചെയ്യാൻ ശ്രമിച്ചാൽ ഒരു claim മാത്രമേ വിജയിക്കൂ.

അപൂർവമായ പരാജയ സാഹചര്യത്തിൽ ഞങ്ങൾ മനഃപൂർവം ഒരു തീരുമാനം എടുത്തു: ഒരു മണിക്കൂർ claim ചെയ്തതിനും ചാർജ് ചെയ്തതിനും ഇടയിൽ പ്രക്രിയ crash ആയാൽ, ആ മണിക്കൂർ claim ചെയ്തതായി നിലനിൽക്കും, പക്ഷേ ബിൽ ചെയ്യപ്പെടില്ല. അപൂർവ crash-ൽ ചെറിയൊരു വരുമാനം നഷ്ടപ്പെടുന്നത്, ആരിൽ നിന്നെങ്കിലും ഇരട്ടി ചാർജ് ഈടാക്കുന്നതിനേക്കാൾ നല്ലതാണ്.

അളന്ന ബില്ലിംഗ് ഓണാക്കിയപ്പോൾ അത് അടുത്ത പൂർണ മണിക്കൂറിൽ നിന്നാണ് തുടങ്ങിയത്. അതിനുമുമ്പുള്ള മണിക്കൂറുകൾ പഴയ കണക്ക് പ്രകാരം ഇതിനകം ചാർജ് ചെയ്തിരുന്നു; അളന്ന ഡാറ്റ ഉപയോഗിച്ച് അവ വീണ്ടും ബിൽ ചെയ്താൽ ആ ഭാഗം രണ്ടുതവണ ചാർജ് ചെയ്യപ്പെടുമായിരുന്നു.

Mythex-ൽ നിർമ്മിക്കുന്നവർക്ക് ഇതിന്റെ അർത്ഥം

• നിങ്ങളുടെ ഡാറ്റാബേസ് ബിൽ ഇപ്പോൾ ഡാറ്റാബേസ് യഥാർത്ഥത്തിൽ ചെയ്തതിനെ പ്രതിഫലിപ്പിക്കുന്നു. അപൂർവമായി ഉപയോഗിക്കുന്ന ആപ്പിന് വളരെ കുറച്ച് ചെലവേ വരൂ; ഡാറ്റാബേസിനെ നിരന്തരം query ചെയ്യുന്ന ആപ്പ് അതിനെ ഉണർത്തി വെക്കും, ചെലവ് കൂടും.
• ഏറ്റവും വലിയ നിയന്ത്രണം നിങ്ങളുടെ ആപ്പ് ഡാറ്റാബേസ് എങ്ങനെ ഉപയോഗിക്കുന്നു എന്നതാണ്. ഡാറ്റാബേസിനെ ഓരോ കുറച്ച് സെക്കൻഡിലും poll ചെയ്യുന്നത് അതിനെ എപ്പോഴും ഉണർത്തി വെക്കും. ആവശ്യപ്പെടുമ്പോൾ AI-യോട് ഡാറ്റ എടുക്കാൻ പറയുകയോ അത് cache ചെയ്യുകയോ ചെയ്താൽ ഡാറ്റാബേസിന് ഉറങ്ങാൻ കഴിയും. അടിസ്ഥാനങ്ങൾക്കായി ഡാറ്റാബേസ് എന്താണ് എന്നതിനുള്ള ഞങ്ങളുടെ guide കാണുക.
• Pro പ്ലാനുകൾ hosting, ഡാറ്റാബേസുകൾ, സംഭരണം എന്നിവയ്ക്ക് Free നിരക്കിന്റെ പകുതി നൽകുന്നു. വിശദാംശങ്ങൾ credits docs ൽ ഉണ്ട്.

ഞങ്ങൾ പഠിച്ചത്

• ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയ ചെലവുകളുടെ കണക്കുകൾ കാലക്രമേണ തെറ്റിപ്പോകും. ഉപയോഗിച്ചത് എത്രയെന്ന് മുകളിലുള്ള provider-ന് പറയാൻ കഴിയുമെങ്കിൽ, അതിൽ നിന്ന് ബിൽ ചെയ്യുക.
• നിങ്ങൾ ചാർജ് ചെയ്യുന്ന ഏറ്റവും ചെറിയ യൂണിറ്റിൽ ബില്ലിംഗ് idempotent ആക്കുക. ഞങ്ങൾക്ക് അത് ഒരു ഡാറ്റാബേസ്-മണിക്കൂറാണ്.
• പരാജയപ്പെടേണ്ടി വന്നാൽ, ഉപഭോക്താവിന്റെ ഗുണത്തിനായി പരാജയപ്പെടുക.