Quack: DuckDB क्लाइंट-सर्वर प्रोटोकॉल

 (duckdb.org)
2 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Quack DuckDB इंस्टेंसेज़ के बीच संचार उपलब्ध कराता है, जिससे client-server कॉन्फ़िगरेशन और कई concurrent writers द्वारा एक ही database का उपयोग संभव होता है
  • DuckDB अपनी in-process architecture बनाए रखते हुए, कई processes द्वारा एक ही फ़ाइल को संशोधित करते समय आवश्यक state synchronization को remote protocol के ज़रिए संभालता है
  • Quack एक HTTP-आधारित request-response protocol है, जो application/duckdb serialization और token authentication का उपयोग करता है, और इसका default port 9494 है
  • बेंचमार्क में Quack ने 60 million rows को 4.94 सेकंड में ट्रांसफ़र किया, और छोटे append टेस्ट में 8-thread आधार पर लगभग 5,434 tx/s दर्ज किए
  • Quack का लक्ष्य DuckLake integration, remote Catalog server, auto install·load, protocol extension, और replication protocol है, और यह DuckDB v2.0 के समय production release को लक्ष्य बना रहा है

Quack का उद्देश्य और पृष्ठभूमि

  • Quack एक remote protocol है जो DuckDB इंस्टेंसेज़ को आपस में संचार करने देता है, जिससे DuckDB को client-server कॉन्फ़िगरेशन में चलाया जा सकता है और कई concurrent writers एक ही database का उपयोग कर सकते हैं
  • DuckDB 2019 से in-process architecture पर ज़ोर देता आया है, और बिना अलग server या protocol के low-level API calls पर चलने का इसका तरीका Python notebooks जैसे interactive data science कार्यों और applications के भीतर SQL functionality देने के लिए उपयुक्त रहा है
  • एक ही DuckDB database file को कई processes द्वारा एक साथ संशोधित करने के लिए, DuckDB को main memory में रखे जाने वाले बहुत-से state को processes के बीच synchronize करना पड़ता है
  • पहले इसके लिए अलग RPC process, Arrow Flight SQL protocol का उपयोग करने वाले प्रोजेक्ट, MotherDuck का proprietary protocol, और PostgreSQL को pg_duckdb के साथ जोड़ने वाला “EleDucken” जैसे workaround मौजूद थे
  • DuckDB को general-purpose data processing tool के रूप में विस्तारित करने के लिए, in-process क्षमताओं के साथ client-server protocol नए use cases खोल सकता है

Quack का उपयोग कैसे होता है

  • Quack में दो या अधिक DuckDB इंस्टेंसेज़ आपस में संचार करते हैं, और DuckDB client और server दोनों की भूमिका निभाता है
  • ये दोनों इंस्टेंसेज़ अलग कंप्यूटरों, remote locations, या एक ही laptop के अलग terminal windows में हो सकते हैं
  • Quack extension अभी core_nightly repository में है, और इसे वर्तमान release version DuckDB v1.5.2 में इस्तेमाल किया जा सकता है
  • server-side DuckDB instance में Quack को install·load करने के बाद quack_serve कॉल किया जाता है, और उदाहरण में quack:localhost तथा token = 'super_secret' का उपयोग किया गया है
INSTALL quack FROM core_nightly;
LOAD quack;

CALL quack_serve(
    'quack:localhost',
    token = 'super_secret'
);

CREATE TABLE hello AS
    FROM VALUES ('world') v(s);
  • client-side DuckDB instance में भी Quack को install·load किया जाता है, CREATE SECRET से token सेट किया जाता है, और ATTACH 'quack:localhost' AS remote; के ज़रिए remote instance से कनेक्ट किया जाता है
INSTALL quack FROM core_nightly;
LOAD quack;

CREATE SECRET (
    TYPE quack,
    TOKEN 'super_secret'
);

ATTACH 'quack:localhost' AS remote;
FROM remote.hello;
  • इस कॉन्फ़िगरेशन से DuckDB #2 में remote table hello का मान world क्वेरी किया जा सकता है
  • local instance से remote instance में data copy भी किया जा सकता है; उदाहरण में DuckDB #2 में remote.hello2 table बनाई जाती है और DuckDB #1 में FROM hello2; से उसकी पुष्टि की जाती है
  • complex queries या बड़े datasets में, query को ज्यों का त्यों remote side पर भेजने वाला query function यह नियंत्रित करने में अधिक मदद करता है कि कौन-सा काम remote पर execute होगा
FROM remote.query(
    'SELECT s FROM hello'
);
  • विस्तृत उपयोग विधि Quack documentation में उपलब्ध है

प्रोटोकॉल डिज़ाइन

  • HTTP-आधारित

    • Quack सीधे HTTP के ऊपर बनाया गया है, और HTTP, TCP तथा उसके नीचे की परतों के ऊपर व्यावहारिक रूप से standard protocol layer बन चुका है
    • HTTP stack message stream transfer के लिए कुशलता से optimize किया गया है, और सही implementation होने पर इसका overhead कम रहता है
    • load balancing, authentication, firewall, intrusion detection जैसे क्षेत्रों में HTTP को संभालने के तरीके व्यापक रूप से ज्ञात हैं
    • HTTP के उपयोग के कारण DuckDB-Wasm distribution भी Quack को native रूप से इस्तेमाल कर सकता है
    • browser में चलने वाला DuckDB, Quack के माध्यम से EC2 server पर चल रहे DuckDB instance से सीधे कनेक्ट कर सकता है

  • request-response pattern

    • Quack की interactions हमेशा client-driven request-response pattern पर चलती हैं
    • messages में token authentication के लिए connection request, query execution request, response का पहला भाग लौटाना, और बड़े परिणाम लाने के लिए आगे के fetch messages शामिल हो सकते हैं
    • बड़े परिणामों को कई threads पर parallel रूप से fetch किया जा सकता है

  • serialization

    • requests और responses एक नए MIME type application/duckdb में encode किए जाते हैं
    • यह encoding data types और result sets जैसी complex structures के लिए DuckDB के internal serialization primitives का उपयोग करती है
    • यही primitives कई वर्षों से DuckDB की WAL files में भी उपयोग हो रहे हैं, और इनका पर्याप्त optimization व validation हो चुका है

  • encryption और exposure model

    • Quack server शुरू होते समय default रूप से random authentication token बनाता है, और client को यह token देना होता है
    • Quack server default रूप से केवल localhost पर bind करता है, हालांकि इस व्यवहार को override किया जा सकता है
    • default रूप से SSL उपयोग नहीं किया जाता, क्योंकि केवल localhost communication के लिए वह infrastructure और dependencies जोड़ना उचित नहीं माना गया
    • DuckDB Quack endpoint को सीधे internet पर खोलना recommended नहीं है
    • यदि Quack को web पर expose करना हो, तो nginx जैसे सामान्य HTTP endpoint का उपयोग करने और उस proxy से Let’s Encrypt आदि के माध्यम से SSL terminate कराने की कड़ी सिफारिश की जाती है
    • Quack client non-local connections के लिए मानकर चलता है कि SSL enabled है, हालांकि इस व्यवहार को override किया जा सकता है
    • संबंधित सेटिंग्स reverse proxy documentation में हैं

  • round-trip optimization

    • Quack को query के लिए आवश्यक protocol round-trips कम करने के लिए डिज़ाइन किया गया है
    • connection के बाद एक query को single round-trip में पूरा किया जा सकता है, जो latency-sensitive environments में फ़ायदेमंद है
    • large response transfer को भी optimize किया गया है, और DuckDB टीम के अनुसार Quack फिलहाल sockets के माध्यम से tables transfer करने का सबसे तेज़ तरीका है
    • बेंचमार्क से पता चलता है कि यह कुछ ही सेकंड में millions of rows ट्रांसफ़र कर सकता है

  • authentication और authorization

    • Quack, DuckDB की extensibility philosophy के अनुरूप authentication और authorization model डिज़ाइन करता है
    • यह default authentication method और unrestricted default authorization देता है, लेकिन दोनों को user-provided code से बदला जा सकता है
    • server startup पर random authentication token generate होता है, और client connection के समय authentication string प्रदान करता है
    • server authentication callback को कॉल करता है, और default callback client द्वारा दिए गए token की तुलना server-generated token से करता है
    • authentication callback को settings के माध्यम से बदलकर LDAP directory lookup, text file reading, या arbitrary logic का उपयोग किया जा सकता है
    • authorization function को भी बदला जा सकता है, और default function सभी requests को अनुमति देता है
    • user authorization function client द्वारा चलाए जाने वाले हर query की जाँच कर सकता है, और निर्णय को पहले उपयोग की गई authentication string से जोड़ सकता है
    • ऐसे callbacks सामान्य SQL macros के रूप में भी लिखे जा सकते हैं

  • default port

    • Quack server default रूप से 9494 port पर listen करता है
    • 94 को Netscape Navigator के रिलीज़ वर्ष 1994 को आसानी से याद रखने के लिए चुना गया है

बेंचमार्क

  • बेंचमार्क Ubuntu on Arm चलाने वाली AWS virtual machines पर किए गए
  • instance type m8g.2xlarge था, जिसमें 8 vCPU, 32GB RAM, और “up to 15Gbps” network bandwidth थी
  • यह client और server के एक ही data center में लेकिन अलग machines पर होने वाले वास्तविक scenario को दोहराता है
  • दोनों instances एक ही availability zone में रखे गए थे, और औसत ping time लगभग 0.280ms था

  • bulk transfer

    • पहला बेंचमार्क database protocol के माध्यम से बहुत सारी rows ट्रांसफ़र करने वाले bulk transfer कार्य को मापता है
    • तुलना Quack, PostgreSQL protocol, और Arrow Flight SQL protocol के बीच की गई
    • Arrow Flight, internal रूप से DuckDB का उपयोग करने वाले GizmoSQL server के रूप में उपलब्ध कराया गया
    • TPC-H lineitem table से rows की संख्या बढ़ाते हुए transfer मापा गया, और अधिकतम 60 million rows तक परीक्षण किया गया
    • 60 million rows, CSV format में 76GB के बराबर हैं
    • हर result को 5 runs के median wall-clock time के रूप में रिपोर्ट किया गया
    • मुख्य परिणाम इस प्रकार थे
      • 100k rows: DuckDB Quack 0.07 s, Arrow Flight 0.07 s, PostgreSQL 0.20 s
      • 1M rows: DuckDB Quack 0.24 s, Arrow Flight 0.38 s, PostgreSQL 2.20 s
      • 10M rows: DuckDB Quack 0.89 s, Arrow Flight 2.90 s, PostgreSQL 25.64 s
      • 60M rows: DuckDB Quack 4.94 s, Arrow Flight 17.40 s, PostgreSQL 158.37 s
    • Quack ने 5 सेकंड से कम में 60 million rows ट्रांसफ़र करके बड़े result sets के transfer में मज़बूत प्रदर्शन दिखाया
    • उद्देश्य-उन्मुख Arrow Flight SQL भी इस परिणाम में Quack तक नहीं पहुँच सका, और PostgreSQL का row-based protocol कुल मिलाकर कमज़ोर रहा
    • standard PostgreSQL clients कई threads में parallel reads नहीं करते, जबकि Quack और Arrow ऐसा कर सकते हैं
    • DuckDB का PostgreSQL client भी कुछ स्थितियों में parallel reads कर सकता है

  • small writes

    • दूसरा बेंचमार्क small append कार्य को मापता है
    • यह उन स्थितियों से मेल खाता है जहाँ छोटे writes को centralize किया जाता है, जैसे observability data को किसी central DuckDB instance में इकट्ठा करना
    • जिन protocols को एक single transaction पूरा करने के लिए कई client-server round-trips चाहिए, उनके लिए यह प्रतिकूल टेस्ट है
    • TPC-H lineitem जैसी संरचना वाली एक empty table बनाई गई, और random values को एक-एक row के रूप में अलग-अलग INSERT transactions में डाला गया
    • parallel threads की संख्या बढ़ाते हुए इसे 5 सेकंड तक चलाया गया, और experiment को 5 बार दोहराकर median transactions per second रिपोर्ट किए गए
    • मुख्य परिणाम इस प्रकार थे
      • 1 thread: DuckDB Quack 1,038 tx/s, Arrow Flight 469 tx/s, PostgreSQL 839 tx/s
      • 2 threads: DuckDB Quack 1,956 tx/s, Arrow Flight 799 tx/s, PostgreSQL 1,094 tx/s
      • 4 threads: DuckDB Quack 3,504 tx/s, Arrow Flight 1,224 tx/s, PostgreSQL 2,180 tx/s
      • 8 threads: DuckDB Quack 5,434 tx/s, Arrow Flight 1,358 tx/s, PostgreSQL 4,320 tx/s
    • Quack ने 8 parallel threads तक PostgreSQL को पीछे छोड़ा, और अधिकतम लगभग 5,500 tx/s का transaction throughput दिखाया
    • इसके बाद एक ही table पर concurrent inserts प्रति सेकंड के मामले में DuckDB की मौजूदा सीमा सामने आती है
    • PostgreSQL इस क्षेत्र में बेहतर scale करता है, और DuckDB टीम इसे निकट भविष्य में देखने योग्य क्षेत्र मानती है
    • Arrow Flight अपेक्षा के अनुरूप अच्छा नहीं रहा, और PostgreSQL के लगभग आधे स्तर का प्रदर्शन दिखाया
    • benchmark scripts सार्वजनिक रूप से उपलब्ध हैं

उपयोग के मामले और DuckDB के लिए इसका महत्व

  • Quack कई अलग-अलग processes को local या remote रूप से एक ही table content को parallel में modify करने वाला multiplayer DuckDB उपयोग संभव बनाता है
  • कुछ capabilities पहले DuckLake से भी संभव थीं, लेकिन Quack इसे अधिक सरल बनाता है और कहीं अधिक उच्च प्रदर्शन देता है
  • जिन use cases में ultra-local queries की तुलना में central state अधिक महत्वपूर्ण है, वहाँ DuckDB के उपयोग का दायरा बढ़ता है
  • data lake के प्रसार से यह पहले ही स्पष्ट हो चुका है कि data हमेशा local नहीं होता, और Quack इस दिशा के अनुरूप एक capability बनकर उभरता है
  • Quack को DuckLake में integrate किया जाएगा, जिससे DuckDB स्वयं एक remotely accessible Catalog server बन सकेगा
  • यह integration data inlining जैसी नई capabilities खोल सकता है
  • अतिरिक्त प्रश्नों के लिए Quack FAQ उपलब्ध है
  • DuckDB interactive analytics के लिए in-process database वाले अपने शुरुआती niche से आगे बढ़कर आधुनिक data architecture के core component की दिशा में और आगे जा रहा है

Arrow Flight SQL का उपयोग क्यों नहीं किया गया

  • Arrow और ADBC जैसे संबंधित प्रोजेक्ट, ODBC और JDBC की तरह systems के बीच data exchange में friction कम करने वाले exchange APIs के रूप में मूल्यवान हैं
  • लेकिन DuckDB अपने अंदर Arrow जैसे exchange formats के उपयोग को लेकर सावधान है
  • DuckDB के query intermediate results की internal structure कुछ मायनों में Arrow के क़रीब है, लेकिन अन्य मायनों में काफ़ी अलग है
  • data systems में innovation जारी रखने के लिए, बाहरी नियंत्रण वाले formats की सीमाओं में बंधना उचित नहीं माना गया, इसलिए Quack में proprietary serialization का उपयोग किया गया
  • proprietary serialization उपयोग करने से जब भी नए data types या protocol messages की ज़रूरत हो, उन्हें तुरंत deploy किया जा सकता है
  • Arrow Flight SQL में ऐसा डिज़ाइन है जिसमें हर query को कम से कम दो protocol round-trips, यानी CommandStatementQuery और DoGet, की आवश्यकता होती है
  • यह तरीका छोटे update कार्यों के लिए, विशेषकर ज़्यादा latency वाले environments में, आदर्श नहीं है
  • Quack को छोटे queries के लिए single round-trip में query execution और result fetch संभव बनाने हेतु डिज़ाइन किया गया है

आगे की योजना

  • Quack को DuckLake में integrate किया जाएगा ताकि remote DuckDB server को DuckLake catalog के रूप में उपयोग किया जा सके
  • इस integration से विशेष रूप से inlining में बड़े performance improvements की उम्मीद है
  • आने वाले महीनों में Quack को और परिष्कृत किया जाएगा, और इस साल शरद ऋतु में निर्धारित DuckDB v2.0 के साथ पहला production release लाने की योजना है
  • Quack extension की आवश्यकता होने पर auto install और auto load को सक्षम करने की योजना है
  • नए parser का उपयोग करके DuckDB में remote SQL databases से संवाद करने वाली syntax को भी बेहतर बनाया जाएगा
  • DuckDB core के स्तर पर transactions per second को काफ़ी बढ़ाने की योजना है, ताकि 8 parallel threads से कहीं आगे तक transaction scaling संभव हो सके
  • authentication और authorization से आगे बढ़ते हुए, DuckDB extensions को नए protocol messages और handling code जोड़ने देने के लिए Quack protocol extensions की अनुमति पर भी विचार किया जा रहा है
  • Quack के ऊपर replication protocol जोड़कर DuckDB instance के changes को दूसरे servers पर replicate करने और read-replica cluster बनाने की संभावना पर भी विचार हो रहा है
  • Quack और इसकी शुरुआती शुरूआत को 24 जून के community conference DuckCon #7 में भी कवर किया जाएगा
  • अलग Quack project page भी उपलब्ध है

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की टिप्पणियाँ

  • पिछले हफ़्ते ही मैं ठीक ऐसी किसी चीज़ की इच्छा कर रहा था, टाइमिंग कमाल की है
    मैं एक Deno सर्वर से sensor values को DuckDB में स्ट्रीम कर रहा था, लेकिन सर्वर बंद किए बिना duckdb -ui से डेटा देख नहीं सकता था
    DB की सामग्री देखने के लिए सर्वर में कोई फीचर जोड़ना नहीं चाहता था, इसलिए अभी के लिए ऐसे ही काम चलाने वाला था, लेकिन यह उस समस्या और DuckDB के साथ आ रही दूसरी मिलती-जुलती समस्याओं को बहुत साफ़ तरीके से हल कर देता है
    DuckDB 2025/26 में मेरी पसंदीदा तकनीक है, और LLM काम, डेटा स्टोरेज, विश्लेषण, डेटा पाइपलाइन जैसी कई workflows में गहराई से शामिल हो चुका है

    • आप इसे अपने workflows में कैसे इस्तेमाल कर रहे हैं, यह थोड़ा और विस्तार से सुनना चाहूँगा
      दिलचस्पी तो बहुत है, लेकिन अभी तक मैं अपनी problem-solving शैली में DuckDB को स्वाभाविक रूप से फिट नहीं कर पाया हूँ, इसलिए यह भी ठीक से नहीं समझ पा रहा कि किन use cases पर इसे मैप कर सकता हूँ

  • कमाल है। मैं हमारी कंपनी के internal app framework में DuckDB इस्तेमाल करने पर विचार कर रहा था, और यह “तो फिर horizontal scaling कैसे करेंगे” वाली समस्या हल कर देता है
    DuckDB टीम के लिए तालियाँ, और protocol का नाम Quack होना भी पसंद आया

  • मैं एक open source project पर काम कर रहा था जो observability data, यानी metrics, logs और traces को Parquet में स्टोर और query करता है, और open storage formats तथा catalogs के इस्तेमाल की बात से मैं पूरी तरह सहमत हूँ, लेकिन Apache Iceberg की usability को लेकर काफ़ी निराशा थी
    यह देखकर DuckLake मेरे use case के लिए कहीं अधिक दिलचस्प लगने लगा है, और आगे यह कहाँ जाता है, यह देखने का इंतज़ार है
    https://github.com/smithclay/duckdb-otlp

    • क्या आप इसे Mimir के विकल्प के रूप में इस्तेमाल कर रहे हैं?

  • DuckDB अच्छा है, लेकिन यह आखिर बनना क्या चाहता है, यह समझ नहीं आता
    इसे इस्तेमाल करने के नए-नए तरीके लगातार सामने आ रहे हैं, और कौन-सा तरीका सही है, यह एक नज़र में समझना आसान नहीं है

    • DuckDB standalone भी है और साथ ही एक component भी
      यह कोशिश काफ़ी सुसंगत लगती है, और कुछ मायनों में इसे फिर से पारंपरिक client-server relational database के परिचित usage model की ओर ले जाती है
      relational DBMS मूल रूप से multi-user concurrency systems थे, और DuckDB एक बहुत तेज़ local engine है जिसे दूसरे systems में embed किया जा सकता है, इसलिए इसके use cases भी बहुत विविध हैं
      यह कुछ वैसा ही है जैसे SQLite से पूछना कि वह क्या बनना चाहता है। वह phones, browsers, desktop apps और IoT devices में मौजूद है, और लोगों ने उसे कई दिशाओं में बढ़ाया है। फ़र्क बस इतना है कि यहाँ यह third-party नहीं बल्कि first-party पहल है, और मुझे यह काफ़ी सहज और समझने योग्य कदम लगता है
    • बस अपने लिए सही तरीका ढूँढ लेना है
    • हमारी data pipeline ऐसे .duckdb files बनाती है जिन्हें app डाउनलोड करता है
      app S3 पर assets को monitor करता है और etag बदलने पर उन्हें fetch कर लेता है
      BigQuery या ClickHouse जैसी performance पाना, बिना वह infrastructure खुद चलाए या उसकी लागत चुकाए, काफ़ी आसान हो जाता है
      यह हर मामले में परफ़ेक्ट नहीं है, लेकिन उम्मीद से कहीं ज़्यादा चीज़ें संभाल लेता है
    • इसे मैं “DuckDB Postgres बनने की कोशिश कर रहा है” की तरह नहीं, बल्कि एक बड़े workflow के अंदर execution layer बनने की दिशा में देखता हूँ
      अब engine ख़ुद हमेशा pain point नहीं है, दिक्कतें उसके आसपास हैं। live DB, S3 paths, Parquet files, credentials, repeatable execution, exports, validation, और वे क्षण जब one-off scripts चुपचाप infrastructure बन जाती हैं
      Quack remote/server हिस्से को अधिक साफ़ बनाता है, लेकिन बड़ा रुझान यह लगता है कि DuckDB end-user tool से ज़्यादा दूसरे tools के अंदर SQL layer बनता जा रहा है
    • इस उपयोग और Arrow Flight के use cases में data movement के अलावा ज़्यादा समानता समझ नहीं आती

  • “concurrent writers” से क्या मतलब है, यह समझाया नहीं गया
    ऊपर से देखने पर तो बस server side पर writes को serialize किया जा रहा है

    • मुझे नहीं लगता कि ऐसा है। DuckDB पहले से ही एक process के अंदर concurrent writes सपोर्ट करता है
      ऐसा नहीं लगता कि यह फीचर अचानक सारी writes को serialize करने लगेगा

  • साझा team server पर रखे जाने वाले छोटे internal analytics datasets के लिए यह उपयोगी लगता है
    homelab इस्तेमाल के लिए भी इसे काफ़ी ध्यान से देखने लायक है

    • DuckLake के साथ इस्तेमाल करें तो यह multi-terabyte datasets तक अच्छी तरह scale करता है
      इस server protocol का बड़ा फ़ायदा यह है कि बड़े memory वाले server को साझा किया जा सकता है और हाल के डेटा के लिए shared cache का लाभ लिया जा सकता है

  • मेरे पास एक C++ application है, और रनटाइम के दौरान सब कुछ memory में रहता है
    sessions के बीच इसे XML के रूप में disk पर सेव किया जाता है और यह ठीक काम करता है, लेकिन यह सख़्ती से single-user के लिए है, और कुछ ग्राहक चाहते हैं कि इसे इस तरह generalize किया जाए कि कई users एक साथ पढ़ और लिख सकें
    performance requirements कम हैं, यानी 2~3 लोग एक साथ कुछ हज़ार records अपडेट करें, बस इतना। ऐसे मामले में DuckDB + Quack अच्छा विकल्प होगा? या इससे बेहतर कुछ और है? SQLite भी देखा है, लेकिन मेरी समझ यह है कि वह client-server की तरह काम नहीं करता

    • https://firebirdsql.org दशकों से SQLite और full-fledged PostgreSQL के बीच चुपचाप मौजूद है, लेकिन अगर सवाल यह है कि कौन-सा client-server database इस्तेमाल करें, तो default recommendation PostgreSQL ही होगी
    • DuckDB analytics की तरफ़ ज़्यादा झुका हुआ है
      concurrent users को संभालने वाले DB के लिए server side पर किसी-न-किसी रूप में hosting किए बिना कोई अच्छा विकल्प मिलना मुश्किल लगता है
      हाँ, कुछ games की तरह अपना multiplayer client server ख़ुद बनाना संभव है, लेकिन ईमानदारी से कहें तो Postgres या SQLite को host करना बेहद सस्ता और आसान है, और सबसे बढ़कर यही इस समस्या का standard approach है
    • यह CRDT के लिए बहुत उपयुक्त use case जैसा लगता है, और तब offline editing भी संभव हो जाती है
    • शायद आपको जिस शब्द को खोजने की ज़रूरत है, वह local-first है

  • शानदार। मैं DuckDB का इस्तेमाल करके Excel-जैसा column-oriented spreadsheet app बना रहा था, लेकिन मुझे पारंपरिक HTTP layer के ज़रिए “client” फिर से बनाना पड़ा

  • “DuckDB आखिर क्या बनना चाहता है” वाला सवाल बार-बार आता है, लेकिन मुझे लगता है जवाब पहले से साफ़ है
    वह analytics के लिए SQLite बनना चाहता है। embed किया जा सके, configuration की ज़रूरत न हो, और हर जगह चले
    Quack बस उस “हर जगह” में remote को शामिल करने वाला हिस्सा है

    • अगर DuckDB टीम का बनाया हुआ कोई cookbook हो, तो वह बहुत बढ़िया होगा

  • “क्या Quack के साथ DuckDB को DuckLake के catalog database के रूप में इस्तेमाल किया जा सकता है?” इस पर जवाब है, “अभी नहीं, लेकिन इस पर काम चल रहा है!”
    यह niche use case जैसा लग सकता है, लेकिन मेरे लिए यही सबसे दिलचस्प हिस्सा है
    हमारा lakehouse DuckLake इस्तेमाल करता है और catalog के लिए Postgres, लेकिन DuckDB / Quack catalog एक शानदार विकल्प बन सकता है

    • आगे चलकर Quack शायद DuckLake catalog के लिए मुख्य विकल्प बन जाएगा
      इसके कई कारण हैं। पहला, inline processing में type mismatch नहीं होता। अगर DuckDB के अलावा कोई और catalog इस्तेमाल करें, तो कई types का 1:1 mapping नहीं बनता, जिससे उन data types को संभालते समय अतिरिक्त overhead आता है
      दूसरा, catalog के ऊपर भी DuckDB की analytics performance और अब transaction performance भी लगभग ज्यों की त्यों मिल सकती है। DuckDB द्वारा DuckDB को पढ़ना हमारे Postgres/SQLite scanners से सीधा तेज़ है
      तीसरा, retries के लिए round-trip नहीं करना पड़ता। पूरी retry logic को DuckDB server side पर relatively आसानी से चलाया जा सकता है। अभी ऐसी retries Postgres तक कई round-trips कराती हैं, जिससे contention-heavy workloads में performance bottleneck बनता है
      संदर्भ के लिए, मैं duckdb/ducklake developer हूँ
    • इस पर सच में काम चल रहा है: https://github.com/duckdb/ducklake/pull/1151
      कुछ ही दिनों में इसे टेस्ट किया जा सकेगा