एक ही टेबल कई अरब rows तक पहुंच गई है और writes धीमी पड़ रही हैं। आपके पास क्या विकल्प हैं?

पहले सस्ते विकल्प चुका लें: बेहतर indexes, ठंडी rows का archiving, बड़े columns को बाहर निकालना, और read लोड के लिए read replicas। फिर टेबल को partition करें, आमतौर पर समय या tenant के हिसाब से, ताकि हर partition छोटा रहे और पुराने partitions तुरंत हटाए जा सकें। अलग अलग डेटाबेस पर sharding सबसे आखिर में आती है, क्योंकि इससे cross shard queries, distributed transactions और rebalancing की कीमत चुकानी पड़ती है, और shard key का चुनाव बाद में बदलना बहुत मुश्किल होता है।

पहले मैं यह पता करूंगा कि असल में धीमा क्या है, क्योंकि बड़ी टेबल अपने आप समस्या नहीं होती। आमतौर पर वजह हर insert पर index maintenance होती है, या कुछ बिना इस्तेमाल के indexes, या autovacuum का पीछे छूट जाना। तो मैं सस्ती जीत से शुरू करता हूं: जिन indexes का कोई इस्तेमाल नहीं वे हटाओ, कोई बड़ा text या JSON column एक side टेबल में ले जाओ ताकि मुख्य rows छोटी रहें, और retention policy से पुरानी हर चीज़ archive कर दो। अगर फिर भी यह सचमुच बहुत बड़ी है, तो मैं partition करता हूं, event जैसे डेटा के लिए आमतौर पर समय के हिसाब से, जिससे हर partition छोटा रहता है, planner सही range तक prune कर पाता है, और पिछले साल का डेटा हटाना दिन भर चलने वाले delete की जगह एक partition drop बन जाता है। sharding आखिरी सहारा है क्योंकि यह प्रोग्रामिंग मॉडल ही बदल देती है: cross shard joins खत्म, transactions distributed हो जाते हैं, और rebalancing खुद एक प्रोजेक्ट है। अगर shard करना ही पड़े तो key पर मैं सच में सोचता हूं, क्योंकि events टेबल को customer id पर shard करने पर जिस पल एक कस्टमर बाकियों से दस गुना बड़ा होगा, उसी पल एक hot shard मिल जाएगा।