29 पॉइंट द्वारा xguru 2021-10-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इस साल की शुरुआत में 5 मिनट के लिए Notion डाउन करके, कई महीनों से चल रहे PostgreSQL sharding को पूरा किया

→ तुरंत प्रतिक्रियाएँ आने लगीं कि यह बहुत तेज़ हो गया है

  • sharding करने का फैसला कब किया गया

→ 5 साल में कई दस-हज़ार गुना बढ़ने के साथ, अच्छी तरह काम कर रहा Postgres monolith अपनी क्षमता से आगे जाने लगा

→ VACUUM लगातार रुकने लगा था, और जल्द ही TXID wraparound होने की आशंका थी, इसलिए sharding का काम शुरू किया गया

  • sharding scheme डिज़ाइन करना

→ application-level sharding

⇨ कौन-सा data shard किया जाएगा

⇨ किस key से partitioning करके data को बाँटा जाएगा

⇨ कितने shard बनाए जाएँ, और उन्हें कैसे व्यवस्थित किया जाए

→ फ़ैसला #1

⇨ Notion का data model block इकाई पर बना है

⇨ block table से जुड़ी सभी tables को shard करने का फैसला किया गया (Space, Discussion, Comment आदि)

→ फ़ैसला #2

⇨ block को workspace ID के आधार पर partition किया गया

⇨ हर workspace को UUID दिया जाता है, इसलिए उसी का उपयोग किया गया

→ फ़ैसला #3

⇨ 480 logical shards और 32 physical DBs की संरचना चुनी गई

2 की घात 512 की बजाय 480 चुनने का कारण यह था कि यह ज़्यादा लचीले तरीके से विभाजित होने वाली संख्या है

  • shards में migration करना

→ 1. Old & New DB में dual write करना (Audit Log के साथ)

→ 2. dual write शुरू होने के बाद old DB के data को new DB में backfill करना शुरू किया

→ 3. new DB के data का validation

→ 4. new DB पर switch करना (incremental तरीके से)

  • मुश्किल से सीखे गए सबक

→ sharding पहले करें : मौजूदा DB par दबाव बहुत बढ़ने तक इंतज़ार किया गया, इसलिए migration खुद भी अतिरिक्त बोझ बन गया और इसे धीरे-धीरे ही करना पड़ा

→ zero-downtime migration को लक्ष्य बनाइए : अंतिम switch के समय dual write की throughput ही मुख्य bottleneck थी.

→ अलग partition key की बजाय composite PK का उपयोग करें : अगर मौजूदा DB के PK id और partition key space_id को जोड़ दिया जाता, तो app के भीतर space_id को पास करने की ज़रूरत नहीं पड़ती

1 टिप्पणियां

 
xguru 2021-10-18

Postgres के TXID की बात हमेशा सामने आने वाले विषयों में से एक है