PostgreSQL: अब न VACUUM, न Bloat

 (orioledata.com)
2 पॉइंट द्वारा GN⁺ 2023-07-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PostgreSQL के लिए नया storage engine OrioleDB resource-heavy VACUUM process को हटाता है और table Bloat की समस्या हल करता है
  • मौजूदा PostgreSQL में MVCC structure की वजह से manual vacuum और autovacuum की जरूरत होती है, और दोनों ही तरीकों में काफी system resources लगते हैं
  • OrioleDB row- और block-level undo log और automatic page merging के जरिए data changes को efficiently handle करता है और fragmented data को consolidate करता है
  • synthetic benchmark में केवल एक index update करना, sparse pages का automatic merge, और row-level WAL लागू करके 5x higher TPS और resource savings हासिल की गईं
  • VACUUM जैसी पुरानी कठिन समस्या को हल करके maintenance burden घटाता है और PostgreSQL की performance और user experience में सुधार देता है

PostgreSQL VACUUM का इतिहास और सीमाएं

  • VACUUM process Berkley Postgres project के infinite time-travel concept से निकला एक historical artifact है; इस concept को बाद में community ने छोड़ दिया
    • लेकिन इससे table Bloat के प्रति vulnerable MVCC(Multi-Version Concurrency Control) system implementation बना
  • MVCC concurrent transaction processing के लिए फायदेमंद है, लेकिन पुराने और बेकार data को साफ करने के लिए manual vacuuming की जरूरत लाता है
    • manual vacuuming labor-intensive काम है और system inefficiency का potential कारण भी
  • बाद में manual work का burden कम करने के लिए automated autovacuum पेश किया गया
    • यह बड़ा improvement था, लेकिन perfect solution नहीं था; automatic होने के बावजूद इसमें काफी system resources लगते हैं
    • इसे Uber के PostgreSQL से MySQL पर migrate करने के कारणों में से एक और Richard Branson द्वारा बताई गई PostgreSQL की 10 complaints में से एक के रूप में mention किया गया
  • Heap-Only Tuples(HOT) updates और microvacuum आने से full table vacuum की जरूरत कम हुई
    • फिर भी VACUUM resource-intensive operation बना रहा, और tables Bloat के प्रति vulnerable रहीं
    • इसे OtterTune team द्वारा सबसे नापसंद PostgreSQL हिस्से के रूप में mention किया गया
  • इन सीमाओं के बावजूद robustness, extensibility और strong community जैसे कारणों से कई organizations और developers PostgreSQL का इस्तेमाल जारी रखते हैं
    • OtterTune ने problem स्वीकार करते हुए भी PostgreSQL इस्तेमाल जारी रखने का फैसला किया

OrioleDB की core features

  • OrioleDB एक नया PostgreSQL engine है, जिसे मुख्य तौर पर tables को Bloat से बचाने और VACUUM जैसी regular maintenance की जरूरत हटाने के लक्ष्य से develop किया गया है
  • यह row-level और block-level undo log और automatic page merging से इसे लागू करता है
    • row और block level undo log ज्यादा fine-grained control देते हैं, जिससे data changes efficiently process होते हैं
    • automatic page merging feature background में fragmented data को लगातार consolidate करता है
  • हर technique का काम करने का तरीका
    • row-level undo log in-place updates allow करता है
    • block-level undo log उन tuples को primary storage से हटाता है जो delete हो चुके हैं लेकिन कुछ transactions को अभी भी visible हैं, ताकि नए tuples के लिए space मिले
    • sparse pages की automatic merging कई deletes के बाद भी tables और indexes को Bloat से बचाती है
  • नतीजतन manual intervention कम होता है, resource consumption घटता है और table Bloat के प्रति vulnerability कम होती है

Benchmark

  • एक initialization script से synthetic benchmark बनाया गया, जो 1 table और 5 indexes create करती है
    • id primary key और value1~value4(float8), ts(timestamp) columns वाली test table create की गई
    • value1, value2, value3, value4, ts पर अलग-अलग indexes create किए गए
  • pgbench script conflict होने पर एक index को sparsely update करने वाले upsert format में है
    • 1~10,000,000 range के random id से INSERT perform करती है; conflict होने पर सिर्फ ts update करती है
    • यह sparse update सामान्य heap PostgreSQL tables में index Bloat पैदा करता है
  • यह benchmark OrioleDB design के फायदे दिखाता है
    • undo log और in-place updates की वजह से OrioleDB केवल उस एक index को update करता है जिसका value बदला है, जबकि PostgreSQL heap engine में single index field update HOT को ineffective कर देता है और सभी indexes update होते हैं
    • automatic page merging sparse indexes को Bloat से बचाती है, और sparse pages automatically merge हो जाते हैं
    • row-level WAL, block-level WAL की तुलना में काफी कम space लेता है, जिससे WAL लिखते समय IOPS घटता है
  • cumulative improvements के परिणामस्वरूप OrioleDB ये numbers देता है
    • प्रति transaction 5x higher TPS
    • प्रति transaction 2.3x lower CPU load
    • प्रति transaction 22x lower IOPS
    • table और index Bloat नहीं

OrioleDB का महत्व

  • OrioleDB अपनाने से PostgreSQL community एक ऐसे नए दौर में प्रवेश करती है, जहां VACUUM अतीत की बात बन जाता है
  • यह PostgreSQL की सबसे पुरानी कठिन समस्याओं में से एक का solution पेश करता है, और users को बेहतर efficiency और कम maintenance burden देता है

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

1 टिप्पणियां

 
GN⁺ 2023-07-16
Hacker News की टिप्पणियाँ

  • फिर भी कुछ बातें खटकती हैं। row-level processing write ordering और fsync ordering की समस्या पैदा करता है, और variable-sized rows की तुलना में pages को order करना आसान होता है
    PostgreSQL data safety को लेकर बहुत, शायद बेहद conservative है, और यह मुख्यतः सही समय पर fsync करके हासिल किया जाता है, जिसका असर SSD firmware समेत पूरे I/O stack में फैलकर performance को धीमा कर देता है
    MVCC concurrent access के लिए बहुत अच्छा है, लेकिन Oriole के दस्तावेज़ यह नहीं बताते कि graph किन concurrency conditions में निकाले गए थे
    Oriole दस्तावेज़ का title और introduction VACUUM समाधान पर फोकस करते हैं, लेकिन ऐसा नहीं लगता कि उन्होंने यह साबित किया है कि PostgreSQL में दिखने वाला “square wave” graph वास्तव में ज़्यादातर VACUUM की वजह से है। Percona के दूसरे benchmark(https://www.percona.com/blog/evaluating-checkpointing-in-postgresql/) में ऐसा स्पष्ट square-wave pattern नहीं दिखता
    चूंकि authors भी शायद इन मुद्दों से वाकिफ होंगे, वे यह भी लिख सकते थे कि उन्होंने इसे कैसे approach किया

    • OrioleDB row-level WAL का उपयोग करता है, लेकिन फिर भी pages का इस्तेमाल करता है। row-level WAL copy-on-write checkpoints की वजह से संभव हुआ है, और यह B-tree की structurally consistent image देता है। अधिक जानकारी के लिए architecture document देखें
      https://github.com/orioledb/orioledb/blob/main/doc/arch.md
      PostgreSQL के data safety के प्रति conservative होने की वजह से, पहला लक्ष्य pure extension बनना है। PostgreSQL का हिस्सा बनने के लिए समय की कसौटी पर खरा उतरना होगा
      concurrency जानकारी छूटी थी, यह सही है, और blog post में VM type और concurrency जानकारी जोड़ दी गई है
      square-wave pattern वास्तव में checkpoint की वजह से ही बना था। यहाँ improvement का कारण असल में VACUUM नहीं, बल्कि केवल संबंधित indexes को modify करने का तरीका, और पूरे I/O को कम करने वाला row-level WAL है

  • यह बढ़िया है, लेकिन सोच रहा हूँ कि parent project के release cycle के साथ चलने की योजना क्या है
    आपने एक बड़े open source project को fork करके उस पर काफी बड़े बदलाव किए हैं, और अगर आपको नहीं लगता कि ये बदलाव upstream में स्वीकार किए जाएंगे, तो पता नहीं यह अच्छा विचार है या नहीं
    यह साफ होना चाहिए कि यह मज़े के लिए बनाया गया toy है, या आगे maintain किया जाने वाला गंभीर project
    अगर यह गंभीर project है, तो यह बताना चाहिए कि इसे भविष्य में abandoned software बनने से बचाने की क्या योजना है, मूल project की आगे की releases को absorb करने की क्या योजना है, या फिर इसे पूरी तरह अलग project के रूप में ले जाने की योजना है
    चूंकि यह extension है, इसलिए लगता है कि PostgreSQL upstream changes लेना संभव होगा, लेकिन अगर यह आसान होता तो शायद यह शुरू से ही PostgreSQL project का हिस्सा बन गया होता, इसलिए यह इतना आसान नहीं लगता

    • लेखक ने पोस्ट की एक reply में इसका जवाब पहले ही दे दिया था
      “हाँ, सही है। लेकिन अभी लंबा रास्ता बाकी है। फिलहाल OrioleDB PostgreSQL core patches के साथ आने वाला extension है। मध्यम अवधि का लक्ष्य OrioleDB को pure extension बनाना है, और दीर्घकालिक लक्ष्य OrioleDB को PostgreSQL core का हिस्सा बनाना है”
    • जबकि कोई इसे आने वाले कुछ दिनों में production में इस्तेमाल करने नहीं जा रहा, यह कुछ ज़्यादा ही aggressive लगता है। आप project को आर्थिक रूप से support करने की बात भी नहीं कर रहे, और जैसा कि दूसरों ने बताया, इस सवाल का जवाब पहले से मौजूद था
      अगली बार शुरुआत से इतना hard-hitting न होना बेहतर होगा
    • इसका एक reference link है जिसका जवाब पहले ही दिया जा चुका है :)
      https://news.ycombinator.com/item?id=36742001
    • यह वाजिब बात है। पहले VACUUM की समस्या झेल चुके व्यक्ति के तौर पर, मैं सोच रहा था कि क्या यह मूल रूप से ज़रूरी चीज़ है, या ऐसी चीज़ है जिसे ठीक किया जा सकता है
      इसका ठीक किया गया उदाहरण देखना अपने आप में निश्चित रूप से मददगार है। अगर किसी कंपनी के पास Postgres fork को maintain करने के संसाधन हैं, तो बढ़िया; नहीं तो उसे यह आकलन करना होगा कि इस fork को इस्तेमाल करने की कठिनाई performance gains की तुलना में स्वीकार करने लायक है या नहीं

  • “Uber ने Postgres से MySQL पर माइग्रेट किया” जैसी बातें अब बंद होनी चाहिए। Uber ने Postgres जैसे relational database से MySQL को एक distributed key-value store के रूप में इस्तेमाल करने वाली, व्यावहारिक रूप से अपनी खुद की non-relational database में माइग्रेट किया था, इसलिए यह स्थिति ज़्यादातर Postgres उपयोगकर्ताओं पर वैसे की वैसे लागू नहीं होती
    वैसे भी, पुराने डेटा को undo log/segment में ले जाने वाला ऐसा MVCC डिज़ाइन Oracle DB में भी इस्तेमाल होता है, इसलिए इसका काम करना अपने आप में प्रमाणित है
    आम कठिनाई यह है कि डेटा के पुराने versions को पढ़ने की गति धीमी हो जाती है। उन्हें log में ढूंढना पड़ता है, और कभी-कभी transaction खत्म होने से पहले ही log से डेटा हट जाता है, जिससे बदनाम Snapshot Too Old error आ सकता है
    लेख में यह नहीं दिखा कि row को undo log से कब हटाया जाता है। अगर उसे तब हटाया जाता है जब उसकी ज़रूरत नहीं रहती, तो लगभग उतनी ही मात्रा का maintenance work चाहिए होगा; ऐसे में सुधार कहाँ से आता है, यह स्पष्ट नहीं है। और अगर Oracle की तरह यह space खत्म हो सकने वाला circular buffer है, तो high write load में लंबे समय तक चलने वाले transactions fail होने लगेंगे, जो काफ़ी अप्रिय है

    • undo records तब truncate किए जाते हैं जब किसी भी transaction को उनकी अब और ज़रूरत नहीं रहती
      “maintenance work” से ठीक-ठीक क्या मतलब है, इस पर निर्भर करता है। अगर workload की बात करें, तो पुराने undo records को file unlink करके बहुत सस्ते bulk deletion में हटाया जा सकता है, इसलिए यहाँ सुधार मिलता है। VACUUM scan की ज़रूरत नहीं होती
      अगर space usage की बात करें, तो versions की समान संख्या लगभग उतनी ही space लेगी, यह सही है। लेकिन पुराने row versions को अलग storage में रखने से primary storage के long-term degradation को रोका जा सकता है। OrioleDB sparse pages की automatic merge भी implement करता है
      OrioleDB undo log के लिए memory के अंदर circular buffer implement करता है। अगर circular buffer सभी undo records को संभाल नहीं पाता, तो सबसे पुराने records को storage में spill कर दिया जाता है। अभी undo log size पर कोई limit नहीं है, और records को तब तक रखा जाता है जब तक किसी भी transaction को उनकी ज़रूरत हो सकती है, इसलिए “Snapshot Too Old” error नहीं आता
      हालांकि, undo size को limit करने के लिए Oracle-style error को एक option के रूप में implement करने पर विचार किया जा सकता है। GitHub का architecture document भी देखना उपयोगी होगा
      https://github.com/orioledb/orioledb/blob/main/doc/arch.md
    • SQL Server भी VACUUM से बचता है, शायद किसी ऐसे ही तरीके से
      बेशक, MySQL concurrency के मामले में काफ़ी समझौता करके VACUUM से बचता है

  • शीर्षक ने उत्साहित किया था, लेकिन पहली छाप निराशाजनक रही। GitHub का main README[1] corporate-style promotional copy जैसा लगता है
    अभी तक जो समझ में आया है, वह बस इतना है कि OrioleDB PostgreSQL के लिए एक नया storage engine है, PostgreSQL “सबसे प्रिय” database है, OrioleDB दूसरे extensions के ऊपर बना एक extension है, और OrioleDB cloud के दरवाज़े खोलता है
    cryptocurrency और Web 3.0 scams के दौर के बाद, PostgreSQL जैसी महत्वपूर्ण चीज़ को extend और improve करने वाले project को public करते समय मैं शायद इस तरह का approach टालता
    [1] https://github.com/orioledb/orioledb

    • शायद बात इस हिस्से की हो रही है: “OrioleDB consists of an extension, building on the innovative table access method framework and other standard Postgres extension interfaces.”
      इससे ज़्यादा स्पष्ट लिखना शायद मुश्किल है। table access method वह feature है जो PostgreSQL में zheap जैसी alternative storage schemes या column-oriented stores को support करने के लिए जोड़ा गया था
      इसका ज़िक्र करना महत्वपूर्ण है। PostgreSQL के ऊपर alternative data storage system चढ़ाने वाले कई PostgreSQL forks मौजूद हैं, लेकिन OrioleDB को non-forked PostgreSQL पर extension के रूप में काम करने के लिए डिज़ाइन किया गया है। अभी यह पूरी तरह वहाँ नहीं पहुँचा है, लेकिन दिशा वही है
      अगर आप PostgreSQL से परिचित हैं, तो README काफ़ी स्पष्ट लगता है

  • Oriole का डिज़ाइन transaction-aware indexes और point-wise entry removal की माँग करता हुआ लगता है, और इसकी अपनी अलग लागत है
    उदाहरण के लिए, spatial indexes के लिए GiST जैसा कुछ maintain करना मुश्किल लग सकता है, क्योंकि इसकी प्रकृति ऐसी है कि हर index tuple की सटीक position पता नहीं होती; और full-text search indexing के लिए GIN जैसा कुछ posting tree की कम compressibility के कारण बहुत बड़ा हो सकता है
    इसके अलावा, index-organized table इस्तेमाल होने की स्थिति में BRIN जैसा कुछ कैसे implement होगा, यह भी सहज नहीं लगता। BRIN दिलचस्प डेटा न होने पर physical table के बड़े ranges को query result से जल्दी बाहर कर सकता है। आप primary key range के आधार पर partition कर सकते हैं, लेकिन primary key values की density समय और value range के हिसाब से बहुत बदल सकती है
    मैं जानना चाहूँगा कि इन अधिक जटिल लेकिन बहुत उपयोगी index methods को कैसे implement करने की योजना है
    collation बदलने पर पैदा हो सकने वाली समस्याएँ भी हैं। Postgres का heap और VACUUM sort order नहीं जानते, इसलिए collation बदलने के बाद गलत जगह मौजूद rows को delete करके फिर दोबारा insert कर दिया जाए, तो VACUUM अंततः टूटे हुए tuples को साफ़ कर देता है और कई बार corruption ठीक हो सकती है
    Oriole में ऐसा करना मुश्किल लगता है, क्योंकि हटाए जाने वाले original tuple को point lookup से ढूँढा नहीं जा सकेगा। इसलिए known index corruption cases को ठीक करने के लिए शायद पूरा index rebuild करना पड़े, जो maintenance burden को काफ़ी बढ़ाता दिखता है

    • GiST-जैसी functionality के लिए हम किसी space-filling curve पर B-tree बनाने का विचार कर रहे हैं। internal pages में union key जोड़कर इस tree search को और तेज़ व सरल बनाने की भी योजना है
      GIN-जैसी functionality में posting list compression अभी भी संभव है। एक संभावित विकल्प यह है कि undo records को किसी एक posting list item से नहीं, बल्कि पूरी posting list से जोड़ा जाए
      BRIN का सीधा equivalent बन पाना संभव नहीं लगता, क्योंकि इसमें index-organized table का उपयोग होता है। हालांकि primary key के internal pages में मौजूद union key के साथ कुछ दिलचस्प किया जा सकता है
      collation वाली समस्या सही है और गंभीर भी। GA से पहले, collation-aware सभी indexes को किसी खास libicu collation version पर pin करना पड़ेगा

  • लेख की दलीलें भी काफ़ी भरोसेमंद लगती हैं और benchmark भी performance के दावों का समर्थन करते दिखते हैं, लेकिन प्रस्तावित नए storage engine, यानी OrioleDB, और PostgreSQL खुद के बीच का फर्क अच्छी तरह समझ नहीं आ रहा।
    commercial motivation और लेख में बताई गई innovations से कमाई करना चाहने की वजह के अलावा, इसे upstream में contribute करने के बजाय OrioleDB नाम के एक नए database के रूप में market करने की कोई वजह है क्या?

    • OrioleDB को PostgreSQL के future engine के रूप में देखा जा रहा है, और चाहत है कि यह default engine बने।
      लेकिन OrioleDB के बदलाव इतने बड़े हैं कि उन्हें धीरे-धीरे शामिल करना संभव नहीं है। इसलिए मौजूदा PostgreSQL engine, यानी heap के साथ-साथ कई lower-level subsystems समेत, और OrioleDB की तुलना की जा रही है।
    • Alexander Korotkov की सोच शायद Postgres committer के अनुभव पर आधारित है: ये बदलाव इतने बड़े हैं कि upstream में स्वीकार होना मुश्किल है, इसलिए अलग engine के रूप में जाना पड़ रहा है।
      अधिक जानकारी के लिए https://www.socallinuxexpo.org/sites/default/files/presentations/solving-postgres-wicked-problems.pdf देखें, खासकर स्लाइड 9~11।
    • ये बदलाव PostgreSQL engine में सीधे integrate करने के लिए बहुत बड़े हैं, क्योंकि ये MVCC पद्धति को बुनियादी रूप से बदल देते हैं।

  • अगर यह engine extension है, तो उत्सुकता है कि दूसरे extensions के साथ इस्तेमाल करने पर इसका क्या असर होगा। उदाहरण के लिए timescaledb[0] child tables पर काम करता है।
    इस तरह करने पर क्या प्रभाव होगा, यह जानना दिलचस्प होगा।
    create table xyz(...) using orioledb;
    select create_hypertable(xyz, ts);
    [0] https://github.com/timescale/timescaledb

  • क्या OrioleDB एक स्थिर on-disk format का वादा करके Postgres major versions के बीच upgrade procedure की ज़रूरत खत्म करने में रुचि रखेगा? यह उस समस्या को हल करने का एक मौका लगता है।

    • PostgreSQL में upgrade procedure की ज़रूरत आम तौर पर Postgres heap या OrioleDB table access method के low-level on-disk format की वजह से नहीं, बल्कि Postgres catalog changes की वजह से होती है।
      नई types और उन्हें support करने वाले functions जोड़ने जैसी चीज़ें किसी upgrade procedure के ज़रिए insert करनी पड़ती हैं। catalog tables के column layout बदलने वाले दूसरे catalog changes भी होते हैं, और उस स्थिति में भी versions के बीच stored data को update करने की प्रक्रिया चाहिए होती है।
      अगर upgrade procedure न हो, तो catalogs को बदला नहीं जा सकता। इसी वजह से PostgreSQL में सिर्फ minor version upgrades ही binary replacement भर से संभव हैं और बिना समस्या के सुरक्षित rollback भी किए जा सकते हैं।
      अगर upgrades को केवल internal API, planner, और executor changes तक सीमित कर दिया जाए, तो development पर गंभीर पाबंदी लग जाएगी। OrioleDB शायद इस upgrade procedure की ज़रूरत खत्म नहीं कर पाएगा।
    • ऊपर-ऊपर से देखें तो यह हासिल करना मुश्किल लगता है, जब तक कि काफ़ी performance छोड़ने की तैयारी न हो। on-disk format तभी बदला जाता है जब उसके पीछे ठोस वजह हो।
    • यह कैसे मदद करेगा, यह साफ़ नहीं है। PostgreSQL पहले से ही tables और indexes के लिए व्यावहारिक रूप से स्थिर on-disk format का वादा करता है, तभी तो pg_upgrade काम करता है।
      cluster upgrade का ज़्यादातर काम catalog tables को फिर से लिखने में जाता है। और ज्यादातर workloads में pg_upgrade पहले ही बहुत तेज़ होता है, इसलिए यह भी स्पष्ट नहीं है कि बड़ा फ़ायदा आखिर कहाँ मिलेगा।

  • “प्रति transaction CPU overhead 2.3 गुना कम” वाली अभिव्यक्ति थोड़ी खटकती है। Postgres का CPU उपयोग 5% से 65% तक ऊपर-नीचे होता है, जबकि Oriole लगातार 90% पर रहता है
    predictability अच्छी है, लेकिन निचले हिस्से को 85% तक ऊपर खींच देना काफ़ी चिंता की बात नहीं है क्या?

    • आम तौर पर CPU का अधिकतम उपयोग करना अच्छा होता है। लगता है Oriole की I/O मांग बहुत कम है, इसलिए वह कहीं ज़्यादा transactions संभाल रहा है और CPU bottleneck की स्थिति में पहुँच गया है
      अच्छी बात यह है कि इसका मतलब है कि अगर ज़्यादा शक्तिशाली CPU के साथ vertical scaling करें, तो Oriole में और अधिक performance मिल सकती है। वहीं Postgres में performance इसी तरह आगे नहीं बढ़ेगी
      desktop operating system के नज़रिए से देखें तो Postgres server का idle time किसी और काम में इस्तेमाल किया जा सकता है, लेकिन server में आम तौर पर एक ही काम होता है और उसी काम के लिए optimized machine चाहिए होती है
    • मेरी समझ से ऐसा इसलिए है क्योंकि comparison में इस्तेमाल किया गया TPS threshold CPU को 90% तक saturate कर देता है। कम से कम इस chart में Oriole का TPS स्थिर है और pg से काफ़ी ज़्यादा है
      TPS कम करेंगे तो CPU भी अनुपात में नीचे आएगा, और यहाँ शायद दिखाना यह है कि यह कितना ऊपर तक जा सकता है
    • अगर CPU usage की upper limit हट जाए, तो usage कम रखते हुए भी कुछ हद तक proportional performance बनाए रखना आसान हो जाता है, इसलिए यह समस्या नहीं है
      अगर system को CPU 60% पर सीमित करें तो कुल आँकड़े बदल सकते हैं, लेकिन उसी usage पर TPS 1.8 गुना है तो फिर भी यह जीत ही है। यह marketing trick से ज़्यादा एक काफ़ी अच्छा number लगता है
      अगर महँगा server CPU प्रति unit X डॉलर का है, लेकिन आप उसका सिर्फ 60% ही इस्तेमाल कर सकते हैं और व्यावहारिक रूप से उतना ही कर पाते हैं, तो आप प्रति unit 0.4X डॉलर जला रहे हैं
      अगर workload को vertically ले जाकर एक machine के 90% तक saturate किया जा सकता है, तो आम तौर पर QoS और isolation techniques लगाकर कम saturation और proportional performance बनाए रखना आसान होता है। उल्टा ऐसा नहीं होता। अगर आप पूरी machine saturation का सिर्फ 60% ही इस्तेमाल कर पाते हैं और scale-out करना पड़ता है, तो 90% से ऊपर जाने के लिए redesign चाहिए, और यहाँ वही redesign हुआ है
    • अब उसी hardware पर performance 5 गुना बेहतर हो गई है। TPS 5 गुना ज़्यादा है। इसे ज़्यादा hardware के साथ फिर test करना चाहिए, लेकिन अगर निचले हिस्से में भी 3 गुना performance बनी रहती है, तो कुछ users के लिए यह अच्छा alternative हो सकता है
      कहा गया है कि improvements के cumulative result के रूप में OrioleDB 5 गुना ज़्यादा TPS, प्रति transaction 2.3 गुना कम CPU load, प्रति transaction 22 गुना कम IOPS, और table व index bloat न होने जैसी विशेषताएँ देता है
    • यह performance test था, और संभव है कि मकसद हर DB engine पर वह अधिकतम load लंबे समय तक लगातार डालना था, जिसे वह संभाल सकता है
      CPU load का ऊपर-नीचे होना इस बात का संकेत नहीं कि Postgres “scaling” कर रहा है, बल्कि यह कि वह समय-समय पर performance bottleneck से टकरा रहा है। शायद VACUUM चलाने की ज़रूरत की वजह से, और यह I/O के प्रति बहुत sensitive है
      इसलिए Postgres queries process करने के लिए I/O इस्तेमाल करने के बजाय cleanup काम में I/O खर्च करता है, और TPS तथा CPU usage दोनों साथ में गिर जाते हैं
      दूसरी ओर Oriole कहीं अधिक throughput को कहीं अधिक consistency के साथ संभालता है। accelerator दबाने पर लगातार 100mph से चलने वाली कार पसंद करेंगे, या वह कार जिसमें pedal पूरी तरह दबा हो फिर भी speed 40~70mph के बीच बुरी तरह डगमगाती रहे?

  • लेख में “Richard Branson की PostgreSQL के बारे में नापसंद 10 बातें” जैसा काफ़ी दिलचस्प शीर्षक वाला एक link है। बाद में पता चला कि वह blog लिखने वाला Richard नहीं बल्कि Rick Branson था

    • Rick, Richard का nickname है
    • “Richard Branson” कोई unique identifier नहीं है। शायद हम सबको UUID इस्तेमाल करना चाहिए
    • मेरी नज़र भी उसी हिस्से पर गई थी। मैंने सोचा, Virgin CEO databases के बारे में क्या सोचता है, इससे मुझे भला क्यों फ़र्क पड़ना चाहिए?
      आह, वह वही आदमी नहीं था