ദശലക്ഷക്കണക്കിന് ചെറിയ ഫയലുകൾ കാര്യക്ഷമമായി സംഭരിക്കുക. സ്വയം ഹോസ്റ്റ് ചെയ്ത പരിഹാരം

പ്രിയ സമൂഹമേ, ഈ ലേഖനം ദശലക്ഷക്കണക്കിന് ചെറിയ ഫയലുകൾ കാര്യക്ഷമമായി സംഭരിക്കുന്നതിലും വീണ്ടെടുക്കുന്നതിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കും. ഈ ഘട്ടത്തിൽ, ക്ലസ്റ്റർ ലോക്കുകൾ ഉൾപ്പെടെയുള്ള ലോക്കുകൾക്കുള്ള പൂർണ്ണ പിന്തുണയുള്ള പോസിക്സ്-അനുയോജ്യമായ ഫയൽ സിസ്റ്റങ്ങൾക്കായി അന്തിമ പരിഹാരം നിർദ്ദേശിക്കപ്പെടുന്നു, കൂടാതെ ക്രച്ചസ് ഇല്ലാതെ പോലും.

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

ആശയം ഇതാണ്:

ലളിതമായി പറഞ്ഞാൽ, ചെറിയ ഫയലുകൾ സെർവറിലൂടെ അപ്‌ലോഡ് ചെയ്യുന്നു, അവ നേരിട്ട് ആർക്കൈവിലേക്ക് സംരക്ഷിക്കുകയും അതിൽ നിന്ന് വായിക്കുകയും ചെയ്യുന്നു, കൂടാതെ വലിയ ഫയലുകൾ വശങ്ങളിലായി സ്ഥാപിക്കുന്നു. സ്കീം: 1 ഫോൾഡർ = 1 ആർക്കൈവ്, മൊത്തത്തിൽ ഞങ്ങൾക്ക് ചെറിയ ഫയലുകളുള്ള നിരവധി ദശലക്ഷം ആർക്കൈവുകൾ ഉണ്ട്, നൂറുകണക്കിന് ദശലക്ഷം ഫയലുകളല്ല. സ്‌ക്രിപ്‌റ്റുകളോ ഫയലുകൾ ടാർ/സിപ്പ് ആർക്കൈവുകളോ ഇല്ലാതെ പൂർണ്ണമായി നടപ്പിലാക്കുന്നു.

ഞാൻ ഇത് ചുരുക്കി സൂക്ഷിക്കാൻ ശ്രമിക്കും, പോസ്റ്റ് ദൈർഘ്യമേറിയതാണെങ്കിൽ ഞാൻ മുൻകൂട്ടി ക്ഷമ ചോദിക്കുന്നു.

പരമ്പരാഗത ആർക്കൈവുകളിലും ഒബ്‌ജക്റ്റ് സ്റ്റോറേജിലും അന്തർലീനമായ പോരായ്മകളില്ലാതെ, എച്ച്ടിടിപി പ്രോട്ടോക്കോൾ വഴി ലഭിച്ച ഡാറ്റ നേരിട്ട് ആർക്കൈവുകളിലേക്ക് സംരക്ഷിക്കാൻ കഴിയുന്ന അനുയോജ്യമായ ഒരു സെർവർ ലോകത്ത് കണ്ടെത്താൻ എനിക്ക് കഴിഞ്ഞില്ല എന്ന വസ്തുതയിലാണ് ഇതെല്ലാം ആരംഭിച്ചത്. 10 സെർവറുകളുടെ ഒറിജിൻ ക്ലസ്റ്ററാണ് തിരയലിന്റെ കാരണം, അത് വലിയ തോതിൽ വളർന്നു, അതിൽ 250,000,000 ചെറിയ ഫയലുകൾ ഇതിനകം കുമിഞ്ഞുകൂടി, വളർച്ചാ പ്രവണത നിർത്താൻ പോകുന്നില്ല.

ലേഖനങ്ങൾ വായിക്കാൻ ഇഷ്ടപ്പെടാത്തവർക്ക്, ഒരു ചെറിയ ഡോക്യുമെന്റേഷൻ എളുപ്പമാണ്:

ഇവിടെ и ഇവിടെ.

അതേ സമയം ഡോക്കർ, ഇപ്പോൾ nginx ഉള്ളിൽ മാത്രം ഒരു ഓപ്ഷൻ ഉണ്ട്:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

അടുത്തത്:

ധാരാളം ഫയലുകൾ ഉണ്ടെങ്കിൽ, കാര്യമായ വിഭവങ്ങൾ ആവശ്യമാണ്, അവയിൽ ചിലത് പാഴായിപ്പോകുന്നു എന്നതാണ് ഏറ്റവും മോശം ഭാഗം. ഉദാഹരണത്തിന്, ഒരു ക്ലസ്റ്റേർഡ് ഫയൽ സിസ്റ്റം ഉപയോഗിക്കുമ്പോൾ (ഈ സാഹചര്യത്തിൽ, MooseFS), ഫയൽ, അതിന്റെ യഥാർത്ഥ വലുപ്പം പരിഗണിക്കാതെ, എല്ലായ്‌പ്പോഴും കുറഞ്ഞത് 64 KB എടുക്കും. അതായത്, 3, 10 അല്ലെങ്കിൽ 30 KB വലിപ്പമുള്ള ഫയലുകൾക്ക്, ഡിസ്കിൽ 64 KB ആവശ്യമാണ്. കാൽ ബില്യൺ ഫയലുകൾ ഉണ്ടെങ്കിൽ, നമുക്ക് 2 മുതൽ 10 ടെറാബൈറ്റുകൾ വരെ നഷ്ടപ്പെടും. MooseFS-ന് ഒരു പരിമിതി ഉള്ളതിനാൽ അനിശ്ചിതമായി പുതിയ ഫയലുകൾ സൃഷ്ടിക്കാൻ കഴിയില്ല: ഓരോ ഫയലിന്റെയും ഒരു പകർപ്പ് ഉപയോഗിച്ച് 1 ബില്ല്യണിൽ കൂടരുത്.

ഫയലുകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് മെറ്റാഡാറ്റയ്ക്ക് ധാരാളം റാം ആവശ്യമാണ്. ഇടയ്ക്കിടെയുള്ള വലിയ മെറ്റാഡാറ്റ ഡംപുകളും എസ്എസ്ഡി ഡ്രൈവുകളുടെ തേയ്മാനത്തിന് കാരണമാകുന്നു.

wZD സെർവർ. ഞങ്ങൾ ഡിസ്കുകളിൽ കാര്യങ്ങൾ ക്രമീകരിക്കുന്നു.

സെർവർ Go-യിൽ എഴുതിയിരിക്കുന്നു. ഒന്നാമതായി, എനിക്ക് ഫയലുകളുടെ എണ്ണം കുറയ്ക്കേണ്ടതുണ്ട്. ഇത് എങ്ങനെ ചെയ്യാം? ആർക്കൈവിംഗ് കാരണം, എന്നാൽ ഈ സാഹചര്യത്തിൽ കംപ്രഷൻ ഇല്ലാതെ, എന്റെ ഫയലുകൾ കംപ്രസ് ചെയ്ത ചിത്രങ്ങൾ മാത്രമായതിനാൽ. ബോൾട്ട് ഡിബി രക്ഷാപ്രവർത്തനത്തിലേക്ക് വന്നു, അത് ഇപ്പോഴും അതിന്റെ പോരായ്മകളിൽ നിന്ന് ഒഴിവാക്കേണ്ടതുണ്ട്, ഇത് ഡോക്യുമെന്റേഷനിൽ പ്രതിഫലിക്കുന്നു.

മൊത്തത്തിൽ, കാൽ ബില്യൺ ഫയലുകൾക്ക് പകരം, എന്റെ കാര്യത്തിൽ 10 ദശലക്ഷം ബോൾട്ട് ആർക്കൈവുകൾ മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ. നിലവിലെ ഡയറക്‌ടറി ഫയൽ ഘടന മാറ്റാൻ എനിക്ക് അവസരം ലഭിച്ചാൽ, അത് ഏകദേശം 1 ദശലക്ഷം ഫയലുകളായി കുറയ്ക്കാൻ സാധിക്കും.

എല്ലാ ചെറിയ ഫയലുകളും ബോൾട്ട് ആർക്കൈവുകളിലേക്ക് പായ്ക്ക് ചെയ്തിട്ടുണ്ട്, അവ സ്ഥിതിചെയ്യുന്ന ഡയറക്ടറികളുടെ പേരുകൾ സ്വയമേവ സ്വീകരിക്കുന്നു, കൂടാതെ എല്ലാ വലിയ ഫയലുകളും ആർക്കൈവുകൾക്ക് അടുത്തായി തുടരും; അവ പാക്ക് ചെയ്യുന്നതിൽ അർത്ഥമില്ല, ഇത് ഇഷ്ടാനുസൃതമാക്കാവുന്നതാണ്. ചെറിയവ ആർക്കൈവുചെയ്‌തു, വലിയവ മാറ്റമില്ലാതെ അവശേഷിക്കുന്നു. രണ്ടിലും സുതാര്യമായാണ് സെർവർ പ്രവർത്തിക്കുന്നത്.

wZD സെർവറിന്റെ വാസ്തുവിദ്യയും സവിശേഷതകളും.

Linux, BSD, Solaris, OSX എന്നീ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾക്ക് കീഴിലാണ് സെർവർ പ്രവർത്തിക്കുന്നത്. ലിനക്സിനു കീഴിലുള്ള AMD64 ആർക്കിടെക്ചറിനായി മാത്രമാണ് ഞാൻ പരീക്ഷിച്ചത്, എന്നാൽ ഇത് ARM64, PPC64, MIPS64 എന്നിവയിൽ പ്രവർത്തിക്കണം.

പ്രധാന സവിശേഷതകൾ:

• മൾട്ടിത്രെഡിംഗ്;
• മൾട്ടിസെർവർ, തെറ്റ് സഹിഷ്ണുതയും ലോഡ് ബാലൻസും നൽകുന്നു;
• ഉപയോക്താവിനോ ഡവലപ്പർക്കോ വേണ്ടിയുള്ള പരമാവധി സുതാര്യത;
• പിന്തുണയ്ക്കുന്ന HTTP രീതികൾ: GET, HEAD, PUT, DELETE;
• ക്ലയന്റ് ഹെഡറുകൾ വഴി വായിക്കുന്നതിനും എഴുതുന്നതിനുമുള്ള പെരുമാറ്റത്തിന്റെ നിയന്ത്രണം;
• ഫ്ലെക്സിബിൾ വെർച്വൽ ഹോസ്റ്റുകൾക്കുള്ള പിന്തുണ;
• എഴുതുമ്പോൾ / വായിക്കുമ്പോൾ CRC ഡാറ്റ സമഗ്രതയെ പിന്തുണയ്ക്കുക;
• കുറഞ്ഞ മെമ്മറി ഉപഭോഗത്തിനും ഒപ്റ്റിമൽ നെറ്റ്‌വർക്ക് പെർഫോമൻസ് ട്യൂണിംഗിനുമുള്ള സെമി-ഡൈനാമിക് ബഫറുകൾ;
• മാറ്റിവെച്ച ഡാറ്റ കോംപാക്ഷൻ;
• കൂടാതെ, സേവനം നിർത്താതെ ഫയലുകൾ മൈഗ്രേറ്റ് ചെയ്യുന്നതിന് ഒരു മൾട്ടി-ത്രെഡഡ് ആർക്കൈവർ wZA വാഗ്ദാനം ചെയ്യുന്നു.

യഥാർത്ഥ അനുഭവം:

ഞാൻ വളരെക്കാലമായി തത്സമയ ഡാറ്റയിൽ സെർവറും ആർക്കൈവറും വികസിപ്പിക്കുകയും പരീക്ഷിക്കുകയും ചെയ്യുന്നു, ഇപ്പോൾ ഇത് പ്രത്യേക SATA ഡ്രൈവുകളിൽ 250,000,000 ഡയറക്‌ടറികളിൽ സ്ഥിതിചെയ്യുന്ന 15,000,000 ചെറിയ ഫയലുകൾ (ചിത്രങ്ങൾ) ഉൾപ്പെടുന്ന ഒരു ക്ലസ്റ്ററിൽ വിജയകരമായി പ്രവർത്തിക്കുന്നു. 10 സെർവറുകളുടെ ഒരു ക്ലസ്റ്റർ ഒരു CDN നെറ്റ്‌വർക്കിന് പിന്നിൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഒരു ഒറിജിൻ സെർവറാണ്. ഇത് സേവനത്തിനായി, 2 Nginx സെർവറുകൾ + 2 wZD സെർവറുകൾ ഉപയോഗിക്കുന്നു.

ഈ സെർവർ ഉപയോഗിക്കാൻ തീരുമാനിക്കുന്നവർക്ക്, ഉപയോഗിക്കുന്നതിന് മുമ്പ്, ബാധകമെങ്കിൽ, ഡയറക്ടറി ഘടന ആസൂത്രണം ചെയ്യുന്നതാണ് ബുദ്ധി. എല്ലാം 1 ബോൾട്ട് ആർക്കൈവിലേക്ക് ക്രാം ചെയ്യാൻ സെർവർ ഉദ്ദേശിച്ചിട്ടില്ലെന്ന് ഞാൻ ഉടൻ തന്നെ റിസർവേഷൻ ചെയ്യട്ടെ.

പ്രകടന പരിശോധന:

സിപ്പ് ചെയ്‌ത ഫയലിന്റെ വലുപ്പം ചെറുതാണെങ്കിൽ, അതിൽ വേഗത്തിൽ GET, PUT പ്രവർത്തനങ്ങൾ നടക്കുന്നു. എച്ച്ടിടിപി ക്ലയന്റ് റൈറ്റിംഗിനുള്ള ആകെ സമയം സാധാരണ ഫയലുകളിലേക്കും ബോൾട്ട് ആർക്കൈവുകളിലേക്കും വായനയിലേക്കും താരതമ്യം ചെയ്യാം. 32 KB, 256 KB, 1024 KB, 4096 KB, 32768 KB വലുപ്പത്തിലുള്ള ഫയലുകളുമായുള്ള ജോലി താരതമ്യം ചെയ്യുന്നു.

ബോൾട്ട് ആർക്കൈവുകളിൽ പ്രവർത്തിക്കുമ്പോൾ, ഓരോ ഫയലിന്റെയും ഡാറ്റ സമഗ്രത പരിശോധിക്കുന്നു (CRC ഉപയോഗിക്കുന്നു), റെക്കോർഡിംഗിന് മുമ്പും റെക്കോർഡിംഗിന് ശേഷവും, ഓൺ-ദി-ഫ്ലൈ റീഡിംഗ്, വീണ്ടും കണക്കുകൂട്ടൽ എന്നിവ സംഭവിക്കുന്നു, ഇത് സ്വാഭാവികമായും കാലതാമസം വരുത്തുന്നു, പക്ഷേ പ്രധാന കാര്യം ഡാറ്റ സുരക്ഷയാണ്.

SATA ഡ്രൈവുകളിലെ ടെസ്റ്റുകൾ വ്യക്തമായ വ്യത്യാസം കാണിക്കാത്തതിനാൽ ഞാൻ SSD ഡ്രൈവുകളിൽ പ്രകടന പരിശോധനകൾ നടത്തി.

പരിശോധനാ ഫലങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള ഗ്രാഫുകൾ:

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ചെറിയ ഫയലുകൾക്ക് ആർക്കൈവുചെയ്‌തതും ആർക്കൈവ് ചെയ്യാത്തതുമായ ഫയലുകൾ തമ്മിലുള്ള വായനയുടെയും എഴുത്തിന്റെയും സമയങ്ങളിലെ വ്യത്യാസം ചെറുതാണ്.

32 MB വലുപ്പമുള്ള ഫയലുകൾ വായിക്കുന്നതും എഴുതുന്നതും പരിശോധിക്കുമ്പോൾ ഞങ്ങൾക്ക് തികച്ചും വ്യത്യസ്തമായ ഒരു ചിത്രം ലഭിക്കും:

ഫയലുകൾ വായിക്കുന്നതിനുള്ള സമയ വ്യത്യാസം 5-25 ms ഉള്ളിലാണ്. റെക്കോർഡിംഗിൽ, കാര്യങ്ങൾ കൂടുതൽ മോശമാണ്, വ്യത്യാസം ഏകദേശം 150 എംഎസ് ആണ്. എന്നാൽ ഈ സാഹചര്യത്തിൽ വലിയ ഫയലുകൾ അപ്‌ലോഡ് ചെയ്യേണ്ട ആവശ്യമില്ല; അങ്ങനെ ചെയ്യുന്നതിൽ അർത്ഥമില്ല; അവ ആർക്കൈവുകളിൽ നിന്ന് പ്രത്യേകം ജീവിക്കാൻ കഴിയും.

*സാങ്കേതികമായി, NoSQL ആവശ്യമായ ജോലികൾക്കായി നിങ്ങൾക്ക് ഈ സെർവർ ഉപയോഗിക്കാം.

wZD സെർവറുമായി പ്രവർത്തിക്കുന്നതിനുള്ള അടിസ്ഥാന രീതികൾ:

ഒരു സാധാരണ ഫയൽ ലോഡ് ചെയ്യുന്നു:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

ബോൾട്ട് ആർക്കൈവിലേക്ക് ഒരു ഫയൽ അപ്‌ലോഡ് ചെയ്യുന്നു (ആർക്കൈവിൽ ഉൾപ്പെടുത്താവുന്ന പരമാവധി ഫയൽ വലുപ്പം നിർണ്ണയിക്കുന്ന സെർവർ പാരാമീറ്റർ fmaxsize, കവിയുന്നില്ലെങ്കിൽ, അത് കവിഞ്ഞാൽ, ആർക്കൈവിന് അടുത്തായി ഫയൽ സാധാരണ പോലെ അപ്‌ലോഡ് ചെയ്യും):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

ഒരു ഫയൽ ഡൗൺലോഡ് ചെയ്യുന്നു (ഡിസ്കിലും ആർക്കൈവിലും ഒരേ പേരുകളുള്ള ഫയലുകൾ ഉണ്ടെങ്കിൽ, ഡൗൺലോഡ് ചെയ്യുമ്പോൾ, ആർക്കൈവ് ചെയ്യാത്ത ഫയലിന് സ്ഥിരസ്ഥിതിയായി മുൻഗണന നൽകും):

curl -o test.jpg http://localhost/test/test.jpg

ബോൾട്ട് ആർക്കൈവിൽ നിന്ന് ഒരു ഫയൽ ഡൗൺലോഡ് ചെയ്യുന്നു (നിർബന്ധിതമായി):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

മറ്റ് രീതികളുടെ വിവരണങ്ങൾ ഡോക്യുമെന്റേഷനിലുണ്ട്.

wZD ഡോക്യുമെന്റേഷൻ
wZA ഡോക്യുമെന്റേഷൻ

സെർവർ നിലവിൽ HTTP പ്രോട്ടോക്കോൾ മാത്രമേ പിന്തുണയ്ക്കുന്നുള്ളൂ; ഇത് ഇതുവരെ HTTPS-ൽ പ്രവർത്തിക്കുന്നില്ല. POST രീതിയും പിന്തുണയ്ക്കുന്നില്ല (ഇത് വേണോ വേണ്ടയോ എന്ന് ഇതുവരെ തീരുമാനിച്ചിട്ടില്ല).

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

ചെയ്യാൻ:

• ക്ലസ്റ്റർ ഫയൽ സിസ്റ്റങ്ങളില്ലാതെ വലിയ സിസ്റ്റങ്ങളിൽ ഉപയോഗിക്കാനുള്ള സാധ്യതയ്ക്കായി നിങ്ങളുടെ സ്വന്തം റെപ്ലിക്കേറ്ററും ഡിസ്ട്രിബ്യൂട്ടറും + ജിയോയുടെ വികസനം (മുതിർന്നവർക്കുള്ള എല്ലാം)
• മെറ്റാഡാറ്റ പൂർണ്ണമായും നഷ്‌ടപ്പെട്ടാൽ അതിന്റെ പൂർണ്ണമായ റിവേഴ്‌സ് വീണ്ടെടുക്കലിന്റെ സാധ്യത (ഒരു ഡിസ്ട്രിബ്യൂട്ടർ ഉപയോഗിക്കുകയാണെങ്കിൽ)
• വ്യത്യസ്ത പ്രോഗ്രാമിംഗ് ഭാഷകൾക്കായി സ്ഥിരമായ നെറ്റ്‌വർക്ക് കണക്ഷനുകളും ഡ്രൈവറുകളും ഉപയോഗിക്കാനുള്ള കഴിവിനായുള്ള നേറ്റീവ് പ്രോട്ടോക്കോൾ
• NoSQL ഘടകം ഉപയോഗിക്കുന്നതിനുള്ള വിപുലമായ സാധ്യതകൾ
• ബോൾട്ട് ആർക്കൈവുകൾക്കുള്ളിലെ ഫയലുകൾക്കോ ​​മൂല്യങ്ങൾക്കോ ​​സാധാരണ ഫയലുകൾക്കുമായി വ്യത്യസ്ത തരം (gzip, zstd, snappy) കംപ്രഷനുകൾ
• ബോൾട്ട് ആർക്കൈവുകൾക്കുള്ളിലെ ഫയലുകൾക്കോ ​​മൂല്യങ്ങൾക്കോ ​​സാധാരണ ഫയലുകൾക്കുമായി വ്യത്യസ്ത തരം എൻക്രിപ്ഷൻ
• ജിപിയു ഉൾപ്പെടെയുള്ള സെർവർ സൈഡ് വീഡിയോ പരിവർത്തനം വൈകി

എനിക്ക് എല്ലാം ഉണ്ട്, ഈ സെർവർ ആർക്കെങ്കിലും ഉപയോഗപ്രദമാകുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു, BSD-3 ലൈസൻസ്, ഇരട്ട പകർപ്പവകാശം, കാരണം ഞാൻ ജോലി ചെയ്യുന്ന കമ്പനി ഇല്ലെങ്കിൽ, സെർവർ എഴുതില്ലായിരുന്നു. ഞാൻ മാത്രമാണ് ഡെവലപ്പർ. നിങ്ങൾ കണ്ടെത്തുന്ന ഏതെങ്കിലും ബഗുകൾക്കും ഫീച്ചർ അഭ്യർത്ഥനകൾക്കും ഞാൻ നന്ദിയുള്ളവനായിരിക്കും.

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