सिर्फ Perf काफ़ी नहीं है

डेटाबेस में performance-केंद्रित संस्कृति

• डेटाबेस उद्योग performance सुधार पर केंद्रित है, लेकिन वास्तविक user experience अक्सर दूसरे कारकों से प्रभावित होता है।
• डेटा प्रोसेस करते समय उपयोगकर्ता के लिए वास्तव में महत्वपूर्ण चीज़ query optimization से ज़्यादा डेटा का format या SQL में सवाल गढ़ने की क्षमता हो सकती है।
• डेटाबेस performance महत्वपूर्ण है, लेकिन डेटाबेस चुनते समय ease of use, ecosystem, update की गति, workflow के साथ integration जैसे दूसरे कारकों के आधार पर निर्णय लेना बेहतर हो सकता है।

benchmark युद्ध का अंत

• 2019 में GigaOm ने cloud data warehouse की तुलना करने वाला benchmark प्रकाशित किया था, लेकिन वास्तविक बाज़ार नतीजे अलग दिखे।
• अगर benchmark के नतीजे user experience से मेल नहीं खाते, तो यह संकेत हो सकता है कि benchmark ग़लत था, उसने ग़लत चीज़ को test किया, या performance उतनी महत्वपूर्ण नहीं है।

तेज़ होने का मतलब

• cloud database क्षेत्र में अक्सर ध्यान इस बात पर होता है कि उपयोगकर्ता 'execute' बटन क्लिक करने के बाद result तैयार होने में कितना समय लगता है।
• लेकिन वास्तव में उपयोगकर्ता पर असर डालने वाली चीज़ यह है कि काम पूरा होने में कितना समय लगता है, और यह database server time के बराबर नहीं होता।

performance व्यक्तिनिष्ठ है

• performance को उपयोगकर्ता के नज़रिए से मापा जाना चाहिए, और UX से जुड़ी समस्या को एक ही संख्या में नहीं समझाया जा सकता।
• performance की यह व्यक्तिनिष्ठता बताती है कि कौन-सा डेटाबेस ज़्यादा तेज़ है, यह इस बात पर निर्भर करता है कि उसका उपयोग कैसे किया जा रहा है।

बदलाव की रफ़्तार

• DuckDB बहुत तेज़ी से बेहतर हो रहा है, जिससे मौजूदा benchmark निरर्थक हो सकते हैं।
• डेटाबेस चुनते समय सिर्फ़ वर्तमान performance ही नहीं, बल्कि भविष्य की performance और feature बदलाव भी महत्वपूर्ण चर हैं।

कोई जादुई उपाय नहीं

• अगर सभी डेटाबेस सक्रिय रूप से maintain किए जा रहे हैं, तो समय के साथ performance एक-दूसरे के क़रीब आ जाएगी।
• performance में बड़े अंतर लंबे समय तक बने रहने की संभावना कम है।

समस्या कुर्सी और keyboard के बीच, keyboard और database के बीच है

• उपयोगकर्ता के लिए performance का महत्वपूर्ण मापदंड यह है कि सवाल से जवाब तक पहुँचने में कितना समय लगता है।
• डेटाबेस को query execute करने में कितना समय लगता है, उससे ज़्यादा महत्वपूर्ण feature यह है कि idea से answer तक कितनी तेज़ी से पहुँचा जा सकता है।

खट्टे अंगूर की बात

• DuckDB इस समय ClickBench और h20.ai benchmark में ऊपर के स्थानों पर है, और TPC-H तथा TPC-DS में भी इसका प्रदर्शन ख़राब नहीं है।
• किसी डेटाबेस को तेज़ मान लेने से पहले उसे वास्तविक workload पर आज़माना महत्वपूर्ण है।

निष्कर्ष

• सबसे सफल डेटाबेस कंपनियाँ अपने प्रतिस्पर्धियों से ज़्यादा तेज़ performance की वजह से सफल नहीं हुईं।
• जिन डेटाबेस ने performance को मुख्य selling point बनाया, वे बाज़ार में सफल नहीं हुए।
• सलाह यह है कि डेटाबेस चुनते समय raw speed के अलावा दूसरे कारकों के आधार पर निर्णय लेना बेहतर है।

GN⁺ की राय

• यह लेख इस बात पर ज़ोर देता है कि सिर्फ़ डेटाबेस performance पर ध्यान देना काफ़ी नहीं है; user experience और workflow को optimize करना भी उतना ही महत्वपूर्ण है। यह शुरुआती software engineers के लिए भी अहम सीख है कि डेटाबेस चुनते समय केवल performance metrics नहीं, बल्कि user-centric approach पर भी विचार करना चाहिए।
• डेटाबेस performance समय के साथ एक-दूसरे के क़रीब आने की प्रवृत्ति रखती है, क्योंकि तकनीकी प्रगति अलग-अलग platforms में फैल जाती है। इससे संकेत मिलता है कि तकनीक चुनते समय अल्पकालिक performance से ज़्यादा दीर्घकालिक support और improvement की संभावना पर ध्यान देना चाहिए।
• DuckDB जैसे open source projects तेज़ improvement cycle और community support के आधार पर बहुत जल्दी आगे बढ़ सकते हैं। इसका मतलब है कि नई तकनीक अपनाते समय community की सक्रियता और project की प्रगति की रफ़्तार को भी देखना चाहिए।
• डेटाबेस चुनते समय केवल performance benchmark नतीजों पर निर्भर न रहकर, वास्तविक workload पर performance को test करना महत्वपूर्ण है। इससे वास्तविक उपयोग के लिए अधिक उपयुक्त डेटाबेस चुनने में मदद मिल सकती है।
• यह भी रेखांकित किया गया है कि डेटाबेस तकनीक का चयन केवल तकनीकी पक्षों पर नहीं, बल्कि business requirements, maintenance की सरलता और data processing की दक्षता जैसे विविध कारकों को ध्यान में रखकर होना चाहिए।

[GN⁺]

Hacker News राय

• ग्राहकों की बहुत शिकायतों के कई साल बाद यह समझ में आया कि JDBC driver में bug performance को गिरा रहा था। कई engineers का समय queries को तेज़ करने में लगाया गया, लेकिन ज़्यादातर users जिस connector का उपयोग करते थे, वही बचाए गए समय से कहीं ज़्यादा latency जोड़ रहा था। और उससे भी बढ़कर, इस बात का कोई एहसास ही नहीं था। Google के भीतर कोई JDBC driver का उपयोग नहीं कर रहा था, इसलिए users जो query time अनुभव कर रहे थे वह दिखता ही नहीं था, और इसे किसी और की समस्या समझा गया.

  • यह टिप्पणी इस बात पर निराशा जताती है कि Google ग्राहकों की शिकायतों के प्रति "पूरी तरह अंधा" था और अपने ही product का उपयोग नहीं करता था। JDBC वाला हिस्सा खास तौर पर प्रभावशाली है.
• Google ने अंदरूनी इस्तेमाल के लिए एक अच्छी तरह काम करने वाला database बनाया, लेकिन बाहरी दुनिया के लिए adapter layer ठेके पर बनवाई, और वह ठीक से काम नहीं कर पाई, इसलिए बाहरी दुनिया को एक खराब database मिला। Google का sophisticated core अधूरे adapters से घिरा हुआ था, जिसके कारण कुल मिलाकर एक अनावश्यक रूप से उलझा हुआ परिणाम बना। अंदरूनी तौर पर यह बात समझ में नहीं आई, और बाहर के लोगों के लिए इसे पहचानना मुश्किल था.
  • यह टिप्पणी Google की open source strategy पर बहुत सटीक बैठती है.
• मुझे यह अजीब लगता है कि blog कहता है "performance subjective है"। सिर्फ performance को measure करना काफ़ी नहीं है, लेकिन दिए गए एकमात्र उदाहरण में performance महत्वपूर्ण भी है और objective भी। बस गलत चीज़ को measure किया गया था.
  • यह टिप्पणी performance measurement पर blog के दावे पर सवाल उठाती है.
• यह किसी company organization की समस्या लगती है। अगर अंतिम लक्ष्य यह है कि ग्राहक cloud का उपयोग करें और उन्हें value मिले, तो ऐसे metrics नहीं होने चाहिए जो ग्राहकों के लिए महत्वपूर्ण चीज़ों से अलग हों। Google के भीतर ऐसे लोग होने चाहिए जो सक्रिय रूप से ग्राहकों की समस्याएँ सुनें और उन्हें engineers तक पहुँचाएँ ताकि यह पता चल सके कि क्या सुधारना है.
  • यह टिप्पणी इस बात पर ज़ोर देती है कि Google को ग्राहकों की ज़रूरतें समझने और उन्हें बेहतर करने के लिए एक उपयुक्त organizational structure चाहिए.
• Seattle में घर से San Francisco office तक door-to-door पहुँचने में लगभग 4.5 घंटे लगते हैं।
  • यह टिप्पणी मज़ाकिया अंदाज़ में कहती है कि founders अब पहले जैसी तेज़ी से move नहीं करते, और शायद इसकी वजह Federal Reserve द्वारा interest rates बढ़ाना हो सकता है.
• मैं यहाँ कही गई इस बात से सहमत नहीं हूँ कि performance secondary है। पहले यह सुनिश्चित करना चाहिए कि performance पर्याप्त रूप से अच्छी है, उसके बाद ही बाकी सभी चीज़ों का मूल्यांकन करना चाहिए। लेखक खुद कहता है कि "DuckDB तेज़ है"। अगर ऐसा न होता, तो performance competition करनी पड़ती.
  • यह टिप्पणी performance को secondary मानने से असहमत है और कहती है कि पहले performance के पर्याप्त अच्छा होने की पुष्टि होना ज़रूरी है.
• performance "relative" है, "subjective" नहीं। इसका अर्थ उस काम से जुड़ा है जो किया जा रहा है.
  • यह टिप्पणी performance की relative nature समझाती है, और इसे user interface design से जुड़े performance के एहसास से अलग करती है.
• पहला लोकप्रिय web app अपना सारा state Python dict में रखता था और हर कुछ मिनट में उसे disk पर dump कर देता था। वह बहुत तेज़ API था, लेकिन MongoDB पर जाने के बाद performance कभी वापस नहीं आई। फिर भी, आज website बनाते समय कोई "pickledb" नहीं चुनेगा.
  • यह टिप्पणी शुरुआती web app की performance और database बदलने के बाद performance गिरने के अनुभव को साझा करती है.
• मैंने अपना database system बनाया और उसे दूसरे लोकप्रिय databases (Postgres, Sqlite, MySQL, SQL Server) के साथ performance benchmark करना चाहा।
  • यह टिप्पणी बताती है कि user तब तक संतुष्ट नहीं हुआ जब तक उसका database कई तरह की queries में इस मापदंड पर तेज़ नहीं हो गया कि 'run button' दबाने से लेकर screen पर result दिखने तक कितना समय लगता है.
• "बिलकुल, इस नियम के कुछ अपवाद हैं, और वह यह है कि architecture के अंतर को पार करना कठिन होता है। shared nothing database, shared disk की तुलना में नुकसान में रहता है, और Redshift को मुख्य रूप से shared disk architecture की ओर जाने में कई साल लगे। object storage में metadata persist करने वाले lakehouse को तेज़ updates में कठिनाई होगी; यह model में ही निहित है।"
  • यह टिप्पणी database architecture के अंतर से जुड़ी समस्याओं की ओर इशारा करती है, और कहती है कि वह इस विषय पर अच्छा literature खोज रहा है.