TigerBeetle दुनिया का सबसे दिलचस्प डेटाबेस है
(amplifypartners.com)- वित्तीय ट्रांज़ैक्शन डेटाबेस TigerBeetle एक नया डेटाबेस है जो debit और credit को native रूप से सपोर्ट करता है। जहाँ पारंपरिक SQL डेटाबेस में एक ट्रांज़ैक्शन के लिए 10~20 queries की ज़रूरत पड़ती थी, वहीं यह एक ही roundtrip में 8,190 ट्रांज़ैक्शन प्रोसेस कर सकता है
- जहाँ कई सिस्टम तेज़ coding और dependency विस्तार को चुनते हैं, यह प्रोजेक्ट धीरे-धीरे कोड लिखना, Deterministic Simulation Testing (DST), और zero dependency जैसी परंपरा-विरोधी रणनीतियों पर कायम है
- पारंपरिक OLTP डेटाबेस के single-node आर्किटेक्चर से अलग, इसमें distributed by default, clock fault tolerance (cluster time), और storage fault tolerance को डिज़ाइन में ही शामिल किया गया है, और Viewstamped Replication तथा Zig के चयन से implementation की simplicity और visibility हासिल की गई है
- NASA के Power of Ten से प्रेरित TigerStyle methodology लागू की गई है, जिसमें हर function में औसतन 2 से अधिक assertions का उपयोग, static memory allocation को अनिवार्य करना, और production environment में भी assertions को enabled रखना जैसे कड़े coding standards शामिल हैं
- real-time payments, gaming, और energy billing जैसे hyper-transactional युग के लिए बनी यह संरचना अगली पीढ़ी के OLTP के लिए performance और correctness का benchmark पेश करती है और 20~30 साल पुराने SQL डेटाबेस को बदलने वाले अगली पीढ़ी के transaction processing system के रूप में उभर रही है
debit/credit-केंद्रित डेटाबेस की ज़रूरत
- TigerBeetle एक "वित्तीय ट्रांज़ैक्शन डेटाबेस" है, जो debit और credit को core primitives के रूप में इस्तेमाल करता है
- 1985 में Jim Gray ने ट्रांज़ैक्शन का जो मूल अर्थ परिभाषित किया था, वह SQL transaction नहीं बल्कि business transaction (debit/credit) था
- Gray ने 20 साल बाद भी standard transaction processing को "DebitCredit" के रूप में परिभाषित किया: बैंक खाते से debit करना, double-entry bookkeeping करना, और फिर terminal को जवाब देना
- debit/credit सिर्फ accounting या banking के लिए नहीं, बल्कि ट्रांज़ैक्शन की प्रकृति को व्यक्त करने वाली साझा भाषा है, और यही ACID जैसी guarantees का कारण है
- मौजूदा SQL डेटाबेस में debit/credit लागू करने की समस्याएँ
- एक debit/credit ऑपरेशन के लिए account balance देखना, row lock करना, code में decision का इंतज़ार करना, debit/credit रिकॉर्ड करना आदि मिलाकर 10~20 SQL queries की ज़रूरत होती है
- network round-trip समय के दौरान row lock बनाए रखना पड़ता है, और बहुत से ट्रांज़ैक्शन एक ही "house account" को एक्सेस करें तो hot row समस्या और बढ़ जाती है
- भारत और ब्राज़ील में हर महीने अरबों instant payments, अमेरिका का FedNow, और energy/gaming/cloud की real-time billing के कारण दुनिया अगले 10 वर्षों में कम-से-कम 3 orders of magnitude अधिक transaction-centric हो गई है, लेकिन आज इस्तेमाल हो रहे SQL डेटाबेस 20~30 साल पुरानी तकनीक पर आधारित हैं
- TigerBeetle की अलग पहचान
- debit/credit को first-class primitive की तरह डिज़ाइन करके यह 1MiB की एक query में 8,190 ट्रांज़ैक्शन को एक ही roundtrip में प्रोसेस करता है
- संस्थापक Joran इसे "1000x performance idea" कहते हैं, लेकिन साथ ही इसे "कोई बहुत असाधारण चीज़ नहीं" भी बताते हैं
- आम तौर पर डेटाबेस बनाने में 10 साल लगते हैं, लेकिन TigerBeetle सिर्फ 3.5 साल में पूरा हुआ और Jepsen tests पास कर गया
- जून 2025 में Kyle Kingsbury कई machines पर अलग-अलग जगह corruption डालने के बावजूद TigerBeetle की foundation को तोड़ नहीं पाए (सिर्फ read query engine में 1 correctness bug मिला, जिसका durability पर असर नहीं था)
आधुनिक डेटाबेस डिज़ाइन
distributed-by-default आर्किटेक्चर
- जब Postgres और MySQL बनाए गए थे, तब single-node paradigm हावी था, लेकिन आज shared cloud hardware के दौर में distributed paradigm मुख्यधारा है
- आधुनिक डेटाबेस को strict serializability देनी चाहिए और machines के बीच transactions को replicate करके redundancy, fault tolerance, और high availability सुनिश्चित करनी चाहिए
- आज के कुछ सबसे लोकप्रिय OLTP डेटाबेस अब भी बड़े पैमाने पर single-node architecture पर निर्भर हैं, और कुछ में automatic failover built-in रूप से उपलब्ध नहीं है
- TigerBeetle का distributed डिज़ाइन
- इसे distributed by default बनाया गया है; cluster में जितनी machines चाहिए, उन पर बस binary install करनी होती है
- asynchronous replication, Zookeeper आदि की ज़रूरत नहीं पड़ती; इसके बजाय MIT के pioneering Viewstamped Replication consensus protocol के implementation में निवेश किया गया है
- Zig toolchain को छोड़कर यह zero dependencies बनाए रखता है और हर core dependency में सीधे निवेश करता है
clock fault tolerance
- एक transaction database के रूप में TigerBeetle में physical timestamps की accuracy audit और compliance के लिए महत्वपूर्ण है
- Linux में कई clocks होते हैं:
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - hardware clock की physical imperfections के कारण clocks अलग-अलग गति से चलती हैं, जिससे "drift" errors होते हैं, जो कम समय में "skew" errors के रूप में जमा हो सकते हैं
- आम तौर पर NTP इन errors को ठीक करता है, लेकिन अगर partial network failure के कारण NTP चुपचाप रुक जाए, तो high-availability consensus cluster अंधेरे में चल सकता है
- Linux में कई clocks होते हैं:
- cluster time implementation
- cluster के भीतर अधिकांश clocks को मिलाकर fault-tolerant "cluster time" बनाया जाता है
- ज़रूरत पड़ने पर server के system time को फिर से align किया जाता है, या यदि बहुत ज़्यादा clocks खराब हों तो system सुरक्षित रूप से बंद हो जाता है
- Chrony, PTP, और NTP के रुक जाने का वास्तविक पता लगाकर operators को alert किया जाता है
- servers के बीच offset clock times को track और sample करके Marzullo algorithm से सबसे सटीक interval estimate निकाला जाता है
storage failures को संभालना
-
पारंपरिक डेटाबेस की धारणाएँ
- यह मान लिया जाता है कि disk failure होने पर सिस्टम error message के साथ predictably fail होगा
- SQLite documentation: "SQLite corruption या I/O errors का पता लगाने के लिए database file में redundancy नहीं जोड़ता, और यह मानकर चलता है कि पढ़ा गया data पहले लिखा गया data के बिल्कुल समान है"
-
वास्तविक storage failure scenarios
- disks चुपचाप corrupted data वापस कर सकती हैं, I/O गलत दिशा में जा सकता है (read/write path), या बिना error code के अचानक धीमी पड़ने वाली gray failure हो सकती है
-
TigerBeetle की storage fault tolerance
- Protocol Aware Recovery का उपयोग करके यह availability बनाए रखता है, जब तक सभी replicas में data copies corrupt न हो जाएँ
- सारा data immutable है, और checksums तथा hash chains के ज़रिए corruption या tampering न होने की मज़बूत guarantee दी जाती है
- अपना page cache,
O_DIRECTसे disk पर data लिखना, और raw block device पर सीधे चलना (filesystem की ज़रूरत नहीं) जैसे तरीकों से disk और software के बीच layers को न्यूनतम किया गया है - off-the-shelf LSM की जगह इसका अपना LSM Forest (लगभग 20 LSM trees) इस्तेमाल होता है
- यह सिर्फ storage fault tolerance का दावा नहीं करता, बल्कि Jepsen द्वारा verify किया गया ऐसा एकमात्र distributed database है
- local machine failure की स्थिति में, disk sector level की failure भी storage engine को global consensus से जोड़ती है और cluster के माध्यम से self-healing संभव बनाती है
Zig programming language का चयन
-
मौजूदा डेटाबेस की भाषाएँ
- Postgres C (1970s) में, MySQL C और C++ (1979) में, और MSSQL भी C तथा C++ में लिखा गया है
- programming languages ने पिछले 40 वर्षों में बहुत प्रगति की है; आज अगर आधुनिक तरीके से बनाया जाए तो Rust या Zig चुना जा सकता है
-
TigerBeetle ने Zig क्यों चुना
- पूरा C ecosystem उपयोग कर सकता है, साथ ही बेहतरीन toolchain और compiler देता है
- इसे लिखना आसान है और खासकर पढ़ना आसान है; कुछ मामलों में TypeScript जितना आसान, लेकिन बहुत तेज़
- static memory allocation संभव है, जो TigerBeetle का एक core principle है
- शानदार developer experience और तेज़ learning curve, इसलिए TigerBeetle source code में जल्दी प्रवेश किया जा सकता है
- शुरुआती Rust team के सदस्य Matklad (Rust Analyzer के creator) और Brian Anderson (Graydon के साथ Rust के co-creator) जैसे लोग TigerBeetle में काम कर चुके हैं
- Rust में dynamic memory allocation से बचना "hard mode" है, लेकिन Zig में यह आसान है
Deterministic Simulation Testing और VOPR
DST की बुनियादी अवधारणा
-
Deterministic Simulation Testing (DST) एक अभिनव testing technique है जिसे FoundationDB team (अब Apple के स्वामित्व में) ने लोकप्रिय बनाया
- इसका उपयोग पहले की तुलना में कम समय में ज़्यादा सुरक्षित और bug-free distributed databases बनाने के लिए किया गया
- distributed systems में concurrency समस्याओं के combinations practically अनंत होते हैं: message loss, threads के unpredictable execution order आदि
- पारंपरिक unit tests और integration tests पर्याप्त नहीं होते, और formal verification महँगी तथा धीमी होती है
-
DST कैसे काम करता है
- यह एक deterministic simulator है जो किसी विशेष timeline में system के सामने आने वाले लगभग सभी possible scenarios को चलाता है
- OS, network, disk issues या अलग-अलग delays जैसे external factors को भी शामिल करता है
- कम समय में वर्षों के बराबर testing देता है (क्योंकि समय स्वयं deterministic हो जाता है, इसलिए
while trueloops भी संभव हैं) - databases के लिए विशेष रूप से उपयुक्त है, क्योंकि वे I/O-intensive होते हैं, compute-intensive नहीं
- Jepsen tests, DST क्या कर सकता है उसका सिर्फ एक subset हैं
TigerBeetle का VOPR
-
VOPR (Viewstamped Operation Replicator) का परिचय
- यह internally developed test cluster है, जिसका नाम फिल्म WarGames के WOPR simulator से लिया गया है
- यह TigerBeetle को लगातार असंख्य स्थितियों में test करता है, जैसे nodes कैसे leader elect करते हैं, individual state failures, और network failures
- एक ही thread पर पूरे distributed cluster को virtual रूप से simulate किया जा सकता है
-
VOPR का पैमाना
- यह दुनिया का सबसे बड़ा DST cluster है, जो 1,000 CPU cores पर चलता है
- इसका आकार इतना असामान्य है कि Hetzner ने यह पुष्टि करने के लिए विशेष email भेजी कि क्या उन्हें सच में इतने cores चाहिए
- VOPR-1000 को 24x7x365 चलाया जाता है ताकि production से पहले जितनी संभव हो उतनी rare conditions पकड़ी जा सकें
- simulator में समय को deterministic रूप से abstract किया गया है और लगभग 700x तेज़ किया गया है, जिससे हर दिन लगभग 2,000 साल के simulation runtime के बराबर परीक्षण जमा होता है
DST का gamification
- TigerBeetle ने DST को एक गेम में बदल दिया है, जहाँ system response के साथ अलग-अलग failure scenarios खेले जा सकते हैं
- यह गेम sim.tigerbeetle.com पर खेला जा सकता है
- browser में एक वास्तविक VOPR instance चलाकर TigerBeetle simulation किया जाता है
- इसे WebAssembly में compile किया गया है, और TigerBeetle engineers ने वास्तविक system को visualize करने के लिए game frontend बनाया है
TigerStyle और Power of Ten
TigerStyle methodology
-
TigerStyle, TigerBeetle की engineering methodology है, जो GitHub पर public है
- "यह engineering और art, numbers और human intuition, reason और experience, first principles और knowledge, precision और poetry के intersection पर विकसित होने वाला एक collective give-and-take है"
- फिल्म Tron: Legacy के "Biodigital Jazz" विचार को अपनाता है: मानव और digital elements की intertwining, "Grid" की chaotic लेकिन structured nature, और technology के भीतर human potential की improvisational spirit
- TigerBeetle में code की भावना में सिर्फ science नहीं, art भी डाली जाती है
-
TigerStyle का प्रभाव
- यह NASA के Power of Ten से निकले engineering और code principles प्रस्तुत करता है, जो perfect code writing के सिद्धांतों के लिए जाना जाता है
- इसमें simplicity और elegance जैसे themes से लेकर naming conventions जैसे practical applications तक शामिल हैं
- इसका असर Resonate और Turso जैसी अन्य कंपनियों पर भी दिखने लगा है
- इस पर Lex Fridman podcast में भी चर्चा हुई है
assertions का उपयोग
-
Power of Ten का नियम 5: Assertion
- code behavior के बारे में अपेक्षाओं को उसी समय स्पष्ट रूप से encode करने की अवधारणा, बाद में नहीं
- इसे एक single line boolean की तरह लिखा जाता है: assert(a > b)
-
TigerStyle के assertion नियम
- हर function argument, return value, precondition, और invariant को assert करना; प्रति function औसतन कम-से-कम 2 assertions
- जहाँ assertion महत्वपूर्ण और चौंकाने वाला हो, वहाँ comment की जगह assertion का उपयोग
- compile-time constants के बीच संबंधों को assert करना ताकि program चलने से पहले design integrity verify हो सके
- सिर्फ जो होना चाहिए वही नहीं, बल्कि जिसकी उम्मीद नहीं है उस negative space को भी assert करना, क्योंकि रोचक bugs वहीं उभरते हैं
performance पर सोच
-
code लिखने से ज़्यादा महत्वपूर्ण है code के बारे में reasoning और design
- performance समस्याओं को हल करने और बड़े 1000x gains पाने का सबसे अच्छा समय design phase है, जबकि यही वह समय है जब measurement या profiling संभव नहीं होती
-
TigerStyle के performance principles
- "चार मूल रंगों" (network, storage, memory, CPU) और "दो textures" (bandwidth और latency) पर बुनियादी napkin math करना
- control plane और data plane को अलग करना, access को batch करना, hot loops को standalone functions में निकालना ताकि compiler dependencies घटें—ऐसी tactical tips देना
खुद आज़माएँ
- TigerBeetle आधुनिक research को पुराने formats पर लागू करके अभूतपूर्व performance और reliability guarantees देता है
- यह एक आधुनिक OLTP engine है जो native credit/debit modeling, distributed-by-default, storage और clock fault tolerance, और DST-आधारित quality assurance को जोड़ता है
- यह systems और storage engineering को एक art form की तरह विकसित करता है, और इस प्रक्रिया में मज़ा लेना नहीं भूलता
- DST के चतुर उपयोग की वजह से यह सिर्फ कुछ ही वर्षों में Jepsen standard तक पहुँच गया
- installation single binary के रूप में सरल है, और आधिकारिक site के simple install script के साथ सिर्फ curl command से जल्दी शुरू करके इसे आज़माया जा सकता है
6 टिप्पणियां
अगर आप सोचें कि db distributed node क्यों नहीं इस्तेमाल करता, तो यह समझा जा सकता है कि postgres single node क्यों है
सोचिए कि performance से भी ज़्यादा महत्वपूर्ण क्या है
Hacker News राय
TigerBeetle शानदार है, लेकिन यह ध्यान में रखना चाहिए कि यह लेख उस निवेश फर्म ने लिखा है जिसने TigerBeetle में निवेश किया है संबंधित लिंक
आने वाले कुछ महीनों में मेरे ऐसे और पोस्ट आते रहेंगे, अच्छा होगा अगर लोग इस पर और सक्रिय चर्चा करें, सोच रहा हूँ कि ऊपर एक disclaimer जोड़ना बेहतर होगा या नहीं, जोड़ना मुश्किल नहीं है
यह लेख निवेश फर्म की साइट पर साफ़ तौर पर “Portfolio Spotlight” के रूप में प्रकाशित है, इसलिए अपेक्षाएँ उसी हिसाब से रखनी चाहिए
मैं लेखन शैली पर अलग से कुछ नहीं कहूँगा, लेकिन यह कि यह निवेश फर्म का लेख है, बहुत आसानी से समझ में आ जाता है
TigerBeetle की correctness के प्रति प्रतिबद्धता, coding practices, और hyper-specialized दिशा का मैं प्रशंसक हूँ, लेकिन पोस्ट में कुछ बातों की आलोचना करना चाहता हूँ
multi-node के बारे में दिया गया विवरण थोड़ा भ्रामक है। cloud-native लोग कुछ भी कहें, एक अच्छी तरह tuned single DB और connection pooler के साथ भी बहुत बड़ा QPS संभाला जा सकता है। पिछली कंपनी में maintenance के दौरान गलती से सारा traffic एक ही MySQL 8 RDS instance पर चला गया था, फिर भी वह 80~90K QPS बिना दिक्कत संभाल गया। instance भी बहुत बड़ा नहीं था, बस schema, queries, और ProxySQL/MySQL tuning अच्छी थी। peak पर writer और दो read replica के साथ 120K QPS भी आराम से चल गया
अगर server पर node-local NVMe इस्तेमाल हो, तो ज़्यादा संभावना है कि CPU limit पहले आएगी
redundancy के मामले में, जो RDBMS network environment को ध्यान में रखकर डिज़ाइन किए गए हैं, उनमें आखिरकार failover और hot standby जैसी सुविधाएँ होती ही हैं
TigerBeetle का consensus system clever है और इसमें external dependency नहीं है, लेकिन यह बड़े row handle करने की कोशिश नहीं करता। अगर 1MiB packet में एक बार में हज़ारों transactions प्रोसेस किए जाएँ, तो यह पारंपरिक RDBMS में मुश्किल चीज़ को संभव बना सकता है
इन आलोचनाओं का मकसद उनकी उपलब्धियों को कमतर दिखाना नहीं है, मैं अब भी इस प्रोडक्ट से बहुत प्रभावित हूँ
consensus protocol की सीमा पर की गई यह टिप्पणी ही असल मुद्दा है। TigerBeetle केवल transaction-specific काम को अलग करके संभालना चाहता है, यह सभी OLGP db को replace करने का दावा नहीं करता। मकसद यह है कि महत्वपूर्ण data को अलग transaction DB में ले जाया जाए। ऐसा तरीका TurboPuffer में भी मिलता-जुलता दिखता है
यह सही है कि आधुनिक RDBMS काफ़ी तेज़ हैं, लेकिन TigerBeetle का use case high contention वाला खास environment है। वास्तव में, हमने टेस्ट में सीधे दिखाया है कि जब कई transactions एक ही account को छूते हैं, तो पूरे cluster की throughput नाटकीय रूप से गिर जाती है। (संदर्भ: संबंधित HN कमेंट)
मुझे Joran और टीम का DST, distributed systems की समझ, और performance testing पर किया गया काम बहुत पसंद है, खासकर dependencies को न्यूनतम रखने का उनका जुनून प्रभावशाली है (हालाँकि OS को भी dependency माना जा सकता है)
लेकिन सामान्य OLTP (जिसे टीम OLGP कहती है) को वे जिस तरह दिखाते हैं, उसमें हमेशा कुछ न कुछ अनुचित लगता है। उदाहरण के लिए, financial transactions में केवल row lock इस्तेमाल करने वाले low-performance SQL transactions को ही तुलना के उदाहरण के रूप में दिखाया जाता है, मानो आज भी 50 साल पुराने OLTP design को पकड़े हुए हों
आधिकारिक performance page पर contention को केवल 1% तक ही कम किया जा सकता है। मुझे नहीं लगता कि Stripe जैसी जगह OLTP DB में 1% contention पर चलती है
contention को पहले से भाँपकर, उसे gracefully handle करके, और extreme transaction throughput देने वाले systems बनाए जा सकते हैं। ऐसे systems DB को contention से बचाते हैं ताकि वह scale करता रहे। वास्तव में बड़े payment systems की throughput संख्याएँ आधिकारिक performance comparison से कहीं ज़्यादा होती हैं
marketing में इन बातों को लगभग नज़रअंदाज़ किया जाता है, और ऐसा दिखाया जाता है मानो हर developer बस अपरिपक्व transactions ही DB पर फेंकता है, जबकि असलियत में ज़्यादातर कहीं अधिक समझदार engineers होते हैं। payments industry में तो 'payments engineer' नाम की अलग भूमिका भी होती है
TigerBeetle शानदार है, लेकिन दूसरी OLTP प्रणालियों को ग़लत समझने की ओर धकेलने वाला marketing pattern असहज करता है
प्रशंसा के लिए धन्यवाद
आपने कहा कि Stripe के OLTP DB में 1% contention नहीं होगा, लेकिन Stripe MongoDB-आधारित है। RDBMS से इसकी तुलना करना सेब और संतरे की तुलना जैसा है
underlying OS को dependency माना जा सकता है या नहीं, इस पर कहूँ तो मैंने ऐसे systems के साथ काम किया है जो पूरी तरह in-memory चलते थे और kexec के दौरान भी बने रहते थे। जब syscalls तक नहीं किए जा सकते, तब OS भी काफ़ी हद तक dependency बन जाता है
क्या आप lock-based transactions और commit time पर conditional checks से handle होने वाले optimization approach के उदाहरण दे सकते हैं?
हमने TigerBeetle पर विचार किया था, लेकिन कुछ बाधाएँ थीं
हम Cloudflare Workers का उपयोग करते हैं, लेकिन TigerBeetle client app समर्थित नहीं है। issue लिंक Cloudflare Containers में शायद चल जाए, लेकिन हमारा workflow Workers-केंद्रित है
authentication की सुविधा नहीं है। server (जैसे VPS) पर केवल IP restriction किया जा सकता है, लेकिन serverless environment में fixed IP नहीं होता संबंधित issue
Wireguard में IP को ECC key से authenticate करने का तरीका भी समाधान हो सकता है
वास्तव में Cloudflare Workers या AWS Lambda environment में अगर 1000 workers सभी DB से connection खोल दें, तो समस्या होती है। इसलिए आम तौर पर DB के सामने proxy या service layer रखी जाती है। proxy को DB तक पहुँचने का तरीका पता होता है, इसलिए private network में auth की चिंता नहीं करनी पड़ती
अगर आप TigerBeetle solution team से बात करें, तो वे end-to-end encryption के ज़रिए logical level authentication जैसी custom solution भी सुझा सकते हैं
2025 में authentication feature के बिना DB होना यक़ीन करना मुश्किल है। अगर यह financial DB है, तो कम-से-कम authentication proxy/layer जोड़ने की गाइड वेबसाइट पर होनी चाहिए। अगर यह HTTP इस्तेमाल नहीं करता (जो docs से साफ़ नहीं है), तो लोग यह भी जानना चाहेंगे कि बिना HTTP authentication proxy कैसे जोड़ा जाए। इस हालत में इसे इंटरनेट पर expose करना बहुत ख़तरनाक होगा
सवाल था: “10 साल में transaction volume 1000 गुना से ज़्यादा बढ़ गया है, और इस्तेमाल होने वाला DB 20-30 साल पुराना SQL है। क्या यह टिक पाएगा?” मेरा मानना है, बिल्कुल टिकेगा
30 साल पुराना software भी लगातार update हुआ है, और उसकी बुनियाद शुरुआत से ही मज़बूत थी
Joran (TigerBeetle) यहाँ। सामान्य workload में समस्या नहीं होती, लेकिन transaction processing में power law contention की वजह से SQL row lock समस्या बनती है (Amdahl's Law देखें)। हमने theoretical maximum performance limit की गणना करने वाला contention calculator वेबसाइट पर रखा है, देख सकते हैं contetion calculator
DNS भी 1983 में प्रकाशित हुआ था और आज तक इंटरनेट की बुनियाद है। इससे भी दिखता है कि अगर आधार मज़बूत हो तो 30 साल से पुराने systems भी काफ़ी लंबे समय तक टिक सकते हैं। ज़्यादातर workloads के लिए SQL अब भी काफ़ी अच्छा है
हर बार नया और चमकदार tech, पुरानी, आज़माई हुई, सिद्ध tech से बेहतर ही होगा, ऐसा नहीं है। कभी-कभी लगता है कि software engineers पूरे उद्योग में सबसे ‘कम याददाश्त’ वाले engineers हैं
distributed system में दर्जनों DB संभालने हों, तो distributed transactions (जैसे Sagas) ज़रूरी हो जाते हैं। single machine पर relational DB अब भी बेहतरीन है
पुराने hardware पर performance कम थी, लेकिन अब technology इतनी आगे बढ़ चुकी है कि चीज़ें पहले से ज़्यादा तेज़ और बेहतर चलती हैं
FoundationDB के साथ भी TigerBeetle चर्चा के कई बिंदु मिलते-जुलते हैं
धीमी coding, DST, dependency-free approach, production में distributed environment को default मानना, optimistic locking के साथ clock skew को tolerate करना, Jepsen की कठोर testing, testing के लिए नई language (Flow) आदि। FDB से भी लगभग यही समस्याएँ हल की जा सकती हैं, और मेरा मानना है कि TigerBeetle अपने use case के लिए ज़्यादा optimized होगा
FDB के लोकप्रिय न होने का एकमात्र कारण यह है कि उसके लिए अच्छे layers बहुत कम बने हैं। हालाँकि कुछ लोग SQS, DynamoDB, और SQLite layers अलग से बना रहे हैं
FDB के लोकप्रिय न होने की असली वजह Apple है। 2013 में रिलीज़ हुआ, लोगों को प्रोडक्ट इतना पसंद आया कि कंपनी का acquisition हो गया, और उसके बाद पुराने users की सेवाएँ बंद हो गईं। exclusivity खत्म होने के बाद भी भरोसा वापस नहीं आया
FDB टीम के साथ मिलकर DST पर एक पोस्ट भी तैयार की जा रही है
acquisition के बाद क्या हुआ, यह जानने की उत्सुकता है
मैं इसे सचमुच 'the one true database' मानता हूँ
“सभी hyperscalers FDB क्यों नहीं इस्तेमाल करते” यह सवाल पूछकर github पर खोजा, और अंत में पता चला कि यह Apple के अधीन है
हाल में मैंने TigerBeetle की development style को Rust, Go आदि में अपनाने की कोशिश की, और इसे बहुत मज़बूती से recommend करना चाहता हूँ
single entry point, लगभग शून्य dependencies
local में CI, और एक ही command से test/coverage/lint आदि चलाना
property/snapshot/swarm tests के ज़रिए simulation लाने में रुचि जगी
fast/slow का स्पष्ट विभाजन, सभी tests deterministic seed के साथ
explicit upper bound + resource pool management, dynamic allocation वाला code भी समझना आसान हो जाता है
यह सब TB टीम के videos और docs की वजह से संभव हुआ
“production में assertions ऑन रखते हैं” यह बात प्रभावशाली लगी
मुझे कभी समझ नहीं आया कि assertions को बंद क्यों किया जाता था। production में assert fail हो जाए तो तुरंत पता चलना चाहिए (यह एक अलंकारिक बात है)
ऐतिहासिक रूप से assertions बंद करने से performance gain होता था। लेकिन आजकल कुछ extra comparisons का असर बड़ा नहीं होता
मूल रूप से assertion developer API के misuse को रोकने के लिए checks होते हैं। user input stage पर इन्हें proper error messages जैसी business logic में बदलना ज़्यादा उचित है
कभी-कभी ऐसी चीज़ें भी assertion से जाँचना चाहेंगे जिन्हें verify करना आसान नहीं होता। जैसे यह सुनिश्चित करना कि list sorted है
assertion का मूल उद्देश्य compile/test time checks है। अगर इसे prod में इस्तेमाल करना है, तो if statement में बदला जा सकता है। सोचना चाहिए कि assert कहीं सिर्फ़ सुविधाजनक syntactic sugar तो नहीं
काश TB टीम double-entry model को finance के बाहर दूसरे scenarios में भी ज़्यादा फैलाकर समझाए। stocks, concert tickets आदि में भी यह बहुत उपयोगी है। API सुधार अब काफ़ी हो चुके हैं, अब यह बताने का समय है कि इसका उपयोग कैसे किया जाए
मैं analyst हूँ, SQL बहुत इस्तेमाल करता हूँ लेकिन code developer नहीं हूँ। मोटे तौर पर overview और performance benefit समझ में आते हैं। कुछ सवाल हैं a) TigerBeetle की data structure असल में कैसी दिखती है? शायद यह सामान्य table format जैसी नहीं होगी b) अगर SQL queries नहीं लिख सकते, तो इसे कैसे इस्तेमाल किया जाता है c) अगर double-entry model को stocks, tickets आदि पर लागू करें, तो वह कैसा दिखेगा? उदाहरण के लिए, अगर किसी venue के पास 1000 tickets हैं और वह एक बेचता है, तो क्या inventory से cash में, और deferred revenue से performance obligation में एंट्री जाएगी? या ticket बिकने से पहले कोई entry ही नहीं होती?
Postgres में भी इसी तरह का double-entry implementation संभव है
“ज़्यादातर टीमें code जल्दी लिखती हैं, testing को बोझ मानती हैं, और ढेर सारी dependencies जोड़ती जाती हैं” — 25 साल पहले तो यह उलटा था, वही standard था। Google और Facebook के “move fast and break things” culture से पहले लोग बहुत व्यवस्थित तरीके से, धीरे लेकिन अच्छे test के साथ development करते थे। उम्मीद है TigerBeetle को और पहचान मिलेगी। Jepsen report भी पढ़ने लायक है Jepsen report
25 साल बाद देखना दिलचस्प होगा कि TigerBeetle Google बनता है या धीरे लेकिन परिपूर्ण प्रोडक्ट किसी तेज़ competitor से हार जाता है
“Move fast and break things” Facebook का motto था। Google तो उल्टे testing पर काफ़ी ज़ोर देता था। हाँ, वास्तविक requirements के हिसाब से चलना ज़रूरी है, और engineers कई बार बहुत सारी काल्पनिक requirements गढ़कर inefficiency पैदा कर देते हैं। असली users तक जल्दी product पहुँचाना और feedback लेकर उसे सुधारना, ‘bubble’ के अंदर बैठकर अनंत refinement करते रहने से कहीं ज़्यादा मूल्यवान है
ऊपर दिए गए लेख की सामग्री से अलग, TigerBeetle की वेबसाइट खुद भी काफ़ी प्रभावशाली है.
यह किसी बेहद तेज़ चीज़ का एहसास कराती है, और डिज़ाइन ऐसा लगता है कि भारी-भरकम तकनीक की बजाय उसे हल्के-फुल्के अंदाज़ में पेश करने की कोशिश की गई है, इसलिए यह दिलचस्प लगी.
लिंक: https://tigerbeetle.com
सुधार: दोबारा देखने पर यह थोड़ा भारी-भरकम लगता है। फिर भी, सौंदर्य की दृष्टि से यह प्रभावशाली लगा, इसलिए साझा कर रहा/रही हूँ :)
सही है। एनीमेशन तेज़ है, इसलिए यह कंटेंट पर ध्यान देने में बाधा डाले बिना स्क्रीन को नीरस भी नहीं होने देता। और यह TigerBeetle के बेहद तेज़ होने का काफ़ी ज़ोरदार संकेत भी देता है, हाहा।
काफ़ी दिलचस्प है।
आम साइटों की तुलना में animation का समय काफ़ी कम रखा गया है। इसे इस तरह भी सुलझाया जा सकता है...