സ്പേഷ്യൽ മെമ്മറി നിർമ്മിക്കുന്നു

ഭൗതിക ലോകത്തിനായി ഒരു Pinterest നിർമ്മിക്കാൻ ഞാൻ മൂന്ന് മാസങ്ങൾ ചെലവഴിച്ചു.

ആശയം ലളിതമാണ്. നിങ്ങൾ പ്രത്യേക GPS കോർഡിനേറ്റുകളിൽ ഡിജിറ്റൽ കുറിപ്പുകളോ, ഫോട്ടോകളോ, അല്ലെങ്കിൽ കഥകളോ അവശേഷിപ്പിക്കുന്നു. ആളുകൾക്ക് ആ കൃത്യമായ സ്ഥലത്ത് നേരിട്ട് എത്തുമ്പോൾ മാത്രമേ അവ കാണാൻ കഴിയൂ. ഇത് യഥാർത്ഥ ലോകത്തെ ഡിജിറ്റൽ ടൈം ക്യാപ്സ്യൂളുകളുടെ (digital time capsules) ഒരു ശേഖരമാക്കി മാറ്റുന്നു.

ഒരു ലൊക്കേഷൻ അധിഷ്ഠിത ആപ്പ് നിർമ്മിക്കുന്നത് കാണുന്നതിനേക്കാൾ പ്രയാസകരമാണ്. ടെക് സ്റ്റാക്കിനെക്കുറിച്ച് (tech stack) ഞാൻ പഠിച്ച കാര്യങ്ങൾ ഇതാ.

സ്പേഷ്യൽ ഡാറ്റാബേസ് (The Spatial Database) നിങ്ങൾക്ക് ഇത് വലുതാക്കാൻ (scale) ആഗ്രഹമുണ്ടെങ്കിൽ അറ്റാറ്റ്യൂഡ് (latitude), ലോംഗിറ്റ്യൂഡ് (longitude) എന്നിവ വെറും സംഖ്യകളായി മാത്രം സൂക്ഷിച്ചാൽ പോരാ. നിങ്ങൾക്ക് സ്പേഷ്യൽ ഇൻഡക്സുകൾ (spatial indexes) ആവശ്യമാണ്. ഞാൻ PostgreSQL-നോടൊപ്പം PostGIS ആണ് ഉപയോഗിച്ചത്.

ഇത് കൈകാര്യം ചെയ്യുന്നു:

  • R-tree ഉപയോഗിച്ചുള്ള സ്പേഷ്യൽ ഇൻഡക്സിംഗ്
  • ഇൻ-ബിൽറ്റ് ദൂര കണക്കുകൂട്ടലുകൾ (Built-in distance calculations)
  • വേഗതയേറിയ പ്രോക്സിമിറ്റി ക്വറികൾ (Fast proximity queries)

ഒരു ഉപയോക്താവിൽ നിന്ന് 50 മീറ്റർ ചുറ്റളവിൽ ഉള്ള ഓർമ്മകൾ കണ്ടെത്തണമെങ്കിൽ, PostGIS ആ പ്രധാന ജോലി ചെയ്യുന്നു.

കാഷിംഗ് സ്ട്രാറ്റജി (The Caching Strategy) പ്രശസ്തമായ വിനോദസഞ്ചാര കേന്ദ്രങ്ങളിൽ നിന്ന് ധാരാളം റിക്വസ്റ്റുകൾ വരാറുണ്ട്. ഓരോ രണ്ട് സെക്കൻഡിലും ഡാറ്റാബേസ് പരിശോധിക്കുന്നത് പെർഫോമൻസിനെ ബാധിക്കും. തിരക്കുള്ള സ്ഥലങ്ങളിലെ മെമ്മറി ഐഡികൾ (memory IDs) കാഷ് (cache) ചെയ്യാൻ ഞാൻ Redis GEO കമാൻഡുകൾ ഉപയോഗിച്ചു.

ഒരു പ്രോ ടിപ്പ്: Redis-ൽ മുഴുവൻ ഒബ്‌ജക്റ്റും കാഷ് ചെയ്യരുത്. ഐഡികൾ (IDs) മാത്രം കാഷ് ചെയ്യുക. ഇത് മെമ്മറി ഉപയോഗം കുറയ്ക്കുകയും ക്വറി സമയം 20ms-ൽ നിന്ന് 2ms-ലേക്ക് കുറയ്ക്കുകയും ചെയ്യുന്നു.

അപ്‌ലോഡ് പാറ്റേൺ (The Upload Pattern) ഓരോ ഫോട്ടോ അപ്‌ലോഡും നിങ്ങളുടെ സെർവർ നേരിട്ട് കൈകാര്യം ചെയ്യുകയാണെങ്കിൽ, അമിത ലോഡ് കാരണം അത് തകരാറിലാകാൻ സാധ്യതയുണ്ട്. ഞാൻ ഒരു ടു-ഫേസ് അപ്‌ലോഡ് പാറ്റേൺ (two-phase upload pattern) ആണ് ഉപയോഗിച്ചത്:

  • ക്ലയന്റ് സെർവറോട് ഒരു pre-signed URL ആവശ്യപ്പെടുന്നു
  • ക്ലയന്റ് ഫയൽ നേരിട്ട് Cloudflare R2-ലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു
  • അപ്‌ലോഡ് പൂർത്തിയായെന്ന് ക്ലയന്റ് സെർവറിനെ അറിയിക്കുന്നു

S3-ക്ക് പകരം ഞാൻ R2 തിരഞ്ഞെടുത്തത് അതിൽ egress fees ഇല്ലാത്തതുകൊണ്ടാണ്. ഉപയോക്താക്കൾ മീഡിയ ഡൗൺലോഡ് ചെയ്യുമ്പോൾ ഇത് പണം ലാഭിക്കാൻ സഹായിക്കുന്നു.

വിജയിച്ച കാര്യങ്ങൾ (What Worked)

  • PostGIS-ഉം Redis GEO-യും സ്പേഷ്യൽ ക്വറികൾ വേഗത്തിലാക്കുന്നു.
  • നേരിട്ടുള്ള R2 അപ്‌ലോഡുകൾ ബാക്കെൻഡിനെ സ്കെയിൽ ചെയ്യാൻ സഹായിക്കുന്നു.
  • Go, Gin എന്നിവ കുറഞ്ഞ മെമ്മറി ഉപയോഗത്തിൽ ഉയർന്ന പെർഫോമൻസ് നൽകുന്നു.
  • പ്രോഗ്രസീവ് പ്രൈവസി (Progressive privacy - Private, Friends, or Public) ഉപയോക്താക്കളെ സംരക്ഷിക്കുന്നു.

പരാജയപ്പെട്ട കാര്യങ്ങൾ (What Went Wrong)

  • ഉയരമുള്ള കെട്ടിടങ്ങളുള്ള നഗരങ്ങളിൽ GPS കൃത്യതയിൽ വ്യത്യാസമുണ്ടാകാം.
  • 'കോൾഡ് സ്റ്റാർട്ട്' (cold start) പ്രശ്നം യഥാർത്ഥമാണ്. ആപ്പ് സജീവമായി തോന്നാൻ ധാരാളം ഉപയോക്താക്കളെ ആവശ്യമാണ്.
  • കണ്ടന്റ് മോഡറേഷൻ (Content moderation) നിരന്തരമായ ശ്രദ്ധ ആവശ്യപ്പെടുന്നു.

ഇത് നിർമ്മിച്ചതിലൂടെ സോഷ്യൽ ആപ്പുകൾക്ക് ഭൗതികമായ സ്ഥാനം (physical location) എന്നത് പലപ്പോഴും അവഗണിക്കപ്പെടുന്ന ഒരു വശമാണെന്ന് ഞാൻ മനസ്സിലാക്കി. ഡിജിറ്റൽ ഉള്ളടക്കം ഒരു യഥാർത്ഥ സ്ഥലവുമായി ബന്ധപ്പെടുമ്പോൾ അതിന് കൂടുതൽ അർത്ഥമുണ്ടാകുന്നു.

Source: https://dev.to/kevinten10/building-spatial-memory-why-i-built-a-pinterest-for-the-physical-world-and-what-i-learned-bpm

Optional learning community: https://t.me/GyaanSetuAi