PostgreSQL का वह हिस्सा जिसे हम सबसे ज़्यादा नापसंद करते हैं (2023)

 (cs.cmu.edu)
4 पॉइंट द्वारा GN⁺ 2024-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें

PostgreSQL में सबसे नापसंद हिस्सा

  • पिछले 5 वर्षों में PostgreSQL इंटरनेट पर सबसे ज़्यादा पसंद किए जाने वाले DBMS के रूप में स्थापित हुआ है। इसकी वजह इसकी reliability, functionality, scalability, और ज़्यादातर operational workloads के लिए उपयुक्त होना है.
  • हालांकि, PostgreSQL का multi-version concurrency control (MVCC) implementation दूसरे relational DBMS की तुलना में सबसे खराब माना जाता है.

Multi-version concurrency control क्या है?

  • MVCC का लक्ष्य यह है कि कई queries एक ही समय में database को read और write कर सकें, बिना एक-दूसरे में हस्तक्षेप किए.
  • DBMS मौजूदा rows को overwrite नहीं करता, बल्कि कई versions बनाए रखता है ताकि query अपनी request पूरी करने के लिए सही version चुन सके.
  • यह तरीका explicit record locking की ज़रूरत कम करता है और queries को database का snapshot देखने देता है.

PostgreSQL का multi-version concurrency control

  • PostgreSQL मौजूदा row को update करते समय नया version बनाकर बदलाव लागू करता है, यानी यह append-only version storage तरीका इस्तेमाल करता है.
  • यह तरीका कई जटिल समस्याएँ पैदा करता है.

Multi-version storage

  • PostgreSQL सभी row versions को एक ही storage space में रखता है.
  • Update के समय नया version slot allocate किया जाता है, पुराना version copy किया जाता है, और फिर उस पर बदलाव लागू किए जाते हैं.
  • PostgreSQL versions के बीच संबंध दर्ज करने के लिए version chain का उपयोग करता है.

Version vacuum

  • PostgreSQL पुराने versions को हटाने के लिए vacuum प्रक्रिया का उपयोग करता है.
  • Autovacuum नियमित रूप से चलकर expired versions हटाता है और space को फिर से उपयोग में लाता है.

PostgreSQL का MVCC सबसे खराब क्यों है

  • PostgreSQL का MVCC implementation 1980s की design पर आधारित है, और यह आधुनिक log-structured system patterns के साथ मेल नहीं खाता.
  • इसमें PostgreSQL के MVCC से जुड़ी चार मुख्य समस्याएँ बताई गई हैं.

समस्या 1: Version copy

  • PostgreSQL हर column को नए version में copy करता है, जिससे data duplication और storage requirement बढ़ जाती है.
  • MySQL और Oracle delta store करके इस समस्या से बचते हैं.

समस्या 2: Table bloat

  • PostgreSQL के expired versions space घेरते रहते हैं, और अगर autovacuum उन्हें हटा न सके तो database लगातार बढ़ता रहता है.
  • इससे query performance खराब होती है.

समस्या 3: Secondary index maintenance

  • PostgreSQL को हर update पर सभी indexes update करने पड़ते हैं.
  • इससे query performance खराब होती है.

समस्या 4: Vacuum management

  • PostgreSQL की performance काफी हद तक autovacuum की effectiveness पर निर्भर करती है.
  • अगर autovacuum सही से काम न करे, तो performance problems पैदा होती हैं.

GN⁺ का सार

  • PostgreSQL अब भी बहुत पसंद किया जाने वाला DBMS है, लेकिन इसका MVCC implementation आधुनिक नहीं है.
  • PostgreSQL की MVCC समस्याओं को हल करने के लिए बहुत समय और मेहनत की ज़रूरत है.
  • PostgreSQL की autovacuum settings को optimize करके performance बेहतर की जा सकती है.
  • PostgreSQL की MVCC समस्याओं के विकल्प के रूप में MySQL और Oracle पर विचार किया जा सकता है.

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

1 टिप्पणियां

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

  • OrioleDB ने नए storage engine के साथ समस्या हल करने की कोशिश की

    • अगर ज़्यादातर INSERT ऑपरेशन होते हों, तो अतिरिक्त space की ज़रूरत नहीं होती
    • transaction के भीतर statements की संख्या पर सीमा है, लेकिन COPY FROM का उपयोग करके इससे बचा जा सकता है
    • DBA के नज़रिए से rollback/undo space को अलग से मैनेज करने की ज़रूरत नहीं होती

  • PostgreSQL का डिज़ाइन हर मायने में खराब नहीं है

    • MySQL और Oracle नए version और current version के बीच compressed delta स्टोर करते हैं
    • git diff स्टोर नहीं करता, बल्कि PostgreSQL की तरह पूरा object स्टोर करता है

  • Oracle और MySQL के MVCC implementation नए version का physical address स्टोर नहीं करते

    • इसके बजाय वे logical identifier स्टोर करते हैं ताकि DBMS current version का physical address ढूंढ सके
    • इससे secondary index read धीमा हो सकता है, लेकिन दूसरे फ़ायदों के कारण overhead कम होता है

  • MySQL में single row update करते समय SELECT id WHERE something; UPDATE what WHERE id=id काफ़ी तेज़ होता है

    • आम कामों में यह तरीका इस्तेमाल नहीं होता, और इससे one-off DML धीमा हो जाता है

  • 2010 के दशक में MongoDB को non-durable writes की वजह से "webscale" माना जाता था

    • यह marketing का नतीजा था

  • pg_repack के बारे में दी गई व्याख्या से सहमत नहीं हूँ

    • VACUUM FULL भारी है, लेकिन repack एक तेज़ और हल्का विकल्प है

  • PostgreSQL के लोकप्रिय होने के कारण ये रहे

    • data safety, ACID, Oracle से समानता, MVCC, SQL standard compliance, Postgres team, community, data types, high performance, BSD flexibility
    • PostgreSQL लगातार आगे बढ़ रहा है, और इसमें community की बड़ी भूमिका है

  • यह सवाल है कि PostgreSQL का पूरे नए row-tuple version को स्टोर करना क्या default storage engine की विशेषता है

  • लेख अच्छी तरह लिखा गया था, इसलिए पढ़ना और समझना आसान था

    • vacuum से जुड़ी समस्याओं को समझने में मदद मिली, और diagrams भी अच्छे थे