सिर्फ प्रदर्शन काफी नहीं है
(motherduck.com)- डेटाबेस चुनते समय अगर केवल raw query speed और सामान्य benchmarks को देखा जाए, तो यूज़र के सवाल से जवाब तक पहुँचने में लगने वाला कुल समय आसानी से छूट सकता है
- 2019 के GigaOm benchmark ने Azure Data Warehouse और Redshift को आगे दिखाया था, लेकिन असली बाज़ार में Snowflake और BigQuery ज़्यादा बिके, जिससे performance के अलावा दूसरे कारकों की ताकत दिखती है
- server execution time घटाने के बावजूद JDBC driver, result download, CSV parsing, SQL लिखने की कठिनाई जैसे आसपास के paths बड़े bottleneck बन सकते हैं
- ClickBench, TPC-H, TPC-DS उपयोगी हैं, लेकिन JOIN की मौजूदगी, single-table scan, schema tuning, correctness और ACID guarantees की शर्तों के आधार पर निष्कर्ष बदल जाते हैं
- डेटाबेस engine performance समय के साथ converge हो जाती है, इसलिए लंबी अवधि के चयन का आधार मौजूदा ranking से ज़्यादा idea से answer तक की speed और workflow integration होना चाहिए
Benchmarks जिन वास्तविक wait time को मिस कर देते हैं
- Seattle के घर से San Francisco office तक की 4.5 घंटे की यात्रा में अगर विमान की cruising speed 10 गुना बढ़ा भी दी जाए, तो airport तक जाना, security check, boarding, runway wait, baggage और destination travel की वजह से कुल समय केवल लगभग 20% ही घट सकता है
- डेटाबेस भी कुछ ऐसा ही है
- engine तेज़ हो जाए, फिर भी यूज़र अजीब CSV files, SQL में सवाल व्यक्त करने की कठिनाई, और tool connection issues से साथ-साथ जूझते हैं
- benchmark wars जीतने वाला product promote करना आसान होता है, लेकिन इसका मतलब यह नहीं कि वह सीधे यूज़र की problem-solving time घटा देगा
- डेटाबेस चयन में ease of use, ecosystem, update speed, और workflow integration बेहतर निर्णय मानदंड हो सकते हैं
- performance किसी खास समय पर किसी खास काम का समय ही दिखाती है, और गलत bottleneck को मेहनत से optimize करवाने का कारण बन सकती है
2019 के GigaOm results और बाज़ार का उल्टा रुख
- 2019 में GigaOm ने cloud data warehouses पर TPC-H और TPC-DS benchmarks चलाए
- लक्ष्य तीन बड़े cloud vendors और Snowflake थे
- परिणाम में Azure Data Warehouse सबसे तेज़ था, Redshift उसके बाद था, और Snowflake व BigQuery काफी पीछे थे
- उस समय BigQuery user evaluations में Azure से सीधे comparison करने वाले customers अक्सर BigQuery चुनते थे
- बाज़ार का परिणाम benchmark ranking से लगभग उल्टा था
- Snowflake और BigQuery, Redshift से ज़्यादा बिके
- Redshift, Azure से ज़्यादा बिकता था
- TPC-H और TPC-DS industry standards हैं और internal performance judgement में भी इस्तेमाल होने वाले tests थे, लेकिन अगर अच्छे performance benchmarks में निचली ranking पाने वाले systems को customers ने ज़्यादा खरीदा, तो माना जा सकता है कि performance से ज़्यादा महत्वपूर्ण factors मौजूद थे
यूज़र को महसूस होने वाली तेज़ी server time नहीं है
- डेटाबेस बनाने वाले लोग अक्सर यूज़र के “run” button दबाने के बाद results तैयार होने तक के server execution time पर ध्यान केंद्रित करते हैं
- यूज़र के लिए महत्वपूर्ण समय काम पूरा करने में लगने वाला कुल समय है, और यह database server द्वारा query execute करने के समय से अलग है
- BigQuery के JDBC driver का उदाहरण इस अंतर को अच्छी तरह दिखाता है
- JDBC driver programmers और BI tools द्वारा database से connect करने के लिए इस्तेमाल होने वाला generic interface था
- BigQuery queries 1–2 सेकंड में execute हो जाती थीं, लेकिन driver के completion polling और result download तरीके के कारण यूज़र को वे कुछ सेकंड या कुछ मिनट और धीमी लगती थीं
- results ज़्यादा होने पर driver page-by-page वह data भी पूरा fetch कर लेता था जिसकी यूज़र को ज़रूरत नहीं होती थी, जिससे delay बढ़ता था और कभी-कभी memory shortage से crash भी हो जाता था
- engineers query time को fraction of a second घटाने में बहुत समय लगाते थे, लेकिन असल यूज़र्स द्वारा बहुत इस्तेमाल होने वाला connector उससे बड़ा delay पैदा कर रहा था
- internal benchmarks रोज़ चलते थे, लेकिन end-to-end performance और यूज़र को महसूस होने वाला time दिखाई नहीं देता था
Performance एक single number में fix नहीं होती
- performance को database perspective से नहीं, बल्कि user perspective से मापा जाना चाहिए, और UX की तरह इसे एक number से पूरी तरह समझाना मुश्किल है
- कौन-सा database तेज़ है, यह actual workload पर निर्भर करता है
- Lamborghini, Prius से तेज़ हो सकती है, लेकिन traffic jam में commute time अलग नहीं हो सकता
- ClickHouse और Redshift की performance difference भी usage pattern पर निर्भर करती है
- ClickHouse का ClickBench दिखाता है कि ClickHouse कई databases से तेज़ है
- benchmark JOIN के बिना single table पर चलता था, और distinct count पर बहुत निर्भर था
- log analysis या website unique users की calculation के लिए यह अच्छा proxy metric हो सकता है
- traditional data warehouse के star schema workloads के लिए यह भ्रम पैदा कर सकता है
- vendor benchmarks आमतौर पर vendor की strengths पर focus करते हैं
- BigQuery benchmarks में कमजोर दिख सकता है, लेकिन knobs लगभग नहीं हैं और आम तौर पर self-tuning है, इसलिए वास्तविक user experience में अच्छा महसूस हो सकता है
- highly tuned SingleStore instance कई workloads में BigQuery को बहुत पीछे छोड़ सकता है, लेकिन schema tuning time और नए workloads जोड़ते समय adaptation की ज़रूरत होती है
- performance बढ़ाने के लिए safety checks या accuracy कम की जा सकती है
- overflow check हटाना
- write flush छोड़ना
- कुछ operations के लिए approximate results देना
- ACID guarantees न देना
- controlled environment को छोड़ दें तो ऐसे shortcuts वे विकल्प बन सकते हैं जिन्हें आप इस्तेमाल नहीं करना चाहेंगे
मौजूदा ranking से ज़्यादा improvement speed टिकती है
- DuckDB-based company बनाते समय यह बात उठी थी कि DuckDB h2o.ai benchmark में काफी पीछे है
- चिंता न करने के दो कारण थे
- performance secondary factor था
- DuckDB बहुत तेज़ गति से improve हो रहा था
- DuckDB की तेज़ improvement में कुछ architectural decisions, अपेक्षाकृत नया और clean codebase, और बेहतरीन engineers का योगदान था
- उसी benchmark के latest DuckDB release के public results में DuckDB middle tier से बड़े अंतर के साथ leading group में पहुँच गया
- डेटाबेस चयन कई साल चलने वाला decision है, इसलिए current performance और features ही नहीं, बल्कि एक साल बाद संभव capability भी महत्वपूर्ण है
- अगर दो databases अलग-अलग speeds से improve हो रहे हैं, तो ज़्यादा तेज़ी से आगे बढ़ने वाले को चुनना बेहतर होने की संभावना अधिक है
Performance gaps समय के साथ कम होते जाते हैं
- actively maintained कई databases को कुछ साल तक बार-बार improve करने पर performance converge करने की प्रवृत्ति रखती है
- एक product की performance technique समय के साथ दूसरे products में भी implement हो सकती है
- अगर ClickHouse scan speed में advantageous techniques इस्तेमाल करता है, तो Snowflake भी 1–2 साल में similar feature ला सकता है
- Snowflake incremental materialized view जोड़ता है, तो BigQuery भी जल्द follow कर सकता है
- हर database में performance निकालने की techniques अलग होती हैं
- queries को machine code में compile करना
- data को local SSD में cache करना
- specialized network hardware से shuffle handle करना
- प्रभावी techniques को समय मिले तो कोई भी implement कर सकता है, और अगर वे अच्छी तरह काम करती हैं तो कई systems में फैलने की संभावना अधिक होती है
- Fivetran CEO George Fraser की data warehouse performance comparison में 2020 में सबसे तेज़ time 8 सेकंड और सबसे धीमा 18 सेकंड था, लेकिन 2022 में तीन vendors लगभग 7 सेकंड पर और सबसे धीमा vendor 9 सेकंड पर आ गया था
- हालांकि, architectural differences को पार करना मुश्किल है
- shared nothing databases, shared disk की तुलना में disadvantaged हो सकते हैं
- Redshift को मुख्यतः shared disk architecture में transition करने में कई साल लगे
- object store में metadata store करने वाला lakehouse तेज़ updates में कठिनाई झेल सकता है
- ऐसे differences मुख्यतः boundary conditions में दिखते हैं, और लंबी अवधि में Redshift के Snowflake से fundamentally तेज़ या धीमा होने का कोई कारण नहीं है
सवाल से जवाब तक का समय घटाने वाले features
- यूज़र के लिए महत्वपूर्ण performance वह समय है जब सवाल पैदा होता है से लेकर जवाब मिलने तक
- यह समय घटाने का तरीका केवल query planning सुधारना नहीं है
- सवाल को आसान तरीके से express करने में मदद कर सकता है
- query results को समझने में आसान बना सकता है
- गलत सवाल पूछने पर feedback दे सकता है
- data issues समझने में मदद कर सकता है
- आवश्यक data को सही जगह और सही form में तैयार करवा सकता है
- Snowflake की ताकत यह थी कि user SQL डालते ही वह “बस काम कर जाए”
- date difference calculate करते समय DATEDIFF और TIMEDIFF दोनों इस्तेमाल किए जा सकते हैं
- reasonable types हों तो दोनों काम करते हैं
- granularity specify या omit की जा सकती है
- granularity में quotes लगाएँ या न लगाएँ, दोनों ठीक है
- DuckDB ने भी Friendlier SQL के जरिए query writing और maintenance आसान करने वाले features जोड़े
GROUP BY ALLaggregate queries में GROUP BY clause के fields छूटने की संभावना घटाता है- केवल SELECT list बदलनी पड़ती है, इसलिए query evolve करते समय कई जगहों पर बदलाव की ज़रूरत घटती है
- यह feature उपयोगी हुआ तो कई database vendors ने similar features जोड़े
- CSV files दुनिया के बहुत सारे data का format हैं, लेकिन कई files गलत तरीके से बनी होती हैं और parsing वास्तव में कठिन है
- BigQuery का शुरुआती CSV splitter inference नहीं कर पाता था, और files के बीच schema थोड़ा भी अलग हो तो confuse हो जाता था
- CSV parsing उम्मीद से ज़्यादा tricky समस्या है
- अगर दो engineers को CSV data पढ़कर same result calculate करना हो, तो जो सिस्टम CSV को सही तरह से आसान ingest करता है, वह query engine speed से स्वतंत्र रूप से पहले answer पा सकता है
- result handling का तरीका भी user experience पर बड़ा असर डालता है
SELECT *अगर MySQL की तरह first page और cursor return करे, तो तुरंत दिख सकता है- BigQuery की तरह server-side table copy बनानी पड़े, तो बड़े table पर कई घंटे लग सकते हैं
- client अगर पूरा data download करने लगे, तो memory shortage हो सकती है
- लंबा connection network issues के प्रति vulnerable होता है, और polling में query polling intervals के बीच खत्म हो तो वह और धीमी दिख सकती है
DuckDB benchmarks देखते समय संकेत
- DuckDB तेज़ है, और कुछ machine sizes के ClickBench में top tier में है
- उदाहरण के तौर पर c6a.4xlarge result दिया गया है
- DuckDB अधिकांश h2o.ai benchmarks में भी अच्छा perform करता है, और TPC-H व TPC-DS में भी खराब नहीं है
- किसी database को तेज़ मानने से पहले अपने workload पर सीधे test करना चाहिए
तेज़ query से ज़्यादा तेज़ problem solving
- सबसे सफल database companies सिर्फ इसलिए सफल नहीं हुईं कि वे competitors से तेज़ थीं
- Redshift कुछ समय तक मजबूत था, लेकिन Snowflake इसलिए प्रवेश कर पाया क्योंकि उसकी ताकत benchmark performance नहीं, बल्कि maintainability थी
- जिन databases ने performance को main selling point बनाया, वे market में अच्छा नहीं कर पाए; जो databases काम आसानी से पूरा करवाते थे, वे ज़्यादा टिके
- database selection में देखने वाले axes और व्यापक हैं
- कोई जादुई secret technique नहीं है, और architectural differences को छोड़ दें तो performance समय के साथ converge करती है
- database engine की improvement speed बहुत अलग-अलग होती है, और तेज़ी से move करने वाला विकल्प long term में advantage रखता है
- performance पर सबसे ज़्यादा obsess करने वाले database vendors लंबी अवधि में धीमे हो सकते हैं
- database performance का single metric नहीं है, और तेज़ database भी कुछ workloads में खराब हो सकता है
- महत्वपूर्ण feature यह नहीं कि query से result तक कितनी जल्दी पहुँचा जाता है, बल्कि idea से answer तक कितनी जल्दी पहुँचा जा सकता है
- धीमी query से तेज़ query बेहतर है, लेकिन database selection raw speed के अलावा दूसरे factors पर आधारित होना चाहिए
1 टिप्पणियां
Hacker News की रायें
यह हिस्सा निराशाजनक है कि कई सालों तक ग्राहकों की शिकायतें आने के बावजूद वे “पूरी तरह अनजान” थे कि JDBC driver की समस्या performance बिगाड़ रही थी
इसका मतलब है कि Google के अंदर लोग अपने product को असली ग्राहकों की तरह इस्तेमाल भी नहीं कर रहे थे, और users को दिखने वाला query time अंदर दिखाई नहीं देता था, इसलिए इसे किसी और की समस्या माना गया
समस्या यह नहीं थी कि optimization पर बहुत ज्यादा मेहनत की गई, बल्कि यह थी कि ग्राहक की पीड़ा से शुरू करके root cause तक trace नहीं किया गया। असली वजह भी आखिरकार performance issue ही थी
JDBC वाली कहानी वाकई अच्छी लगी। Google ने अंदरूनी तौर पर अच्छी चलने वाली database बनाई, और बाहरी दुनिया के लिए adapter layer subcontract करके बनवाई, लेकिन वह ठीक से काम नहीं करती थी, इसलिए बाहरी users को घटिया database इस्तेमाल करनी पड़ी
Google जिस sophisticated core का इस्तेमाल करता है, उसके ऊपर एक टूटा हुआ wrapper चढ़ा दिया गया, जिससे पूरा product बेवजह खराब हो गया; अंदर किसी ने ध्यान नहीं दिया और बाहरी users के लिए भी वजह समझना मुश्किल था। यह Google की open source strategy को बहुत सटीक तरह से दिखाने वाला उदाहरण लगता है
दिक्कत यह है कि non-core areas को काफी खराब कर दिया जाए तो core competency बेहतरीन होने का भी कोई फायदा नहीं रहता। Outsourcing कोई free lunch नहीं है
लेख कहता है कि “performance subjective है” और सिर्फ measurement काफी नहीं, लेकिन असल examples में performance सच में महत्वपूर्ण और objective थी। बस गलत चीज measure की गई थी
यह कंपनी की organizational problem जैसी लगती है। अगर अंतिम लक्ष्य यह है कि लोग cloud इस्तेमाल करें और उन्हें value मिले, तो समझ नहीं आता कि metrics ग्राहकों के लिए महत्वपूर्ण चीजों से अलग क्यों हैं
Google के अंदर कोई ऐसा होना चाहिए जो ग्राहकों से सीधे बात करे, समझे कि समस्या क्या है, और engineers तक बात पहुंचाए ताकि उन्हें पता हो कि क्या improve करना है। Organization को इस तरह design होना चाहिए कि engineers को जरूरी metrics मिलें, या उन metrics को बनाना ही job का हिस्सा हो
मुझे ज्यादा जिज्ञासा यह है कि product और organizational leadership कौन-से metrics देख रही थी कि ऐसी customer feedback छूट गई
“Seattle वाले घर से San Francisco office तक door-to-door 4.5 घंटे” वाला हिस्सा देखकर लगता है कि आजकल founders अब 179 miles/hour की रफ्तार से नहीं चलते। Fed interest rates बढ़ाता है तो शायद ऐसा ही होता है
अच्छे points जरूर हैं, लेकिन conclusion थोड़ा off लगता है। Performance यहां बताए गए तरीके से secondary होने से ज्यादा काफी है या नहीं वाली चीज है
पहले यह pass करना होता है कि क्या यह पर्याप्त तेज है; उसके बाद ही दूसरे factors judge किए जा सकते हैं। उससे पहले आप competition table पर बैठ भी नहीं सकते। लेखक भी कहता है कि “DuckDB is fast”, लेकिन अगर वह fast न होता, तो कम से कम उस checkbox को भरने तक उसे performance पर ही compete करना पड़ता
साथ ही, “सबसे तेजी से आगे बढ़ने वाला database engine आखिरकार जीतता है” यह बात कुछ हद तक सही हो सकती है, लेकिन practical नहीं है। नए player के रूप में progress तेज होती है, लेकिन Snowflake जैसी position पर पहुंचने के बाद speed धीमी होना तय है। आज system चुनते समय current acceleration को future तक वैसे ही extrapolate नहीं किया जा सकता
फिर भी “query से result तक नहीं, बल्कि idea से answer तक कितनी जल्दी पहुंचते हैं” वाला नजरिया अलग से गहराई से explore करने लायक लगता है
Performance “subjective” से ज्यादा relative है। उसका मतलब सामने वाले task से जुड़ा होता है
लेकिन अगर बात ऐसे user interface की है जो तेजी से चलती progress bar की तरह user को ज्यादा fast महसूस कराए, तो वह अलग बात है। वह interface problem है, database problem नहीं
“Relative” कहने के लिए system-to-system comparison के अलावा performance को number देने का कोई तरीका नहीं होना चाहिए, लेकिन यह सच नहीं है
जो web app पहली बार popular हुआ था, उसने सारा state एक Python dict में रखा और हर कुछ मिनट में disk पर dump किया। वह मेरे जीवन की सबसे fast API थी
Mongo पर move करने के बाद performance फिर कभी वापस नहीं आई। फिर भी आज website बनाते समय मैं “pickledb” नहीं उठाऊंगा
fopenके replacement के तौर पर SQLite बीच का रास्ता हैRequest/response वाली user interaction के लिए यह कम fit है, लेकिन बड़े static data या replayable streaming data को incremental या batch तरीके से process करने के मामलों में यह आज से ज्यादा common होना चाहिए
“Shared nothing database, shared disk की तुलना में disadvantage में होती है, और Redshift को मुख्य रूप से shared disk architecture में switch करने में कई साल लगे। Object storage में metadata store करने वाले Lakehouse में fast updates मुश्किल हैं” — इस topic पर अच्छी सामग्री ढूंढ रहा हूं
अच्छा लेख है। पिछले 10 वर्षों में pandas के मजबूत रहने की एक वजह मुझे यह भी लगती है
Single-machine performance काफी अच्छी थी, और यह मानवता को ज्ञात CSV के 99% को read कर सकता था