PostgreSQL का वह हिस्सा जिससे हमें सबसे ज्यादा चिढ़ है (2023)

 (cs.cmu.edu)
4 पॉइंट द्वारा GN⁺ 2024-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PostgreSQL हाल के समय में इंटरनेट का default choice जैसा उभर आया है, लेकिन Carnegie Mellon और OtterTune के अनुभव के अनुसार इसका MVCC implementation MySQL, Oracle, Microsoft SQL Server की तुलना में ज्यादा operational burden डालता है
  • किसी row को update करते समय मौजूदा row को overwrite करने के बजाय नया physical version बनाने वाला append-only storage approach और पुराने version से नए version तक follow करने वाली O2N chain इसकी core design है
  • यह structure पूरे tuple की copy, dead tuple accumulation, सभी indexes के update, और autovacuum dependency की ओर ले जाता है; केवल HOT update संभव होने पर कुछ costs बचाई जा सकती हैं
  • OtterTune customers के PostgreSQL analysis में औसतन करीब 46% updates ने ही HOT optimization का इस्तेमाल किया, और default autovacuum settings बड़े tables में cleanup को लंबे समय तक delay कर सकती हैं
  • PostgreSQL अब भी आकर्षक DBMS है, लेकिन write-heavy workloads और बड़े tables में storage space, I/O, memory, index maintenance और vacuum operations को खुद manage करना पड़ता है

PostgreSQL MVCC समस्या क्यों बनता है

  • Database choices इतने ज्यादा हैं कि अप्रैल 2023 तक DBDB में 897 entries registered थीं, लेकिन अलग-अलग दौर में de facto default choices रही हैं
    • 2000s में Google और Facebook द्वारा इस्तेमाल किया जाने वाला MySQL customary choice था
    • 2010s में MongoDB ने “webscale” image के साथ ध्यान खींचा
    • पिछले 5 वर्षों में PostgreSQL stability, rich features, extensibility और operational workloads के लिए suitability के कारण व्यापक रूप से पसंद किया गया
  • इस लेख का focus PostgreSQL के Multi-Version Concurrency Control (MVCC) implementation पर है
    • Carnegie Mellon की research और Amazon RDS PostgreSQL optimization experience में PostgreSQL के MVCC implementation को MySQL, Oracle, Microsoft SQL Server से खराब आंका गया
    • Amazon Aurora PostgreSQL में भी वही structural problems हैं

MVCC का उद्देश्य और PostgreSQL की design choice

  • MVCC ऐसा तरीका है जिससे कई queries, जहां संभव हो, एक-दूसरे को बाधित किए बिना database को simultaneously read और write कर सकें
    • DBMS मौजूदा rows को overwrite नहीं करता, बल्कि हर logical row के लिए कई physical versions रखता है
    • Query version order, जैसे creation time, के आधार पर अपने लिए सही version पढ़ती है
    • Transaction start time पर database snapshot देखने वाली snapshot isolation संभव हो जाती है
  • Read operations में ऐसी स्थितियां कम हो सकती हैं जहां उसी item को update करने वाले write operation के कारण explicit record lock से blockage हो
  • MVCC DBMS को broadly तीन चीजें तय करनी होती हैं
    • मौजूदा row के updates को कैसे store किया जाए
    • Execution time पर query के लिए सही row version कैसे खोजा जाए
    • जो expired versions अब visible नहीं हैं, उन्हें कैसे हटाया जाए
  • PostgreSQL ने 1980s में जो पहली choice चुनी, उसके कारण बाकी दो क्षेत्रों में भी आज तक burden बना हुआ है

append-only version storage

  • PostgreSQL को शुरुआत से multi-version support के लिए design किया गया था, और update के समय मौजूदा row को overwrite करने के बजाय copy बनाकर नए version पर changes apply करता है
  • इस approach को append-only version storage माना जा सकता है
    • मौजूदा tuple update करने पर DBMS table में नए row version के लिए खाली slot secure करता है
    • Current version की row contents को नए version में copy करता है
    • Newly allocated version slot में changes apply करता है
  • Example table movie information रखने वाली movies table है
    • id primary key है और इसमें name, year, director columns हैं
    • movies_pkey primary index और idx_name, idx_director secondary B+Tree indexes हैं
  • "Shaolin and Wu Tang" की release year 1985 से 1983 में बदलने वाले update में original tuple को copy करने के बाद नए version में changed year apply किया जाता है
    • अगर existing page में space न हो, तो new version किसी दूसरी table page में बनाया जा सकता है

Version chain और O2N approach

  • जब कई physical versions एक ही logical row को represent करते हैं, तो DBMS को versions के बीच relationship record करनी होती है
    • MVCC DBMS one-way linked list के रूप में version chain बनाता है
    • Storage space और maintenance cost घटाने के लिए chain केवल एक direction में जुड़ती है
  • Version chain order दो तरह के होते हैं
    • N2O: latest version previous version की ओर point करता है, और chain का head हमेशा latest version होता है
    • O2N: हर version new version की ओर point करता है, और chain का head सबसे पुराना version होता है
  • Oracle और MySQL सहित अधिकांश DBMS N2O implement करते हैं
  • PostgreSQL, Microsoft SQL Server के In-Memory OLTP engine को छोड़कर, दुर्लभ रूप से O2N इस्तेमाल करता है
    • O2N tuple modify होने पर index को new version की ओर point कराने के लिए update करने की जरूरत कम कर सकता है
    • इसके बदले latest version खोजने के लिए लंबी version chain follow करनी पड़ सकती है
  • PostgreSQL row header का t_tcid field अगले version का tuple ID रखता है, या अगर latest version हो तो अपना ही tuple ID रखता है
    • अगर index old version की ओर point करता है, तो PostgreSQL को chain follow करके new version ढूंढना पड़ता है

Indexes से chain traversal कम करने का तरीका

  • PostgreSQL developers शुरुआती दौर से दो costs जानते थे
    • हर update में पूरे tuple की नई copy बनाना महंगा है
    • अधिकांश queries जिस latest version को चाहती हैं, उसे खोजने के लिए पूरी version chain traverse करना wasteful है
  • PostgreSQL लंबी chain traversal से बचने के लिए row के हर physical version के लिए table index entry जोड़ता है
    • अगर एक logical row के 5 physical versions हैं, तो उस tuple के लिए 5 तक index entries बन सकती हैं
    • अगर idx_name index "Shaolin and Wu Tang" के कई versions की ओर point करता है, तो PostgreSQL latest version तक directly पहुंच सकता है
  • Latest version access तेज हो सकता है, लेकिन index बड़ा होता है और maintenance cost बढ़ती है

HOT update optimization

  • PostgreSQL related versions के कई pages में बिखरने और कई index entries बनने वाली स्थिति घटाने के लिए HOT(heap-only tuple) update इस्तेमाल करता है
  • HOT update possible होने की दो conditions हैं
    • Update table index द्वारा referenced columns को modify न करे
    • New version previous version के समान data page में store हो सके, इसके लिए पर्याप्त space हो
  • HOT apply होने पर index अब भी old version की ओर point करता है, और query version chain follow करके latest version ढूंढती है
  • PostgreSQL normal operation के दौरान old versions हटाकर version chain prune करने वाली optimization भी करता है

dead tuple removal और vacuum

  • PostgreSQL हर update पर row copy बनाता है, इसलिए पुराने version यानी dead tuple को हटाना पड़ता है
  • 1980s के शुरुआती PostgreSQL ने dead tuple हटाए नहीं थे
    • Idea यह था कि old versions रखने से किसी specific point in time का database state देखने वाली time-travel queries चल सकती हैं
    • लेकिन dead tuple न हटाने पर deletes होने के बाद भी table size नहीं घटता, और frequently updated tuples की version chain लंबी होती जाती है
  • PostgreSQL vacuum procedure से table में dead tuple cleanup करता है
    • vacuum last run के बाद modified table pages को sequential scan करता है और expired versions खोजता है
    • कोई version active transactions को visible नहीं है तो उसे expired माना जाता है
    • Current transaction उस version को access नहीं करता और future transactions भी latest live version इस्तेमाल करेंगे, इसलिए space reuse safe है
  • PostgreSQL settings के आधार पर autovacuum को periodically automatically run करता है
    • Global setting से पूरे table की vacuum frequency adjust की जा सकती है
    • Table-level autovacuum settings भी possible हैं
    • Users VACUUM SQL command से manually run कर सकते हैं

समस्या 1: पूरे tuple की copy

  • append-only MVCC में tuple का सिर्फ एक column बदले, तब भी सभी columns new version में copy होते हैं
  • यह approach data duplication और storage space requirements को काफी बढ़ा देता है
    • PostgreSQL को वही database store करने के लिए दूसरे DBMS की तुलना में अधिक memory और disk चाहिए हो सकते हैं
    • Result में queries slow हो सकती हैं और cloud costs बढ़ सकती हैं
  • MySQL और Oracle new version और current version के बीच compressed delta store करते हैं
    • 1000 columns वाली table में सिर्फ एक column बदले, तो केवल changed column का delta record store होता है
    • PostgreSQL changed one column और unchanged 999 columns के साथ new version बनाता है
  • PostgreSQL की TOAST attribute अलग तरह से handle होती है, इसलिए इस comparison से बाहर है
  • EnterpriseDB ने 2013 में append-only storage engine को delta-version-based बनाने के लिए zheap project शुरू किया था
    • आखिरी official update 2021 का status post है
    • उसके बाद कोई स्पष्ट progress नहीं दिखती

समस्या 2: table bloat

  • PostgreSQL के expired versions, यानी dead tuples, delta versions की तुलना में अधिक space लेते हैं
  • write-heavy workloads में autovacuum catch up करे उससे पहले dead tuples तेजी से जमा हो सकते हैं
    • Table लगातार grow कर सकती है
    • Dead tuples और live tuples pages के अंदर mixed होते हैं, इसलिए query execution के दौरान dead tuples भी memory में load करने पड़ते हैं
    • Uncontrolled bloat table scans में IOPS और memory consumption बढ़ाकर query performance घटाता है
    • Dead tuples के कारण optimizer statistics inaccurate हों तो खराब query plans बन सकते हैं
  • Example के तौर पर अगर movies table में 10 million live tuples और 40 million dead tuples हों, तो 80% obsolete data है
    • Average tuple size 1KB हो तो live tuples 10GB और dead tuples करीब 40GB लेते हैं
    • Total table size 50GB है
    • Full table scan में PostgreSQL को अधिकांश obsolete data होने के बावजूद disk से 50GB read करके memory में लाना पड़ता है
  • PostgreSQL में sequential scans द्वारा buffer pool cache को pollute करने से बचाने की protection mechanism है, लेकिन I/O cost को खत्म नहीं करता

VACUUM और VACUUM FULL का अंतर

  • Autovacuum regularly run हो और workload के साथ catch up भी कर ले, फिर भी normal autovacuum storage space operating system को return नहीं कर पाता
  • Normal VACUUM dead tuples हटाता है और हर page के भीतर live tuples rearrange करता है, लेकिन disk के empty pages reclaim नहीं करता
  • अगर PostgreSQL last page खाली कर सके, तो उस page को truncate कर सकता है, लेकिन बाकी pages disk पर रहते हैं
    • 50GB table से 40GB dead tuples हटाने पर भी PostgreSQL OS या RDS perspective से 50GB allocated space maintain कर सकता है
  • Unused space को वास्तव में return करने के लिए VACUUM FULL या pg_repack से पूरी table को नए space में rewrite करना पड़ता है
    • दोनों operations resource-intensive और time-consuming हैं
    • Production database में query performance पर बड़ा impact डाल सकते हैं
  • VACUUM FULL हर page के dead tuples हटाकर remaining live tuples को compress करके new pages में move करता है और unnecessary pages delete करता है

समस्या 3: secondary index maintenance

  • PostgreSQL को एक tuple update करते समय उस table के सभी indexes update करने पड़ते हैं
  • क्योंकि primary index और secondary indexes दोनों version की exact physical location store करते हैं
    • अगर new version previous version वाली same page में stored HOT update नहीं है, तो हर update में यह काम जरूरी है
  • Example update में PostgreSQL new version को Table Page #2 में बनाता है, फिर movies_pkey, idx_director, idx_name में new version की ओर point करने वाली entries insert करता है
  • सभी indexes modify करने वाली structure कई performance costs बनाती है
    • Update query slow हो जाती है
    • हर index traverse करने और new entry insert करने के लिए extra I/O होता है
    • Indexes और buffer pool page table जैसी internal structures में lock/latch contention पैदा होता है
    • Actual query जिन indexes का इस्तेमाल नहीं करती, उनके लिए भी maintenance cost देनी पड़ती है
    • Amazon Aurora जैसे IOPS-based billing वाले DBMS में extra reads और writes problem बनते हैं
  • OtterTune customers के PostgreSQL databases analysis में average करीब 46% updates ने HOT optimization use किया
    • बाकी 50% से ज्यादा updates index maintenance cost उठाते हैं
  • Uber का 2016 का Postgres से MySQL migration पर post इस problem को दिखाने वाला representative case है
    • बहुत सारे secondary indexes वाली table पर write-heavy workload ने बड़ी performance problem झेली
  • Oracle और MySQL में secondary indexes new version का physical address store नहीं करते, इसलिए उनमें वही problem नहीं है
    • Secondary indexes में tuple ID या primary key जैसा logical identifier store होता है
    • DBMS इस logical identifier से current version का physical address खोजता है
    • Secondary index reads slow हो सकते हैं, लेकिन MVCC implementation के दूसरे benefits से overhead कम होता है

समस्या 4: autovacuum operations की कठिनाई

  • PostgreSQL performance obsolete data हटाने और space reuse कराने वाली autovacuum effectiveness पर काफी depend करती है
  • RDS, Aurora, Aurora Serverless सभी PostgreSQL variants हैं, इसलिए उनमें वही autovacuum problems हैं
  • Autovacuum complex है, इसलिए optimal state में चलाना कठिन है
    • Default settings सभी tables के लिए suitable नहीं हैं
    • खासकर बड़े tables में problem बढ़ती है
  • autovacuum_vacuum_scale_factor की default value 20% है
    • 100 million tuple table में autovacuum trigger होने के लिए कम से कम 20 million tuples update होने चाहिए
    • इससे बहुत सारे dead tuples लंबे समय तक table में रहकर I/O और memory costs पैदा कर सकते हैं
  • long-running transaction autovacuum को block कर सकता है
    • expired version cleanup delay होने पर dead tuples और stale statistics जमा होते हैं
    • Performance problems और long-running transactions बनाती हैं, और वे transactions फिर autovacuum को block करते हैं—एक vicious cycle बन सकता है
    • ऐसे cases में इंसान को long-running transaction manually terminate करना पड़ सकता है

OtterTune customer examples

  • एक PostgreSQL Amazon RDS database में dead tuple count 2 सप्ताह तक sawtooth pattern में बदला
    • Autovacuum roughly दिन में एक बार बड़ा cleanup करता था
    • 14 फरवरी को DBMS ने 3.2 million dead tuples cleanup किए
    • पूरे graph में dead tuple count increasing trend पर था, और autovacuum catch up नहीं कर पा रहा था—यह abnormal state थी
  • OtterTune customer के एक PostgreSQL RDS instance में bulk insertion के बाद stale statistics के कारण long-running query हुई
    • इस query ने autovacuum की statistics update को block किया
    • इसके परिणामस्वरूप और long-running queries हुईं
    • OtterTune के automatic health check ने problem identify की, लेकिन administrator को query manually terminate करनी पड़ी और bulk insertion के बाद ANALYZE चलाना पड़ा
    • उस long query का execution time 52 minutes से घटकर 34 seconds हो गया

Practical conclusion

  • DBMS design में हमेशा कठिन choices होती हैं, और choice के अनुसार workloads में performance अलग होती है
  • Uber के specific write-intensive workload में PostgreSQL MVCC से होने वाला index write amplification MySQL migration का reason था
  • PostgreSQL का MVCC implementation ऐसा माना जाता है जिसे नया MVCC DBMS बनाते समय follow नहीं करना चाहिए
    • append-only storage और autovacuum combination core problem है
    • यह design 1980s की legacy है, और 1990s के बाद log-structured system patterns व्यापक होने से पहले का तरीका है
  • PostgreSQL अब भी preferred DBMS है, लेकिन MVCC की weaknesses accept करके operate करना पड़ता है
  • Workaround यह है कि tuning में खुद काफी time और effort लगाया जाए

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

1 टिप्पणियां

 
GN⁺ 2024-10-21
Hacker News की राय

  • मुझे लगा था कि मैं Postgres के internals को काफ़ी जानता हूं, फिर भी यह लेख शानदार था और इससे बहुत कुछ सीखने को मिला
    बुनियादी कमजोरियों में से एक यह लगती है कि Postgres ने row version tracking के लिए N2O के बजाय O2N तरीका चुना। N2O पर बदल देने से सारी समस्याएं हल नहीं होंगी—मसलन पूरी row copy स्टोर करने की समस्या बनी रहेगी—लेकिन 80/20 नज़रिए से मौजूदा implementation की ज़्यादातर कमियां कम हो सकती हैं
    ज़्यादातर transactions को latest row version चाहिए होगा, इसलिए N2O order इस्तेमाल करने पर linked list को सिर्फ़ तब follow करना पड़ेगा जब पुराने version की ज़रूरत हो, और शायद हर row version को index में store करने की ज़रूरत भी न पड़े

    • Andy की YouTube lecture History of Databases(CMU Databases / Spring 2020) देखना अच्छा रहेगा
      वह पहला पूरा class होटल में entry न मिल पाने की वजह से Amsterdam की सड़क पर लेते हैं; उनका character भी दिलचस्प है और internal workings समझाने की क्षमता कमाल की है

  • बड़ा फायदा यह है कि जब workload मुख्य रूप से INSERT और बाद में table deletion से बना हो, तो अतिरिक्त space की ज़रूरत नहीं पड़ती
    आम तौर पर insert transaction को तोड़ने की भी ज़रूरत नहीं होती। वजह यह है कि generated data size या बदली गई कुल rows की संख्या पर practically कोई सीमा नहीं होती। transaction के अंदर statements की संख्या की सीमा है, लेकिन अगर table को बहुत बार नहीं बदलते, तो COPY FROM से bypass किया जा सकता है
    DBA के नज़रिए से rollback/undo space को table storage से अलग manage करने की ज़रूरत नहीं होती। यह application पर निर्भर करता है, लेकिन PostgreSQL design हर लिहाज़ से loser नहीं है। मतलब यह bubble sort जैसा नहीं है

    • 2000s की शुरुआत में game development करते हुए मैंने सीखा कि bubble sort भी हर लिहाज़ से loser नहीं है
      जब list लगभग sorted हो तो performance अच्छी होती है, और 3D rendering में camera से दूरी के आधार पर objects को sort करते समय ऐसा ही होता है। camera को थोड़ा move या rotate करने पर previous frame के order के आधार पर फिर से sort करते समय bubble sort बहुत अच्छा काम करता है
      worst case से बचने के लिए, last pass में failed comparisons की संख्या और अब तक किए गए passes की संख्या count करें, और threshold पार होते ही किसी दूसरे sorting algorithm पर switch कर दें
    • bubble sort hardware या लगभग sorted sets में बेहतरीन है
    • लेख में सचमुच कहा गया है कि pg का MVCC design 90s-स्टाइल का है और अब कोई ऐसा नहीं करता
      यह 30 साल से ज़्यादा पुरानी technology है, इसलिए भले ही हर लिहाज़ से loser न हो, सबसे महत्वपूर्ण पहलुओं में तो loser है, ऐसा मैं मानता हूं

  • मुझे लगता है कि इस लेख में खासकर यह हिस्सा गलत है
    “2000s में conventional wisdom ने MySQL को चुना, क्योंकि Google और Facebook जैसे उभरते tech stars MySQL इस्तेमाल करते थे। 2010s में MongoDB था, जो non-durable writes की वजह से ‘webscale’ बन गया था। पिछले 5 सालों में PostgreSQL internet का पसंदीदा DBMS बन गया है। इसकी वजह भी है! यह reliable है, features से भरपूर है, extensible है, और ज़्यादातर operational workloads के लिए ठीक बैठता है।”
    समझदार engineers ने Postgres को popularity की appeal वाली fallacy की वजह से नहीं, बल्कि data safety, ACID, Oracle से similarity, MVCC, SQL standards compliance, Postgres team, शानदार और मददगार community, data types, high performance, और BSD की flexibility की वजह से चुना था
    2000s की शुरुआत में ATT में Postgres चुनने की वजहें भी यही थीं, और Oracle DBA ने भी transition को बहुत आसानी से स्वीकार किया। जब MySQL rough transition से गुज़र रहा था, PG लगातार मज़बूत और बेहतर होता गया। मुझे लगता है Bruce Momjian ने इस सफलता में बड़ी भूमिका निभाई, और इसकी community सचमुच बेहतरीन है

    • इसी तरह, 2005 में मेरी preference MySQL से PostgreSQL पर shift हो गई थी
      वजह यह थी कि मैं पुराने AS400 database schema और modern Rails app के बीच “live” compatibility layer बनाने के लिए database views इस्तेमाल करना चाहता था
      उसके बाद data safety, transactions के अंदर DDL जैसी चीज़ों की वजह से preference लगातार बढ़ती गई

  • “MySQL और Oracle नए version और current version के बीच compressed delta store करते हैं (इसे git diff जैसा समझें)।”
    Git तो मशहूर तौर पर diff store नहीं करता, बल्कि यहां Postgres जिस तरीके का इस्तेमाल करता है, वैसे नया object और पिछला पूरा object store करता है, है ना?

    • quote किए गए sentence ने यह नहीं कहा कि Git diff store करता है, बल्कि यह कहा कि MySQL और Oracle जो store करते हैं वह git diff जैसा है
    • सही। file का हर version अलग blob होता है
      clone को तेज़ बनाने के लिए packing से compression किया जाता है, लेकिन Git जिस raw form से deal करता है वह ऐसे blobs ही हैं
    • तुलना Git के storage तरीके से नहीं, बल्कि MySQL और Oracle के storage तरीके के git diff format जैसा होने की analogy से थी
      Git repository भी compression करती है, और वह compression एक तरह से diff-based होता है, लेकिन naive expectation की तरह commit history-based नहीं होता
    • मैंने यह point किया था कि दूसरों ने “git diffs” कहा, लेकिन Git असल में pack file में low-level optimization के तौर पर delta इस्तेमाल करता है, और यह MySQL comparison जैसा है
      SQL query में भी diff वैसे का वैसा return नहीं होता
    • Git diff on the fly generate होता है, लेकिन diff फिर भी diff ही है

  • “PostgreSQL को हर update पर table के सभी indexes को modify करने की जो ज़रूरत होती है, उसके कई performance impacts होते हैं। स्वाभाविक रूप से system को ज़्यादा काम करना पड़ता है, इसलिए update queries धीमी हो जाती हैं।”
    मैं इस write amplification को लेकर curious था। यह सही है कि MySQL को उस तरह indexes update करने की ज़रूरत नहीं पड़ती, लेकिन MySQL replication binlog पर निर्भर करता है, और हर change को database itself (InnoDB redo log वगैरह) के अलावा extra record करना पड़ता है
    इसलिए cluster में चलने वाला MySQL किसी दूसरे तरह का write amplification रखता हुआ दिखता है। PostgreSQL replication के लिए WAL reuse करता है, इसलिए उसमें ऐसा amplification नहीं है
    इसके अलावा receiving side पर MySQL incoming binlog को पहले relay log में लिखता है, और relay log को applier thread consume करता है, जिससे extra InnoDB writes और default settings में extra binlog बनता है

  • इस विषय पर डिस्क को हटाकर चर्चा नहीं की जा सकती
    SSD एक बार में 4KB पेज लिखता है। यानी अगर सिर्फ 1 बिट भी अपडेट करें, तो डिस्क 4KB पढ़ती है, बिट बदलती है, और फिर नए स्लॉट में 4KB पेज दोबारा लिखती है। इसलिए कॉपी करने की पेनल्टी डिस्क के प्रकार पर निर्भर करती है

    • दिलचस्प है। सोच रहा हूँ कि यह AWS billing में कैसे दिखता होगा
      AWS IO के MBps के लिए flat rate चार्ज करता है, लेकिन क्या इसमें सबसे नज़दीकी 4KB तक round up करने का नियम है, या request size के बजाय ड्राइव के अपने write volume को track करके storage implementation में वास्तविक IO मात्रा के हिसाब से charge करता है, यह पता नहीं
    • Postgres पेज 8KB का होता है, इसलिए वह point खास मायने नहीं रखता

  • “Oracle और MySQL के MVCC implementation में यह समस्या नहीं है। क्योंकि secondary index नए version का physical address store नहीं करता। इसके बजाय यह logical identifier (जैसे tuple ID, primary key) store करता है, और DBMS इसका उपयोग current version का physical address खोजने के लिए करता है। इस वजह से secondary index reads धीमे हो सकते हैं, लेकिन इन DBMS में MVCC implementation के ऐसे दूसरे फायदे हैं जो overhead घटाते हैं।”
    MySQL में एक दिलचस्प behavior देखा। लगभग 500GB का database था और schema relational से ज्यादा document-oriented जैसा था, जिसमें SELECT id WHERE something; UPDATE what WHERE id=id, UPDATE what WHERE something से कई orders of magnitude तेज़ था
    लगता है इस behavior की वजह शायद यही है। हालांकि आम workloads ऐसा नहीं करते, और सिर्फ inconsistencies ठीक करने वाले अस्थायी DML में ही यह धीमा पड़ता है

    • SELECT read-only operation है, इसलिए parallel में चल सकता है
      इसके उलट UPDATE सच में writes करता है और table को lock भी कर सकता है। UPDATE id=id row-level locking को संभव बनाता है। हालांकि SELECT और UPDATE के बीच में insert हुए नए records छूट जाने का risk भी है
    • कुछ 2TB से बड़े, read-heavy Postgres instances चला रहा हूँ, और ये भी document-oriented के करीब हैं
      मैं सहमत हूँ कि bulk updates बहुत धीमे हो सकते हैं। आखिर में अक्सर updates को batch-wise incrementally process करना पड़ता है, या कभी-कभी COPY तक इस्तेमाल करनी पड़ती है

  • “2010s में यह MongoDB था। non-durable writes की वजह से यह ‘webscale’ बन गया था।”
    विषय से थोड़ा अलग, लेकिन शुरू से अंत तक यह marketing ही था: https://news.ycombinator.com/item?id=15124306

    • MongoDB को पूर्व DoubleClick engineers ने DIY DB के रूप में design किया था, क्योंकि दूसरी service के लिए उनकी requirements पूरी करने वाला कोई DB नहीं था, और यह साथ में बन गया
      version 4.2.8 (2020) तक यह काफी robust हो गया था, और माना जाता है कि इसमें dirty writes नहीं हैं: https://en.wikipedia.org/wiki/MongoDB#Technical_criticisms

  • 2024 में भी इसे usable बनाने के लिए सामने connection pooler (जैसे pgbouncer) रखना पड़ता है, यही सबसे ज्यादा नापसंद है

  • OrioleDB ने नए storage engine के साथ इस समस्या को हल करने की कोशिश की थी: https://github.com/orioledb/orioledb

    • यह Supabase team के पास है
      Oriole अब Supabase में शामिल हो चुका है, और Alexander और उनकी team full-time इस पर काम कर रहे हैं। patchset यहाँ है: https://www.orioledb.com/docs#patch-set
      इस साल के अंत में इसे Supabase platform पर भी इस्तेमाल करके देखा जा सकेगा