ലോ-ലേറ്റൻസി ഇവന്റ് അനലിറ്റിക്സ് രൂപകൽപ്പന ചെയ്യൽ
വലിയ ഫിസിക്കൽ വെന്യൂകൾക്കായി (physical venues) ഡാറ്റാ പൈപ്പ്ലൈനുകൾ നിർമ്മിക്കുന്നത് പ്രയാസകരമാണ്.
20,000 ആളുകൾ പങ്കെടുക്കുന്ന ഒരു ഇവന്റ്, ഒരു സാധാരണ വെബ് ആപ്പിനേക്കാൾ വ്യത്യസ്തമായ പ്രശ്നങ്ങളാണ് ഉണ്ടാക്കുന്നത്. ഒരു വെബ് ആപ്പിൽ, ഉപയോക്താക്കൾ വിവിധ ടൈം സോണുകളിൽ (time zones) വ്യാപിച്ചു കിടക്കുന്നു. എന്നാൽ ഒരു വെന്യൂവിൽ, ആയിരക്കണക്കിന് ആളുകൾ ഒരേ സമയം ഡാറ്റാ സ്പൈക്കുകൾ (data spikes) സൃഷ്ടിക്കുന്നു.
ബാച്ച് പ്രോസസ്സിംഗോ (Batch processing) ലോങ്ങ്-പോളിംഗോ (long-polling) ഉപയോഗിക്കുന്നത് ലാഗ് (lag) ഉണ്ടാക്കും. ജനക്കൂട്ട നിയന്ത്രണത്തിൽ (crowd control), 15 മിനിറ്റ് വൈകുന്നത് ഒരു പരാജയമാണ്. പ്രശ്നങ്ങൾ തടയുന്നതിന് പകരം, പഴയ പ്രശ്നങ്ങളോട് പ്രതികരിക്കുന്ന അവസ്ഥയിലേക്ക് നിങ്ങൾ എത്തിച്ചേരും.
സെക്കൻഡിൽ താഴെ മാത്രം സമയത്തിനുള്ളിൽ (sub-second speed) ഫലം ലഭിക്കാൻ, എഡ്ജ് ഹാർഡ്വെയറിൽ (edge hardware) നിന്ന് നിങ്ങളുടെ ഡാഷ്ബോർഡിലേക്ക് ഒരു തുടർച്ചയായ സ്ട്രീം ആവശ്യമാണ്.
കരുത്തുറ്റ ഒരു ടെലിമെട്രി പൈപ്പ്ലൈനിനായുള്ള (telemetry pipeline) ബ്ലൂപ്രിന്റ് ഇതാ.
ലെയർ 1: ഓഫ്ലൈൻ-ഫസ്റ്റ് എഡ്ജ് കമ്പ്യൂട്ട് (Offline-First Edge Compute)
നിങ്ങൾക്ക് 5ms-ൽ താഴെ മാത്രം ലേറ്റൻസി (latency) ആവശ്യമാണ്. കൂടാതെ നെറ്റ്വർക്ക് തകരാറുകൾ (network drops) കൈകാര്യം ചെയ്യേണ്ടതുമുണ്ട്. Redis പോലുള്ള ലോക്കൽ ഇൻ-മെമ്മറി കാഷെ (in-memory cache) ഉള്ള എഡ്ജ് നോഡുകൾ ഉപയോഗിക്കുക. ഇവന്റ് തുടങ്ങുന്നതിന് മുമ്പ് നിങ്ങളുടെ ക്ലൗഡ് ഡാറ്റാബേസ് ഈ നോഡുകളിലേക്ക് മിറർ (mirror) ചെയ്യുക.
ഒരു പങ്കാളി ഒരു ടാഗ് സ്കാൻ ചെയ്യുമ്പോൾ, സിസ്റ്റം ലോക്കൽ കാഷെ പരിശോധിക്കുന്നു. ഇത് ഇന്റർനെറ്റിനെ മറികടന്ന് ഗേറ്റുകളിലൂടെയുള്ള നീക്കം സുഗമമാക്കുന്നു.
ലെയർ 2: MQTT വഴിയുള്ള അസിൻക്രണസ് ഇൻജഷൻ (Asynchronous Ingestion via MQTT)
വെന്യൂ നെറ്റ്വർക്കുകൾ പലപ്പോഴും അസ്ഥിരമായിരിക്കും. MQTT ഭാരം കുറഞ്ഞതായതുകൊണ്ട് (lightweight) അത് ഉപയോഗിക്കുക. എഡ്ജ് നോഡുകൾ ഒരു ക്ലൗഡ് ബ്രോക്കറിലേക്ക് (cloud broker) സന്ദേശങ്ങൾ അയക്കുന്നു. തുടർന്ന് ബ്രോക്കർ ആ ഡാറ്റ നിങ്ങളുടെ ഇൻജഷൻ ക്യൂകളിലേക്ക് (ingestion queues) റൂട്ട് ചെയ്യുന്നു.
ലെയർ 3: ഫുൾ-ഡ്യുപ്ലെക്സ് WebSockets (Full-Duplex WebSockets)
അപ്ഡേറ്റുകൾക്കായി നിങ്ങളുടെ ഫ്രണ്ട്എൻഡ് (frontend) റിക്വസ്റ്റ് ചെയ്യാൻ അനുവദിക്കരുത്. നിങ്ങളുടെ API ഗേറ്റ്വേയുമായി (API gateway) ഒരു പെർസിസ്റ്റന്റ് കണക്ഷൻ നിലനിർത്താൻ WebSockets ഉപയോഗിക്കുക. ഇത് ഓപ്പറേഷൻസ് ടീമിന് സെക്കൻഡിൽ താഴെ സമയത്തിനുള്ളിൽ ഫ്ലോർ മാറ്റങ്ങൾ കാണാൻ സഹായിക്കുന്നു.
ഈ ക്രമീകരണം വഴി ജനക്കൂട്ടത്തിന്റെ പെട്ടെന്നുള്ള വർദ്ധനവോ (crowd spikes) കുറഞ്ഞ പങ്കാളിത്തമോ (low engagement) ഉടൻ തന്നെ തിരിച്ചറിയാൻ ടീമുകൾക്ക് സാധിക്കും. ഒരു തടസ്സം (bottleneck) ഉണ്ടാകുന്നതിന് മുമ്പ് തന്നെ നിങ്ങൾക്ക് സ്റ്റാഫിനെ പുനർവിന്യസിക്കാൻ കഴിയും.
ജനത്തിരക്കുള്ള സ്ഥലങ്ങളിൽ നിങ്ങളുടെ IoT ഹാർഡ്വെയർ എങ്ങനെ ഒപ്റ്റിമൈസ് ചെയ്യും? നിങ്ങളുടെ അഭിപ്രായങ്ങൾ താഴെ പങ്കുവെക്കുക.