और तेज़ SQLite की तलाश

 (avi.im)
2 पॉइंट द्वारा GN⁺ 2024-12-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SQLite पहले से ही एक तेज़ database system है, लेकिन शोधकर्ता इसे और तेज़ बनाने के तरीके खोज रहे हैं
  • Helsinki University और Cambridge के शोधकर्ताओं ने "asynchronous I/O के माध्यम से serverless runtime/database co-design" पर एक पेपर प्रकाशित किया, जिसमें दिखाया गया कि tail latency को अधिकतम 100 गुना तक कम किया जा सकता है। यही पेपर Rust में दोबारा लिखा गया SQLite, Limbo, की नींव बना।

io_uring

  • io_uring का विवरण: Linux kernel का io_uring subsystem asynchronous I/O के लिए एक interface प्रदान करता है। यह user space और kernel space के बीच ring buffer के माध्यम से buffer copy overhead को कम करता है। Application I/O request submit कर सकती है और OS से I/O task पूरा होने की सूचना मिलने तक दूसरे काम कर सकती है।

  • SQLite में query execution: SQLite data storage के लिए files का उपयोग करता है, और sqlite3_open() function से database खोलता है, sqlite3_prepare() function से SQL statements को bytecode में बदलता है। sqlite3_step() function bytecode commands चलाकर query को process करता है।

पूर्वधारणा

  • serverless computing का उभार: serverless environments में database latency एक समस्या बन सकती है। यदि database को सीधे edge runtime में embed किया जाए तो latency नहीं रहती, और SQLite ऐसे environment के लिए उपयुक्त है।

  • SQLite की समस्या: synchronous I/O के उपयोग के कारण resource usage optimally नहीं हो पाता और concurrency तथा multi-tenancy से जुड़ी समस्याएँ पैदा होती हैं।

  • io_uring की ओर बदलाव: POSIX I/O calls को io_uring से बदलना आसान नहीं है, और SQLite को asynchronous I/O model के अनुरूप फिर से design करना पड़ता है।

Limbo

  • asynchronous I/O support: VM और BTree components में बदलाव कर asynchronous I/O support जोड़ा गया, और synchronous bytecode commands को asynchronous commands से बदला गया। asynchronous I/O blocking को हटाता है और concurrency को बेहतर बनाता है।

  • query और storage engine का अलगाव: resource usage को अधिकतम करने के लिए query engine और storage engine को अलग करने का प्रस्ताव दिया गया।

मूल्यांकन और परिणाम

  • benchmarking: multi-tenant serverless runtime को simulate किया गया ताकि हर tenant के पास अपना embedded database हो। SQLite और Limbo की query latency की तुलना में, Limbo ने p999 पर tail latency को 100 गुना कम किया।

  • भविष्य का काम: कई readers और writers को शामिल करते हुए अतिरिक्त benchmarks की योजना है, और performance advantage मुख्य रूप से p999 के बाद ही स्पष्ट दिखता है।

  • open source code: Limbo का code open source के रूप में उपलब्ध है: Limbo GitHub

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

1 टिप्पणियां

 
GN⁺ 2024-12-17
Hacker News राय

  • इस बात पर चर्चा है कि serverless computing के कुछ विशेष use cases, जैसे AWS Lambda और एक केंद्रीय database के साथ serverless तरीके से बनाई गई apps, हमेशा एक-दूसरे के साथ अच्छी तरह फिट नहीं बैठते

    • 6-7 साल पहले जटिल hierarchical files को प्रोसेस करके उनमें से खास जानकारी निकालने की समस्या हल करने पर काम करने का अनुभव था
    • FaaS, computationally expensive कामों के लिए महंगा पड़ता है, और बड़े XML files को हर बार load और parse करना inefficient था
    • समाधान के तौर पर timer के साथ एक केंद्रीय function इस्तेमाल किया गया, जो files को पढ़ता और parse करता था, फिर उन्हें SQLite database में load और index करता था, और उसके बाद file को S3 में store करता था
    • Lambda function, S3 से file download करके query चलाता था, जब वह local copy से नई होती थी या cold start के समय
    • यह पता चला कि Lambda में local /tmp directory होती है और Python runtime में SQLite शामिल होता है, इसलिए function के अलावा कोई अतिरिक्त code upload करने की ज़रूरत नहीं थी
    • यह देखकर दिलचस्पी हुई कि इस तरह के solution को और तेज़ बनाने पर काम चल रहा है

  • यह स्पष्ट करना उपयोगी हो सकता है कि दो researchers में से एक, लेखक का manager है

    • गलतफहमी से लगा था कि लेखक और researchers का कोई संबंध नहीं है

  • इस बात से सहमति है कि "फायदा सिर्फ p999 और उससे ऊपर पर साफ़ दिखता है, जबकि p90 और p99 पर performance लगभग SQLite जैसी ही है"

    • SQLite और optimization पसंद हैं, लेकिन यह बात सही है

  • SQLite के पास बहुत व्यापक test suite है, इसलिए उसका बहुत गहराई से परीक्षण हुआ है

    • यह सवाल है कि क्या rewrite को भी वैसा ही testing मिलेगा, खासकर जब वह io_uring जैसी ऐसी सुविधाएँ इस्तेमाल करे जो तेज़ तो हैं लेकिन लिखने में कठिन और संभावित रूप से buggy हैं

  • benchmarking के लिए ऐसे multi-tenant serverless runtime का simulation किया गया जिसमें हर tenant का अपना embedded database हो

    • SQLite में हर tenant के लिए उसका अपना thread था, और हर thread में query चलाकर मापा गया
    • यह सवाल है कि serverless SQLite setup में क्या हर request के लिए अलग SQLite process इस्तेमाल होगा

  • पहले Postgres में async io लाने की कोशिश हुई थी, लेकिन वह रुक गई

    • हाल की एक proposal यह है कि codebase को fork किए बिना storage manager को custom तरीके से replace किया जा सके
    • इस नई proposal में काफी रुचि है, और यह storage तथा compute को अलग करने की दिशा से जुड़ा है

  • इस विचार पर सवाल है कि जब async io चल रहा हो तो क्या उस दौरान दूसरा काम किया जा सकता है

    • database काम करते समय क्या transaction के पूरा होने का इंतज़ार करना ज़रूरी होगा, इस पर भी सवाल है

  • blog post के लेखक के रूप में यह उम्मीद नहीं थी कि यह लेख front page पर आ जाएगा

    • वह Turso में काम करते हैं, paper अप्रैल 2024 में प्रकाशित हुआ था, और उसके बाद कई सुधार हुए हैं

  • SQLite open source है, लेकिन उसका महत्वपूर्ण test harness नहीं है

    • सवाल है कि alternatives compatibility कैसे सुनिश्चित करेंगे

  • SQLite file format के एक सख्त subset के रूप में JSON-जैसा format बनाने का कोई सरल रास्ता खोजने की कोशिश की गई, लेकिन सफलता नहीं मिली

    • file format में काफी मनमानी लगी, इसलिए रुचि खत्म हो गई, हालांकि कोई दूसरा व्यक्ति इसमें सफल हो सकता है