डेटाबेस के बिना high-availability web service बनाना

 (blog.screenshotbot.io)
1 पॉइंट द्वारा GN⁺ 2024-08-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें

डेटाबेस के बिना high-availability web service बनाना

खोज

  • किसी नए startup के मामले में, आमतौर पर Rails, Django, Node जैसे web framework और MySQL, PostgreSQL, MongoDB जैसे database चुने जाते हैं
  • लेकिन अगर web service और database instance को एक में मिलाया जा सके तो? इस तरह सभी data को RAM में स्टोर करने वाले तरीके से काम किया जा सकता है
  • RAM को database की तरह इस्तेमाल करने पर SQL query से data को serialize करने की ज़रूरत नहीं रहती
  • index को in-memory hash table का उपयोग करके implement किया जा सकता है
  • background job को बड़े process के भीतर thread के रूप में संभाला जा सकता है
  • अगर process crash हो जाए, तो RAM के snapshot समय-समय पर लेकर और बदलावों को disk पर लिखकर recovery की जा सकती है

विस्तार

  • जब high availability चाहने वाले ग्राहक आने लगें, तो Raft consensus algorithm का उपयोग करके server को replicate किया जाता है
  • leader server डाउन हो जाए तो नया leader चुना जाता है और वही request को संभालता है
  • इस तरीके से server restart किए बिना rolling deploy भी किया जा सकता है

निष्कर्षण

  • जब बड़े ग्राहक बढ़ने लगें, तो sharding के ज़रिए web service को विभाजित करके संभाला जा सकता है
  • हर enterprise ग्राहक को dedicated cluster दिया जाता है
  • मुख्य bottleneck commit thread की performance हो सकती है

हमारा stack

  • Common Lisp का उपयोग: multi-threading support बहुत अच्छा है, और code hot reloading के लिए उपयुक्त है
  • bknr.datastore और bknr.cluster का उपयोग: Raft implementation के लिए Baidu की Braft library का उपयोग किया जाता है
  • image file स्टोर करने के लिए EFS का उपयोग: S3 की तुलना में error handling और testing आसान है

सारांश

  • यह architecture नए startup के लिए उपयुक्त है, और Common Lisp का उपयोग करने पर कई tools पहले से उपलब्ध हैं
  • bknr.datastore, Braft, और Raft के योगदान के लिए धन्यवाद

GN⁺ का सार

  • यह लेख डेटाबेस के बिना high-availability web service बनाने के लिए एक नई architecture पेश करता है
  • RAM को database की तरह इस्तेमाल किया जाता है, और Raft consensus algorithm के ज़रिए high availability सुनिश्चित की जाती है
  • Common Lisp का उपयोग करके multi-threading और code hot reloading को support किया जाता है
  • यह architecture नए startup के लिए उपयुक्त है, और तेज़ development व debugging संभव बनाती है
  • मिलते-जुलते features वाले project में Redis और Memcached शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-11
Hacker News राय

  • SQLite का उपयोग किए बिना अपना खुद का transaction log बनाना अजीब है

    • अगर डेटा एक ही सर्वर में समा जाता है, तो उसी सर्वर पर database चलाना बेहतर है
    • अगर डेटा RAM में समा जाता है, तो ramdisk का उपयोग करना और standard tools से persistent storage में replicate करना आसान है

  • MySQL, Postgres, Redis, MongoDB आदि का उपयोग किए बिना अपना in-memory database बनाना जटिल है

    • transactions को serialize करके disk पर लिखना पड़ता है
    • web servers के बीच transaction logs को sync करना और in-memory database को update करना पड़ता है
    • conflict resolution algorithm लिखना पड़ता है
    • web servers को tenant के हिसाब से shard करना और load balancing layer लिखनी पड़ती है

  • MySQL या Postgres के बुनियादी पहलुओं को सीखने से बचना समय की बर्बादी है

    • public cloud provider पर चलाते समय basic tuning से concurrency समस्याएँ हल की जा सकती हैं
    • 1 करोड़ rows जोड़ना कोई बड़ी समस्या नहीं है
    • और बुरी स्थिति आने तक इंतज़ार करके तब समाधान करना ज़्यादा समझदारी है

  • यह HashiCorp के Nomad, Consul, Vault जैसी architecture है

    • developer experience अच्छा है
    • in-memory state को मनचाहे तरीके से सेट किया जा सकता है
    • नए startup के लिए यह उपयुक्त नहीं है
    • upgrades खास तौर पर मुश्किल होते हैं

  • यह गलतफ़हमी है कि RAM बहुत सस्ती है

    • SSD और vCPU performance में काफ़ी सुधार हुआ है, लेकिन RAM की कीमतें उतनी नहीं घटी हैं
    • DRAM की कीमतें चक्रीय रूप से बदलती रहती हैं, और हाल ही में ही थोड़ी सस्ती हुई हैं

  • मैंने ऐसे projects देखे हैं जहाँ file system directories को table और JSON files को row की तरह इस्तेमाल किया गया

    • Redis, Mongo, Postgres पर विचार किया गया, लेकिन अंततः अपना database बनाया गया
    • innovative tokens को database बनाने में लगाना अल्प-प्रभावी है

  • relational database का उपयोग करना ज़्यादा स्थिर है

    • इसमें built-in redundancy, transaction logs, backup और recovery features होते हैं
    • ज़्यादातर मामलों में database का उपयोग करना बेहतर है

  • जटिल चीज़ों से बचने के लिए अपना Raft consensus layer implement किया गया

    • Redis का उपयोग करना शायद ज़्यादा सरल होता

  • आधुनिक desktop और mobile apps अक्सर SQLite जैसी database का उपयोग करते हैं

    • relational data storage और query उपयोगी होते हैं

  • अपना in-memory database बनाना Postgres या SQLite install करने से आसान नहीं है

    • concurrency code लिखने से SQL लिखना ज़्यादा आसान है