మేము మల్టిపుల్ టైమ్ సిరీస్ డేటాబేస్‌లను ఎలా పరీక్షించాము

గత కొన్ని సంవత్సరాలుగా, సమయ-శ్రేణి డేటాబేస్‌లు విపరీతమైన విషయం నుండి (బహిరంగ పర్యవేక్షణ వ్యవస్థలలో (మరియు నిర్దిష్ట పరిష్కారాలతో ముడిపడి ఉన్నవి) లేదా బిగ్ డేటా ప్రాజెక్ట్‌లలో అత్యంత ప్రత్యేకమైనవి) "వినియోగదారు ఉత్పత్తి"గా మారాయి. రష్యన్ ఫెడరేషన్ యొక్క భూభాగంలో, దీని కోసం Yandex మరియు ClickHouseకి ప్రత్యేక ధన్యవాదాలు ఇవ్వాలి. ఈ సమయం వరకు, మీరు పెద్ద మొత్తంలో సమయ శ్రేణి డేటాను నిల్వ చేయాల్సిన అవసరం ఉన్నట్లయితే, మీరు ఒక భయంకరమైన హడూప్ స్టాక్‌ను నిర్మించడం మరియు దానిని నిర్వహించడం లేదా ప్రతి సిస్టమ్‌కు వ్యక్తిగతంగా ప్రోటోకాల్‌లతో కమ్యూనికేట్ చేయడం అవసరం.

2019లో TSDBని ఉపయోగించడం విలువైనది అనే కథనం ఒక వాక్యాన్ని మాత్రమే కలిగి ఉన్నట్లు అనిపించవచ్చు: “కేవలం ClickHouseని ఉపయోగించండి.” కానీ... సూక్ష్మబేధాలు ఉన్నాయి.

నిజానికి, ClickHouse చురుకుగా అభివృద్ధి చెందుతోంది, యూజర్ బేస్ పెరుగుతోంది మరియు మద్దతు చాలా చురుకుగా ఉంది, అయితే ఇతర, బహుశా మరింత ప్రభావవంతమైన/విశ్వసనీయమైన పరిష్కారాలను కప్పివేసిన ClickHouse యొక్క ప్రజా విజయానికి మేము బందీలుగా మారారా?

గత సంవత్సరం ప్రారంభంలో, మేము మా స్వంత పర్యవేక్షణ వ్యవస్థను మళ్లీ పని చేయడం ప్రారంభించాము, ఈ సమయంలో డేటాను నిల్వ చేయడానికి తగిన డేటాబేస్ను ఎంచుకోవడం గురించి ప్రశ్న తలెత్తింది. నేను ఈ ఎంపిక చరిత్ర గురించి ఇక్కడ మాట్లాడాలనుకుంటున్నాను.

సమస్య యొక్క ప్రకటన

అన్నింటిలో మొదటిది, అవసరమైన ముందుమాట. మనకు మన స్వంత పర్యవేక్షణ వ్యవస్థ ఎందుకు అవసరం మరియు అది ఎలా రూపొందించబడింది?

మేము 2008లో సహాయ సేవలను అందించడం ప్రారంభించాము మరియు 2010 నాటికి క్లయింట్ అవస్థాపనలో సంభవించే ప్రక్రియల గురించి ఆ సమయంలో ఉన్న పరిష్కారాలతో డేటాను సమగ్రపరచడం కష్టమైందని స్పష్టమైంది (మేము మాట్లాడుతున్నాము, దేవుడు నన్ను క్షమించు, కాక్టి, జబ్బిక్స్ మరియు ఎమర్జింగ్ గ్రాఫైట్).

మా ప్రధాన అవసరాలు:

• మద్దతు (ఆ సమయంలో - డజన్ల కొద్దీ, మరియు భవిష్యత్తులో - వందల) క్లయింట్‌లకు ఒక సిస్టమ్‌లో మరియు అదే సమయంలో కేంద్రీకృత హెచ్చరిక నిర్వహణ వ్యవస్థ ఉనికి;
• హెచ్చరిక వ్యవస్థను నిర్వహించడంలో వశ్యత (డ్యూటీ అధికారుల మధ్య హెచ్చరికల పెరుగుదల, షెడ్యూలింగ్, నాలెడ్జ్ బేస్);
• గ్రాఫ్‌లను లోతుగా వివరించే సామర్థ్యం (ఆ సమయంలో జబ్బిక్స్ గ్రాఫ్‌లను చిత్రాల రూపంలో అందించింది);
• పెద్ద మొత్తంలో డేటా (సంవత్సరం లేదా అంతకంటే ఎక్కువ) యొక్క దీర్ఘకాలిక నిల్వ మరియు దానిని త్వరగా తిరిగి పొందగల సామర్థ్యం.

ఈ వ్యాసంలో మేము చివరి పాయింట్‌పై ఆసక్తి కలిగి ఉన్నాము.

నిల్వ గురించి మాట్లాడుతూ, అవసరాలు క్రింది విధంగా ఉన్నాయి:

• వ్యవస్థ త్వరగా పని చేయాలి;
• సిస్టమ్ SQL ఇంటర్‌ఫేస్‌ను కలిగి ఉండటం మంచిది;
• సిస్టమ్ స్థిరంగా ఉండాలి మరియు యాక్టివ్ యూజర్ బేస్ మరియు సపోర్ట్‌ను కలిగి ఉండాలి (ఒకప్పుడు మేము అభివృద్ధి చేయని MemcacheDB లేదా MooseFS పంపిణీ చేసిన నిల్వ వంటి సిస్టమ్‌లకు మద్దతు ఇవ్వాల్సిన అవసరాన్ని ఎదుర్కొన్నాము, దీని బగ్ ట్రాకర్ చైనీస్‌లో ఉంచబడింది: మేము కోరుకోని మా ప్రాజెక్ట్ కోసం ఈ కథను పునరావృతం చేస్తాము);
• CAP సిద్ధాంతానికి అనుగుణంగా ఉండటం: కాన్‌సిటెన్సీ (అవసరం) - డేటా తప్పనిసరిగా తాజాగా ఉండాలి, హెచ్చరిక నిర్వహణ వ్యవస్థ కొత్త డేటాను స్వీకరించకూడదని మరియు అన్ని ప్రాజెక్ట్‌లకు డేటా రాకపోవడం గురించి హెచ్చరికలను ఉమ్మివేయాలని మేము కోరుకోము; విభజన సహనం (అవసరం) - మేము స్ప్లిట్ బ్రెయిన్ సిస్టమ్‌ను పొందాలనుకోవడం లేదు; లభ్యత (క్లిష్టమైనది కాదు, క్రియాశీల ప్రతిరూపం ఉంటే) - ప్రమాదం జరిగినప్పుడు, కోడ్‌ని ఉపయోగించి మనమే బ్యాకప్ సిస్టమ్‌కి మారవచ్చు.

విచిత్రమేమిటంటే, ఆ సమయంలో MySQL మనకు ఆదర్శవంతమైన పరిష్కారంగా మారింది. మా డేటా నిర్మాణం చాలా సులభం: సర్వర్ ఐడి, కౌంటర్ ఐడి, టైమ్‌స్టాంప్ మరియు విలువ; హాట్ డేటా యొక్క వేగవంతమైన నమూనా పెద్ద బఫర్ పూల్ ద్వారా నిర్ధారించబడింది మరియు చారిత్రక డేటా యొక్క నమూనా SSD ద్వారా నిర్ధారించబడింది.

ఆ విధంగా, మేము డేటా పూర్తిగా రెండర్ చేయడానికి ముందు రెండవ 200 ms వరకు వివరాలతో తాజా రెండు వారాల డేటా యొక్క నమూనాను సాధించాము మరియు ఈ సిస్టమ్‌లో చాలా కాలం పాటు జీవించాము.

ఇంతలో, సమయం గడిచిపోయింది మరియు డేటా మొత్తం పెరిగింది. 2016 నాటికి, డేటా వాల్యూమ్‌లు పదుల సంఖ్యలో టెరాబైట్‌లకు చేరుకున్నాయి, ఇది అద్దె SSD నిల్వ సందర్భంలో గణనీయమైన వ్యయం.

ఈ సమయానికి, స్తంభాల డేటాబేస్‌లు చురుకుగా విస్తృతంగా మారాయి, దీని గురించి మేము చురుకుగా ఆలోచించడం ప్రారంభించాము: కాలమ్ డేటాబేస్‌లలో, డేటా నిల్వ చేయబడుతుంది, మీరు అర్థం చేసుకున్నట్లుగా, నిలువు వరుసలలో, మరియు మీరు మా డేటాను చూస్తే, పెద్దదిగా చూడటం సులభం. మీరు స్తంభాల డేటాబేస్‌ని ఉపయోగిస్తే, కుదింపును ఉపయోగించి దాన్ని కుదించగల నకిలీల సంఖ్య.

అయినప్పటికీ, సంస్థ యొక్క కీలక వ్యవస్థ స్థిరంగా పని చేస్తూనే ఉంది మరియు నేను వేరొకదానికి మారడం గురించి ప్రయోగాలు చేయాలనుకోలేదు.

2017లో, శాన్ జోస్‌లో జరిగిన పెర్కోనా లైవ్ కాన్ఫరెన్స్‌లో, క్లిక్‌హౌస్ డెవలపర్లు తమను తాము మొదటిసారిగా ప్రకటించుకున్నారు. మొదటి చూపులో, సిస్టమ్ ఉత్పత్తి-సిద్ధంగా ఉంది (బాగా, Yandex.Metrica ఒక కఠినమైన ఉత్పత్తి వ్యవస్థ), మద్దతు వేగంగా మరియు సరళంగా ఉంది మరియు, ముఖ్యంగా, ఆపరేషన్ సులభం. 2018 నుండి, మేము పరివర్తన ప్రక్రియను ప్రారంభించాము. కానీ ఆ సమయానికి, "వయోజన" మరియు సమయ-పరీక్షించిన TSDB వ్యవస్థలు చాలా ఉన్నాయి మరియు మా అవసరాలకు అనుగుణంగా క్లిక్‌హౌస్‌కి ప్రత్యామ్నాయ పరిష్కారాలు లేవని నిర్ధారించుకోవడానికి మేము గణనీయమైన సమయాన్ని కేటాయించాలని మరియు ప్రత్యామ్నాయాలను సరిపోల్చాలని నిర్ణయించుకున్నాము.

ఇప్పటికే పేర్కొన్న నిల్వ అవసరాలకు అదనంగా, కొత్తవి కనిపించాయి:

• కొత్త సిస్టమ్ అదే మొత్తంలో హార్డ్‌వేర్‌పై కనీసం MySQL వలె అదే పనితీరును అందించాలి;
• కొత్త సిస్టమ్ యొక్క నిల్వ గణనీయంగా తక్కువ స్థలాన్ని తీసుకోవాలి;
• DBMS ఇప్పటికీ సులభంగా నిర్వహించబడాలి;
• DBMSని మార్చేటప్పుడు నేను అప్లికేషన్‌ను కనిష్టంగా మార్చాలనుకున్నాను.

మేము ఏ వ్యవస్థలను పరిగణించడం ప్రారంభించాము?

అపాచీ హైవ్/అపాచీ ఇంపాలా
పాత, యుద్ధం-పరీక్షించిన హడూప్ స్టాక్. ముఖ్యంగా, ఇది HDFSలో స్థానిక ఫార్మాట్‌లలో డేటాను నిల్వ చేయడం పైన నిర్మించిన SQL ఇంటర్‌ఫేస్.

ప్రోస్

• స్థిరమైన ఆపరేషన్‌తో, డేటాను స్కేల్ చేయడం చాలా సులభం.
• డేటా నిల్వ కోసం కాలమ్ పరిష్కారాలు ఉన్నాయి (తక్కువ స్థలం).
• వనరులు అందుబాటులో ఉన్నప్పుడు సమాంతర పనులను చాలా వేగంగా అమలు చేయడం.

మైనస్‌లు.

• ఇది హడూప్, మరియు దానిని ఉపయోగించడం కష్టం. మేము క్లౌడ్‌లో రెడీమేడ్ సొల్యూషన్‌ని తీసుకోవడానికి సిద్ధంగా లేకుంటే (మరియు మేము ఖర్చు పరంగా సిద్ధంగా లేము), మొత్తం స్టాక్‌ను నిర్వాహకుల చేతులతో సమీకరించాలి మరియు మద్దతు ఇవ్వాలి మరియు మేము నిజంగా కోరుకోము ఇది.
• డేటా సమగ్రపరచబడింది నిజంగా వేగంగా.

అయితే:

కంప్యూటింగ్ సర్వర్ల సంఖ్యను స్కేలింగ్ చేయడం ద్వారా వేగం సాధించబడుతుంది. సరళంగా చెప్పాలంటే, మేము ఒక పెద్ద కంపెనీ అయితే, విశ్లేషణలలో నిమగ్నమై ఉంటే మరియు వీలైనంత త్వరగా సమాచారాన్ని సమగ్రపరచడం వ్యాపారానికి కీలకం (పెద్ద మొత్తంలో కంప్యూటింగ్ వనరులను ఉపయోగించి కూడా), ఇది మా ఎంపిక కావచ్చు. కానీ పనులను వేగవంతం చేయడానికి హార్డ్‌వేర్ విమానాలను గుణించడానికి మేము సిద్ధంగా లేము.

డ్రూయిడ్/పినోట్

ప్రత్యేకంగా TSDB గురించి చాలా ఎక్కువ ఉంది, కానీ మళ్ళీ, హడూప్ స్టాక్.

ఉన్నాయి డ్రూయిడ్ మరియు పినోట్ వర్సెస్ క్లిక్‌హౌస్ యొక్క లాభాలు మరియు నష్టాలను పోల్చిన గొప్ప కథనం .

కొన్ని మాటలలో: డ్రూయిడ్/పినోట్ క్లిక్‌హౌస్ కంటే మెరుగ్గా కనిపించే సందర్భాలలో:

• మీరు డేటా యొక్క విజాతీయ స్వభావాన్ని కలిగి ఉన్నారు (మా విషయంలో, మేము సర్వర్ కొలమానాల సమయ శ్రేణులను మాత్రమే రికార్డ్ చేస్తాము మరియు వాస్తవానికి ఇది ఒక టేబుల్ మాత్రమే. కానీ ఇతర సందర్భాలు ఉండవచ్చు: పరికరాల సమయ శ్రేణి, ఆర్థిక సమయ శ్రేణి మొదలైనవి - ప్రతి దానితో దాని స్వంత నిర్మాణం, ఇది సమగ్రంగా మరియు ప్రాసెస్ చేయబడాలి).
• అదనంగా, ఈ డేటా చాలా ఉంది.
• సమయ శ్రేణితో పట్టికలు మరియు డేటా కనిపించడం మరియు అదృశ్యం (అనగా, డేటా యొక్క కొంత సెట్ వచ్చింది, విశ్లేషించబడింది మరియు తొలగించబడింది).
• డేటాను విభజించగల స్పష్టమైన ప్రమాణం లేదు.

వ్యతిరేక సందర్భాలలో, ClickHouse మెరుగ్గా పని చేస్తుంది మరియు ఇది మా కేసు.

క్లిక్హౌస్

• SQL లాంటిది
• నిర్వహించడం సులభం.
• ఇది పని చేస్తుందని ప్రజలు అంటున్నారు.

పరీక్ష కోసం షార్ట్‌లిస్ట్ చేయబడుతుంది.

InfluxDB

ClickHouseకి విదేశీ ప్రత్యామ్నాయం. మైనస్‌లలో: అధిక లభ్యత వాణిజ్య వెర్షన్‌లో మాత్రమే ఉంది, కానీ దానిని పోల్చడం అవసరం.

పరీక్ష కోసం షార్ట్‌లిస్ట్ చేయబడుతుంది.

కాసాండ్రా

ఒకవైపు, ఇది అటువంటి పర్యవేక్షణ వ్యవస్థల ద్వారా మెట్రిక్ సమయాలను నిల్వ చేయడానికి ఉపయోగించబడుతుందని మాకు తెలుసు, ఉదాహరణకు, సిగ్నల్ఎఫ్ఎక్స్ లేదా OkMeter. అయితే, ప్రత్యేకతలు ఉన్నాయి.

కాసాండ్రా సాంప్రదాయిక అర్థంలో స్తంభాల డేటాబేస్ కాదు. ఇది వరుస వీక్షణ వలె కనిపిస్తుంది, కానీ ప్రతి పంక్తి వేర్వేరు నిలువు వరుసలను కలిగి ఉంటుంది, ఇది నిలువు వీక్షణను నిర్వహించడం సులభం చేస్తుంది. ఈ కోణంలో, 2 బిలియన్ నిలువు వరుసల పరిమితితో, కొంత డేటాను నిలువు వరుసలలో (మరియు అదే సమయ శ్రేణి) నిల్వ చేయడం సాధ్యమవుతుందని స్పష్టమవుతుంది. ఉదాహరణకు, MySQLలో 4096 నిలువు వరుసల పరిమితి ఉంది మరియు మీరు అదే చేయడానికి ప్రయత్నిస్తే 1117 కోడ్‌తో లోపం ఏర్పడటం సులభం.

Cassandra ఇంజిన్ మాస్టర్ లేకుండా పంపిణీ చేయబడిన సిస్టమ్‌లో పెద్ద మొత్తంలో డేటాను నిల్వ చేయడంపై దృష్టి పెడుతుంది మరియు పైన పేర్కొన్న Cassandra CAP సిద్ధాంతం AP గురించి, అంటే డేటా లభ్యత మరియు విభజనకు నిరోధకత గురించి ఎక్కువగా ఉంటుంది. అందువల్ల, మీరు ఈ డేటాబేస్‌కు మాత్రమే వ్రాయవలసి వస్తే మరియు దాని నుండి అరుదుగా చదవవలసి వస్తే ఈ సాధనం గొప్పగా ఉంటుంది. మరియు ఇక్కడ కాసాండ్రాను "చల్లని" నిల్వగా ఉపయోగించడం తార్కికం. అంటే, అరుదుగా అవసరమయ్యే, అయితే అవసరమైతే తిరిగి పొందగలిగే భారీ మొత్తంలో చారిత్రక డేటాను నిల్వ చేయడానికి దీర్ఘకాలిక, నమ్మదగిన ప్రదేశంగా. అయినప్పటికీ, సంపూర్ణత కొరకు, మేము దానిని కూడా పరీక్షిస్తాము. కానీ, నేను ఇంతకు ముందే చెప్పినట్లుగా, ఎంచుకున్న డేటాబేస్ పరిష్కారం కోసం కోడ్‌ను చురుకుగా తిరిగి వ్రాయాలనే కోరిక లేదు, కాబట్టి మేము దానిని కొంతవరకు పరిమితంగా పరీక్షిస్తాము - డేటాబేస్ నిర్మాణాన్ని కాసాండ్రా యొక్క ప్రత్యేకతలకు అనుగుణంగా మార్చకుండా.

ప్రోమేతియస్

సరే, ఉత్సుకతతో, మేము ప్రోమేతియస్ స్టోరేజ్ పనితీరును పరీక్షించాలని నిర్ణయించుకున్నాము - మేము ప్రస్తుత పరిష్కారాల కంటే వేగంగా లేదా నెమ్మదిగా ఉన్నామని మరియు ఎంత ఎక్కువగా ఉన్నామో అర్థం చేసుకోవడానికి.

పరీక్షా పద్దతి మరియు ఫలితాలు

కాబట్టి, మేము క్రింది 5 కాన్ఫిగరేషన్‌లలో 6 డేటాబేస్‌లను పరీక్షించాము: ClickHouse (1 నోడ్), ClickHouse (3 నోడ్‌ల కోసం పంపిణీ చేయబడిన టేబుల్), InfluxDB, Mysql 8, Cassandra (3 నోడ్‌లు) మరియు Prometheus. పరీక్ష ప్రణాళిక క్రింది విధంగా ఉంది:

1. ఒక వారం చారిత్రక డేటాను అప్‌లోడ్ చేయండి (రోజుకు 840 మిలియన్ విలువలు; 208 వేల కొలమానాలు);
2. మేము రికార్డింగ్ లోడ్‌ను రూపొందిస్తాము (6 లోడ్ మోడ్‌లు పరిగణించబడ్డాయి, క్రింద చూడండి);
3. రికార్డింగ్‌తో సమాంతరంగా, చార్ట్‌లతో పని చేసే వినియోగదారు అభ్యర్థనలను అనుకరిస్తూ మేము కాలానుగుణంగా ఎంపికలు చేస్తాము. విషయాలను చాలా క్లిష్టతరం చేయకుండా ఉండటానికి, మేము ఒక వారం పాటు 10 మెట్రిక్‌ల (CPU గ్రాఫ్‌లో ఎన్ని ఉన్నాయి) కోసం డేటాను ఎంచుకున్నాము.

మేము మా మానిటరింగ్ ఏజెంట్ యొక్క ప్రవర్తనను అనుకరించడం ద్వారా లోడ్ చేస్తాము, ఇది ప్రతి మెట్రిక్‌కి ప్రతి 15 సెకన్లకు ఒకసారి విలువలను పంపుతుంది. అదే సమయంలో, మేము విభిన్నంగా ఉండటానికి ఆసక్తి కలిగి ఉన్నాము:

• డేటా వ్రాయబడిన మొత్తం కొలమానాల సంఖ్య;
• ఒక మెట్రిక్‌కు విలువలను పంపడానికి విరామం;
• గుంపు పరిమాణం.

బ్యాచ్ పరిమాణం గురించి. దాదాపు మా అన్ని ప్రయోగాత్మక డేటాబేస్‌లను సింగిల్ ఇన్‌సర్ట్‌లతో లోడ్ చేయమని సిఫార్సు చేయనందున, ఇన్‌కమింగ్ మెట్రిక్‌లను సేకరించి వాటిని గ్రూప్‌లుగా గ్రూప్ చేసి బ్యాచ్ ఇన్‌సర్ట్‌గా డేటాబేస్‌కి వ్రాసే రిలే మాకు అవసరం.

అలాగే, అందుకున్న డేటాను ఎలా అన్వయించాలో బాగా అర్థం చేసుకోవడానికి, మేము కొలమానాల సమూహాన్ని పంపడం మాత్రమే కాకుండా, కొలమానాలు సర్వర్‌లుగా నిర్వహించబడతాయి - ఒక్కో సర్వర్‌కు 125 మెట్రిక్‌లు. ఇక్కడ సర్వర్ కేవలం వర్చువల్ ఎంటిటీ - ఉదాహరణకు, 10000 కొలమానాలు దాదాపు 80 సర్వర్‌లకు అనుగుణంగా ఉన్నాయని అర్థం చేసుకోవడానికి.

మరియు ఇక్కడ, ఇవన్నీ పరిగణనలోకి తీసుకుంటే, మా 6 డేటాబేస్ రైట్ లోడ్ మోడ్‌లు:

ఇక్కడ రెండు పాయింట్లు ఉన్నాయి. ముందుగా, కాసాండ్రా కోసం ఈ బ్యాచ్ పరిమాణాలు చాలా పెద్దవిగా మారాయి, అక్కడ మేము 50 లేదా 100 విలువలను ఉపయోగించాము. మరియు రెండవది, ప్రోమేతియస్ ఖచ్చితంగా పుల్ మోడ్‌లో పనిచేస్తాడు కాబట్టి, అనగా. అది స్వయంగా వెళ్లి కొలమానాల మూలాల నుండి డేటాను సేకరిస్తుంది (మరియు పుష్‌గేట్‌వే, పేరు ఉన్నప్పటికీ, ప్రాథమికంగా పరిస్థితిని మార్చదు), సంబంధిత లోడ్‌లు స్టాటిక్ కాన్ఫిగర్‌ల కలయికను ఉపయోగించి అమలు చేయబడ్డాయి.

పరీక్ష ఫలితాలు క్రింది విధంగా ఉన్నాయి:

గమనించదగ్గ విషయం: ప్రోమేథియస్ నుండి అద్భుతంగా వేగవంతమైన నమూనాలు, కాసాండ్రా నుండి భయంకరమైన నెమ్మదిగా నమూనాలు, InfluxDB నుండి ఆమోదయోగ్యం కాని నెమ్మదిగా నమూనాలు; రికార్డింగ్ వేగం పరంగా, క్లిక్‌హౌస్ ప్రతి ఒక్కరినీ గెలుచుకుంది మరియు ప్రోమేతియస్ పోటీలో పాల్గొనలేదు, ఎందుకంటే ఇది ఇన్‌సర్ట్‌లను చేస్తుంది మరియు మేము దేనినీ కొలవము.

చివరికి: ClickHouse మరియు InfluxDB తమను తాము అత్యుత్తమంగా చూపించాయి, అయితే ఇన్‌ఫ్లక్స్ నుండి క్లస్టర్ ఎంటర్‌ప్రైజ్ వెర్షన్ ఆధారంగా మాత్రమే నిర్మించబడుతుంది, దీనికి డబ్బు ఖర్చవుతుంది, అయితే ClickHouse ఏమీ ఖర్చు చేయదు మరియు రష్యాలో తయారు చేయబడింది. USAలో ఎంపిక ఇన్‌ఫ్లక్స్‌డిబికి అనుకూలంగా ఉండవచ్చు మరియు మన దేశంలో ఇది క్లిక్‌హౌస్‌కు అనుకూలంగా ఉండటం తార్కికం.

మూలం: www.habr.com