మానవుల కోసం క్లిక్‌హౌస్ డేటాబేస్ లేదా ఏలియన్ టెక్నాలజీస్

అలెక్సీ లిజునోవ్, ICB యొక్క ఇన్ఫర్మేషన్ టెక్నాలజీ డైరెక్టరేట్ యొక్క రిమోట్ సర్వీస్ ఛానెల్‌ల కోసం సామర్థ్య కేంద్రం అధిపతి

ELK స్టాక్‌కి ప్రత్యామ్నాయంగా (ElasticSearch, Logstash, Kibana), మేము ClickHouse డేటాబేస్‌ను లాగ్‌ల కోసం డేటా నిల్వగా ఉపయోగించడంపై పరిశోధన చేస్తున్నాము.

ఈ కథనంలో మేము ClickHouse డేటాబేస్ మరియు పైలట్ ఆపరేషన్ నుండి ప్రాథమిక ఫలితాలను ఉపయోగించి మా అనుభవం గురించి మాట్లాడాలనుకుంటున్నాము. ఫలితాలు ఆకట్టుకునేలా ఉన్నాయని వెంటనే గమనించాలి.

తరువాత మన సిస్టమ్ ఎలా కాన్ఫిగర్ చేయబడిందో మరియు అది ఏ భాగాలను కలిగి ఉందో మరింత వివరంగా వివరిస్తాము. కానీ ఇప్పుడు నేను ఈ డేటాబేస్ మొత్తం గురించి కొంచెం మాట్లాడాలనుకుంటున్నాను మరియు ఎందుకు శ్రద్ధ వహించాలి. ClickHouse డేటాబేస్ అనేది Yandex నుండి అధిక-పనితీరు గల విశ్లేషణాత్మక స్తంభాల డేటాబేస్. Yandex సేవల్లో ఉపయోగించబడుతుంది, ప్రారంభంలో ఇది Yandex.Metrica కోసం ప్రధాన డేటా నిల్వ. ఓపెన్ సోర్స్ సిస్టమ్, ఉచితం. డెవలపర్ దృక్కోణం నుండి, వారు దీన్ని ఎలా అమలు చేసారో నేను ఎప్పుడూ ఆలోచిస్తున్నాను, ఎందుకంటే అద్భుతంగా పెద్ద డేటా ఉంది. మరియు Metrica వినియోగదారు ఇంటర్‌ఫేస్ చాలా సరళమైనది మరియు త్వరగా పని చేస్తుంది. మీరు మొదట ఈ డేటాబేస్తో పరిచయమైనప్పుడు, మీరు ఈ అభిప్రాయాన్ని పొందుతారు: “సరే, చివరకు! "ప్రజల కోసం" తయారు చేయబడింది! ఇన్‌స్టాలేషన్ ప్రాసెస్ నుండి అభ్యర్థనలను పంపడం వరకు.”

ఈ డేటాబేస్ చాలా తక్కువ ప్రవేశ అవరోధాన్ని కలిగి ఉంది. సగటు డెవలపర్ కూడా కొన్ని నిమిషాల్లో ఈ డేటాబేస్‌ను ఇన్‌స్టాల్ చేసి, దాన్ని ఉపయోగించడం ప్రారంభించవచ్చు. అంతా సజావుగా సాగుతుంది. Linuxకి కొత్త వ్యక్తులు కూడా త్వరగా ఇన్‌స్టాలేషన్‌ను ఎదుర్కోవచ్చు మరియు సాధారణ కార్యకలాపాలను చేయవచ్చు. ఇంతకుముందు, బిగ్ డేటా, హడూప్, గూగుల్ బిగ్ టేబుల్, హెచ్‌డిఎఫ్‌ఎస్ అనే పదాలు విన్నప్పుడు, సగటు డెవలపర్‌కి వారు కొన్ని టెరాబైట్‌లు, పెటాబైట్‌ల గురించి మాట్లాడుతున్నారని, ఈ సిస్టమ్‌లను సెటప్ చేయడం మరియు డెవలప్‌ చేయడంలో కొంతమంది సూపర్‌హ్యూమన్‌లు పాల్గొన్నారని ఆలోచన వచ్చింది. ClickHouse డేటాబేస్ యొక్క ఆగమనం మేము ఒక సాధారణ, అర్థమయ్యే సాధనాన్ని పొందాము, దానితో మీరు ఇంతకుముందు సాధించలేని సమస్యలను పరిష్కరించవచ్చు. ఇది ఒక సాధారణ యంత్రం మరియు ఇన్‌స్టాల్ చేయడానికి ఐదు నిమిషాలు పడుతుంది. అంటే, మాకు MySql వంటి డేటాబేస్ వచ్చింది, కానీ బిలియన్ల రికార్డులను నిల్వ చేయడానికి మాత్రమే! SQL భాషతో ఒక రకమైన సూపర్ ఆర్కైవర్. ఇది ప్రజలకు గ్రహాంతర ఆయుధాలు ఇచ్చినట్లే.

మా లాగ్ సేకరణ వ్యవస్థ గురించి

సమాచారాన్ని సేకరించడానికి, ప్రామాణిక ఫార్మాట్ యొక్క వెబ్ అప్లికేషన్‌ల యొక్క IIS లాగ్ ఫైల్‌లు ఉపయోగించబడతాయి (మేము ప్రస్తుతం అప్లికేషన్ లాగ్‌లను అన్వయించడంలో నిమగ్నమై ఉన్నాము, అయితే పైలట్ దశలో మా ప్రధాన లక్ష్యం IIS లాగ్‌లను సేకరించడం).

మేము వివిధ కారణాల వల్ల ELK స్టాక్‌ను పూర్తిగా వదిలివేయలేకపోయాము మరియు మేము లాగ్‌స్టాష్ మరియు ఫైల్‌బీట్ భాగాలను ఉపయోగించడం కొనసాగిస్తున్నాము, అవి తమను తాము బాగా నిరూపించుకున్నాయి మరియు చాలా విశ్వసనీయంగా మరియు ఊహాజనితంగా పని చేస్తాయి.

సాధారణ లాగింగ్ పథకం క్రింది చిత్రంలో చూపబడింది:

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

పథకంలో ఉపయోగించిన సాఫ్ట్‌వేర్ యొక్క పూర్తి జాబితా పట్టికలో ప్రదర్శించబడింది:

ఉపయోగించిన సాఫ్ట్‌వేర్ జాబితా

పేరు

వివరణ

పంపిణీకి లింక్

వికీపీడియా

పోర్ట్ ద్వారా యాక్సెస్‌ని పరిమితం చేయడం మరియు అధికారాన్ని నిర్వహించడం కోసం రివర్స్-ప్రాక్సీ

ప్రస్తుతం పథకంలో ఉపయోగించబడలేదు

https://nginx.org/ru/download.html

https://nginx.org/download/nginx-1.16.0.tar.gz

FileBeat

ఫైల్ లాగ్‌ల బదిలీ.

https://www.elastic.co/downloads/beats/filebeat (Windows 64bit కోసం పంపిణీ).

https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.3.0-windows-x86_64.zip

లాగ్‌స్టాష్

లాగ్ కలెక్టర్.

FileBeat నుండి లాగ్‌లను సేకరించడానికి, అలాగే RabbitMQ క్యూ నుండి లాగ్‌లను సేకరించడానికి (DMZలో ఉన్న సర్వర్‌ల కోసం.) ఉపయోగించబడుతుంది.

https://www.elastic.co/products/logstash

https://artifacts.elastic.co/downloads/logstash/logstash-7.0.1.rpm

లాగ్‌స్టాష్- అవుట్‌పుట్- క్లిక్‌హౌస్

బ్యాచ్‌లలో క్లిక్‌హౌస్ డేటాబేస్‌కు లాగ్‌లను బదిలీ చేయడానికి లాగ్‌స్టాష్ ప్లగ్ఇన్

https://github.com/mikechris/logstash-output-clickhouse

/usr/share/logstash/bin/logstash-plugin ఇన్‌స్టాల్ logstash-output-clickhouse

/usr/share/logstash/bin/logstash-plugin ఇన్‌స్టాల్ logstash-filter-prune

/usr/share/logstash/bin/logstash-plugin ఇన్‌స్టాల్ logstash-filter-multiline

క్లిక్హౌస్

లాగ్ నిల్వ https://clickhouse.yandex/docs/ru/

https://packagecloud.io/Altinity/clickhouse/packages/el/7/clickhouse-server-19.5.3.8-1.el7.x86_64.rpm

https://packagecloud.io/Altinity/clickhouse/packages/el/7/clickhouse-client-19.5.3.8-1.el7.x86_64.rpm

గమనిక. ఆగస్టు 2018 నుండి, RHEL కోసం “సాధారణ” rpm బిల్డ్‌లు Yandex రిపోజిటరీలో కనిపించాయి, కాబట్టి మీరు వాటిని ఉపయోగించడాన్ని ప్రయత్నించవచ్చు. ఇన్‌స్టాలేషన్ సమయంలో మేము ఆల్టినిటీ ద్వారా సంకలనం చేయబడిన ప్యాకేజీలను ఉపయోగిస్తున్నాము.

గ్రాఫనా

లాగ్‌ల విజువలైజేషన్. డ్యాష్‌బోర్డ్‌లను ఏర్పాటు చేస్తోంది

https://grafana.com/

https://grafana.com/grafana/download

Redhat & Centos(64 Bit) - తాజా వెర్షన్

గ్రాఫానా 4.6+ కోసం క్లిక్‌హౌస్ డేటాసోర్స్

ClickHouse డేటా సోర్స్‌తో గ్రాఫానా కోసం ప్లగిన్

https://grafana.com/plugins/vertamedia-clickhouse-datasource

https://grafana.com/api/plugins/vertamedia-clickhouse-datasource/versions/1.8.1/download

లాగ్‌స్టాష్

FileBeat నుండి RabbitMQ క్యూకి రౌటర్‌ని లాగ్ చేయండి.

గమనిక. దురదృష్టవశాత్తూ FileBeat నేరుగా RabbitMQకి అవుట్‌పుట్‌ని కలిగి ఉండదు, కాబట్టి Logstash రూపంలో ఇంటర్మీడియట్ లింక్ అవసరం

https://www.elastic.co/products/logstash

https://artifacts.elastic.co/downloads/logstash/logstash-7.0.1.rpm

RabbitMQ

సందేశం వరుస. ఇది DMZలో లాగ్ ఎంట్రీల బఫర్

https://www.rabbitmq.com/download.html

https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.7.14/rabbitmq-server-3.7.14-1.el7.noarch.rpm

ఎర్లాంగ్ రన్‌టైమ్ (RabbitMQ కోసం అవసరం)

ఎర్లాంగ్ రన్‌టైమ్. RabbitMQ పని చేయడానికి అవసరం

http://www.erlang.org/download.html

https://www.rabbitmq.com/install-rpm.html#install-erlang http://www.erlang.org/downloads/21.3

ClickHouse డేటాబేస్తో సర్వర్ కాన్ఫిగరేషన్ క్రింది పట్టికలో ప్రదర్శించబడింది:

పేరు

విలువ

వ్యాఖ్య

ఆకృతీకరణ

HDD: 40GB
RAM: 8GB
ప్రాసెసర్: కోర్ 2 2Ghz

మీరు ClickHouse డేటాబేస్ను ఉపయోగించడం కోసం చిట్కాలకు శ్రద్ధ వహించాలి (https://clickhouse.yandex/docs/ru/operations/tips/)

సిస్టమ్-వైడ్ సాఫ్ట్‌వేర్

OS: Red Hat Enterprise Linux సర్వర్ (Maipo)

JRE (జావా 8)

 

మీరు గమనిస్తే, ఇది సాధారణ వర్క్‌స్టేషన్.

లాగ్లను నిల్వ చేయడానికి పట్టిక యొక్క నిర్మాణం క్రింది విధంగా ఉంటుంది:

log_web.sql

CREATE TABLE log_web (
  logdate Date,
  logdatetime DateTime CODEC(Delta, LZ4HC),
   
  fld_log_file_name LowCardinality( String ),
  fld_server_name LowCardinality( String ),
  fld_app_name LowCardinality( String ),
  fld_app_module LowCardinality( String ),
  fld_website_name LowCardinality( String ),
 
  serverIP LowCardinality( String ),
  method LowCardinality( String ),
  uriStem String,
  uriQuery String,
  port UInt32,
  username LowCardinality( String ),
  clientIP String,
  clientRealIP String,
  userAgent String,
  referer String,
  response String,
  subresponse String,
  win32response String,
  timetaken UInt64
   
  , uriQuery__utm_medium String
  , uriQuery__utm_source String
  , uriQuery__utm_campaign String
  , uriQuery__utm_term String
  , uriQuery__utm_content String
  , uriQuery__yclid String
  , uriQuery__region String
 
) Engine = MergeTree()
PARTITION BY toYYYYMM(logdate)
ORDER BY (fld_app_name, fld_app_module, logdatetime)
SETTINGS index_granularity = 8192;

విభజన (నెలవారీ) మరియు ఇండెక్స్ గ్రాన్యులారిటీ కోసం మేము డిఫాల్ట్ విలువలను ఉపయోగిస్తాము. http అభ్యర్థనలను రికార్డ్ చేయడానికి అన్ని ఫీల్డ్‌లు ఆచరణాత్మకంగా IIS లాగ్ ఎంట్రీలకు అనుగుణంగా ఉంటాయి. విడిగా, utm ట్యాగ్‌లను నిల్వ చేయడానికి ప్రత్యేక ఫీల్డ్‌లు ఉన్నాయని మేము గమనించాము (అవి ప్రశ్న స్ట్రింగ్ ఫీల్డ్ నుండి టేబుల్‌లోకి చొప్పించే దశలో అన్వయించబడతాయి).

అలాగే, సిస్టమ్‌లు, భాగాలు మరియు సర్వర్‌ల గురించి సమాచారాన్ని నిల్వ చేయడానికి అనేక సిస్టమ్ ఫీల్డ్‌లు పట్టికకు జోడించబడ్డాయి. ఈ ఫీల్డ్‌ల వివరణ కోసం, దిగువ పట్టికను చూడండి. ఒక పట్టికలో మేము అనేక వ్యవస్థల కోసం లాగ్లను నిల్వ చేస్తాము.

పేరు

వివరణ

ఉదాహరణకు

fld_app_పేరు

అప్లికేషన్/సిస్టమ్ పేరు
చెల్లుబాటు అయ్యే విలువలు:

• site1.domain.com బాహ్య సైట్ 1
• site2.domain.com బాహ్య సైట్ 2
• అంతర్గత-site1.domain.local అంతర్గత సైట్ 1

site1.domain.com

fld_app_module

సిస్టమ్ మాడ్యూల్
చెల్లుబాటు అయ్యే విలువలు:

• వెబ్ - వెబ్‌సైట్
• svc — వెబ్‌సైట్ వెబ్ సేవ
• intgr — వెబ్ ఇంటిగ్రేషన్ సేవ
• బో - అడ్మినిస్ట్రేటర్ (బ్యాక్ ఆఫీస్)

వెబ్

fld_website_పేరు

IISలో సైట్ పేరు

ఒక సర్వర్‌లో అనేక సిస్టమ్‌లు అమలు చేయబడతాయి లేదా ఒక సిస్టమ్ మాడ్యూల్‌కి సంబంధించిన అనేక సందర్భాలు కూడా ఉంటాయి

వెబ్-మెయిన్

fld_server_name

సర్వర్ పేరు

web1.domain.com

fld_log_file_name

సర్వర్‌లోని లాగ్ ఫైల్‌కు మార్గం

నుండి:inetpublogsLogFiles
W3SVC1u_ex190711.log

ఇది గ్రాఫానాలో గ్రాఫ్‌లను సమర్ధవంతంగా రూపొందించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉదాహరణకు, నిర్దిష్ట సిస్టమ్ యొక్క ఫ్రంట్ ఎండ్ నుండి అభ్యర్థనలను వీక్షించండి. ఇది Yandex.Metricaలోని సైట్ కౌంటర్‌ను పోలి ఉంటుంది.

రెండు నెలల డేటాబేస్ వినియోగంపై ఇక్కడ కొన్ని గణాంకాలు ఉన్నాయి.

సిస్టమ్ మరియు కాంపోనెంట్ వారీగా రికార్డుల సంఖ్య

SELECT
    fld_app_name,
    fld_app_module,
    count(fld_app_name) AS rows_count
FROM log_web
GROUP BY
    fld_app_name,
    fld_app_module
    WITH TOTALS
ORDER BY
    fld_app_name ASC,
    rows_count DESC
 
┌─fld_app_name─────┬─fld_app_module─┬─rows_count─┐
│ site1.domain.ru  │ web            │     131441 │
│ site2.domain.ru  │ web            │    1751081 │
│ site3.domain.ru  │ web            │  106887543 │
│ site3.domain.ru  │ svc            │   44908603 │
│ site3.domain.ru  │ intgr          │    9813911 │
│ site4.domain.ru  │ web            │     772095 │
│ site5.domain.ru  │ web            │   17037221 │
│ site5.domain.ru  │ intgr          │     838559 │
│ site5.domain.ru  │ bo             │       7404 │
│ site6.domain.ru  │ web            │     595877 │
│ site7.domain.ru  │ web            │   27778858 │
└──────────────────┴────────────────┴────────────┘
 
Totals:
┌─fld_app_name─┬─fld_app_module─┬─rows_count─┐
│              │                │  210522593 │
└──────────────┴────────────────┴────────────┘
 
11 rows in set. Elapsed: 4.874 sec. Processed 210.52 million rows, 421.67 MB (43.19 million rows/s., 86.51 MB/s.)

డిస్క్ డేటా వాల్యూమ్

SELECT
    formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed,
    formatReadableSize(sum(data_compressed_bytes)) AS compressed,
    sum(rows) AS total_rows
FROM system.parts
WHERE table = 'log_web'
 
┌─uncompressed─┬─compressed─┬─total_rows─┐
│ 54.50 GiB    │ 4.86 GiB   │  211427094 │
└──────────────┴────────────┴────────────┘
 
1 rows in set. Elapsed: 0.035 sec.

కాలమ్ డేటా కంప్రెషన్ నిష్పత్తి

SELECT
    name,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed,
    formatReadableSize(data_compressed_bytes) AS compressed,
    data_uncompressed_bytes / data_compressed_bytes AS compress_ratio
FROM system.columns
WHERE table = 'log_web'
 
┌─name───────────────────┬─uncompressed─┬─compressed─┬─────compress_ratio─┐
│ logdate                │ 401.53 MiB   │ 1.80 MiB   │ 223.16665968777315 │
│ logdatetime            │ 803.06 MiB   │ 35.91 MiB  │ 22.363966401202305 │
│ fld_log_file_name      │ 220.66 MiB   │ 2.60 MiB   │  84.99905736932571 │
│ fld_server_name        │ 201.54 MiB   │ 50.63 MiB  │  3.980924816977078 │
│ fld_app_name           │ 201.17 MiB   │ 969.17 KiB │ 212.55518183686877 │
│ fld_app_module         │ 201.17 MiB   │ 968.60 KiB │ 212.67805817411906 │
│ fld_website_name       │ 201.54 MiB   │ 1.24 MiB   │  162.7204926761546 │
│ serverIP               │ 201.54 MiB   │ 50.25 MiB  │  4.010824061219731 │
│ method                 │ 201.53 MiB   │ 43.64 MiB  │  4.617721053304486 │
│ uriStem                │ 5.13 GiB     │ 832.51 MiB │  6.311522291936919 │
│ uriQuery               │ 2.58 GiB     │ 501.06 MiB │  5.269731450124478 │
│ port                   │ 803.06 MiB   │ 3.98 MiB   │ 201.91673864241824 │
│ username               │ 318.08 MiB   │ 26.93 MiB  │ 11.812513794583598 │
│ clientIP               │ 2.35 GiB     │ 82.59 MiB  │ 29.132328640073343 │
│ clientRealIP           │ 2.49 GiB     │ 465.05 MiB │  5.478382297052563 │
│ userAgent              │ 18.34 GiB    │ 764.08 MiB │  24.57905114484208 │
│ referer                │ 14.71 GiB    │ 1.37 GiB   │ 10.736792723669906 │
│ response               │ 803.06 MiB   │ 83.81 MiB  │  9.582334090987247 │
│ subresponse            │ 399.87 MiB   │ 1.83 MiB   │  218.4831068635027 │
│ win32response          │ 407.86 MiB   │ 7.41 MiB   │ 55.050315514606815 │
│ timetaken              │ 1.57 GiB     │ 402.06 MiB │ 3.9947395692010637 │
│ uriQuery__utm_medium   │ 208.17 MiB   │ 12.29 MiB  │ 16.936148912472955 │
│ uriQuery__utm_source   │ 215.18 MiB   │ 13.00 MiB  │ 16.548367623199912 │
│ uriQuery__utm_campaign │ 381.46 MiB   │ 37.94 MiB  │ 10.055156353418509 │
│ uriQuery__utm_term     │ 231.82 MiB   │ 10.78 MiB  │ 21.502540454070672 │
│ uriQuery__utm_content  │ 441.34 MiB   │ 87.60 MiB  │  5.038260760449327 │
│ uriQuery__yclid        │ 216.88 MiB   │ 16.58 MiB  │  13.07721335008116 │
│ uriQuery__region       │ 204.35 MiB   │ 9.49 MiB   │  21.52661903446796 │
└────────────────────────┴──────────────┴────────────┴────────────────────┘
 
28 rows in set. Elapsed: 0.005 sec.

ఉపయోగించిన భాగాల వివరణ

FileBeat. ఫైల్ లాగ్‌లను బదిలీ చేస్తోంది

ఈ భాగం డిస్క్‌లోని లాగ్ ఫైల్‌లకు మార్పులను పర్యవేక్షిస్తుంది మరియు సమాచారాన్ని LogStashకి పంపుతుంది. లాగ్ ఫైల్‌లు వ్రాయబడిన అన్ని సర్వర్‌లలో ఇన్‌స్టాల్ చేయబడింది (సాధారణంగా IIS). టెయిల్ మోడ్‌లో పని చేస్తుంది (అనగా, ఇది ఫైల్‌కి జోడించిన రికార్డులను మాత్రమే బదిలీ చేస్తుంది). కానీ మీరు మొత్తం ఫైల్‌లను బదిలీ చేయడానికి దీన్ని విడిగా కాన్ఫిగర్ చేయవచ్చు. మీరు మునుపటి నెలల డేటాను డౌన్‌లోడ్ చేయవలసి వచ్చినప్పుడు ఇది సౌకర్యవంతంగా ఉంటుంది. లాగ్ ఫైల్‌ను ఫోల్డర్‌లో ఉంచండి మరియు అది పూర్తిగా చదువుతుంది.

సేవ ఆగిపోయినప్పుడు, డేటా మరింత నిల్వకు బదిలీ చేయబడదు.

ఉదాహరణ కాన్ఫిగరేషన్ ఇలా కనిపిస్తుంది:

filebeat.yml

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:/inetpub/logs/LogFiles/W3SVC1/*.log
  exclude_files: ['.gz$','.zip$']
  tail_files: true
  ignore_older: 24h
  fields:
    fld_server_name: "site1.domain.ru"
    fld_app_name: "site1.domain.ru"
    fld_app_module: "web"
    fld_website_name: "web-main"
 
- type: log
  enabled: true
  paths:
    - C:/inetpub/logs/LogFiles/__Import/access_log-*
  exclude_files: ['.gz$','.zip$']
  tail_files: false
  fields:
    fld_server_name: "site2.domain.ru"
    fld_app_name: "site2.domain.ru"
    fld_app_module: "web"
    fld_website_name: "web-main"
    fld_logformat: "logformat__apache"
 
 
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false
  reload.period: 2s
 
output.logstash:
  hosts: ["log.domain.com:5044"]
 
  ssl.enabled: true
  ssl.certificate_authorities: ["C:/filebeat/certs/ca.pem", "C:/filebeat/certs/ca-issuing.pem"]
  ssl.certificate: "C:/filebeat/certs/site1.domain.ru.cer"
  ssl.key: "C:/filebeat/certs/site1.domain.ru.key"
 
#================================ Processors =====================================
 
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

లాగ్‌స్టాష్. లాగ్ కలెక్టర్

ఈ భాగం FileBeat (లేదా RabbitMQ క్యూ ద్వారా) నుండి లాగ్ రికార్డ్‌లను స్వీకరించడానికి రూపొందించబడింది, వాటిని క్లిక్‌హౌస్ డేటాబేస్‌లో బ్యాచ్‌లలో అన్వయించడానికి మరియు ఇన్సర్ట్ చేయడానికి.

ClickHouseలోకి చొప్పించడానికి, Logstash-output-clickhouse ప్లగ్ఇన్ ఉపయోగించండి. లాగ్‌స్టాష్ ప్లగ్ఇన్ అభ్యర్థనలను తిరిగి పొందడం కోసం ఒక యంత్రాంగాన్ని కలిగి ఉంది, కానీ సాధారణ షట్‌డౌన్ సమయంలో, సేవను నిలిపివేయడం మంచిది. ఆపివేసినప్పుడు, సందేశాలు RabbitMQ క్యూలో పేరుకుపోతాయి, కాబట్టి ఎక్కువసేపు స్టాప్ ఉంటే, సర్వర్‌లలో ఫైల్‌బీట్‌లను ఆపడం మంచిది. RabbitMQ ఉపయోగించని స్కీమ్‌లో (స్థానిక నెట్‌వర్క్‌లో Filebeat నేరుగా లాగ్‌స్టాష్‌కు లాగ్‌లను పంపుతుంది), Filebeats చాలా ఆమోదయోగ్యమైనది మరియు సురక్షితంగా పని చేస్తుంది, కాబట్టి వారికి అవుట్‌పుట్ లభ్యత ఎటువంటి పరిణామాలను కలిగి ఉండదు.

ఉదాహరణ కాన్ఫిగరేషన్ ఇలా కనిపిస్తుంది:

log_web__filebeat_clickhouse.conf

input {
 
    beats {
        port => 5044
        type => 'iis'
        ssl => true
        ssl_certificate_authorities => ["/etc/logstash/certs/ca.cer", "/etc/logstash/certs/ca-issuing.cer"]
        ssl_certificate => "/etc/logstash/certs/server.cer"
        ssl_key => "/etc/logstash/certs/server-pkcs8.key"
        ssl_verify_mode => "peer"
 
            add_field => {
                "fld_server_name" => "%{[fields][fld_server_name]}"
                "fld_app_name" => "%{[fields][fld_app_name]}"
                "fld_app_module" => "%{[fields][fld_app_module]}"
                "fld_website_name" => "%{[fields][fld_website_name]}"
                "fld_log_file_name" => "%{source}"
                "fld_logformat" => "%{[fields][fld_logformat]}"
            }
    }
 
    rabbitmq {
        host => "queue.domain.com"
        port => 5671
        user => "q-reader"
        password => "password"
        queue => "web_log"
        heartbeat => 30
        durable => true
        ssl => true
        #ssl_certificate_path => "/etc/logstash/certs/server.p12"
        #ssl_certificate_password => "password"
 
        add_field => {
            "fld_server_name" => "%{[fields][fld_server_name]}"
            "fld_app_name" => "%{[fields][fld_app_name]}"
            "fld_app_module" => "%{[fields][fld_app_module]}"
            "fld_website_name" => "%{[fields][fld_website_name]}"
            "fld_log_file_name" => "%{source}"
            "fld_logformat" => "%{[fields][fld_logformat]}"
        }
    }
 
}
 
filter { 
 
      if [message] =~ "^#" {
        drop {}
      }
 
      if [fld_logformat] == "logformat__iis_with_xrealip" {
     
          grok {
            match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{IP:serverIP} %{WORD:method} %{NOTSPACE:uriStem} %{NOTSPACE:uriQuery} %{NUMBER:port} %{NOTSPACE:username} %{IPORHOST:clientIP} %{NOTSPACE:userAgent} %{NOTSPACE:referer} %{NUMBER:response} %{NUMBER:subresponse} %{NUMBER:win32response} %{NUMBER:timetaken} %{NOTSPACE:xrealIP} %{NOTSPACE:xforwarderfor}"]
          }
      } else {
   
          grok {
             match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{IP:serverIP} %{WORD:method} %{NOTSPACE:uriStem} %{NOTSPACE:uriQuery} %{NUMBER:port} %{NOTSPACE:username} %{IPORHOST:clientIP} %{NOTSPACE:userAgent} %{NOTSPACE:referer} %{NUMBER:response} %{NUMBER:subresponse} %{NUMBER:win32response} %{NUMBER:timetaken}"]
          }
 
      }
 
      date {
        match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss" ]
          timezone => "Etc/UTC"
        remove_field => [ "log_timestamp", "@timestamp" ]
        target => [ "log_timestamp2" ]
      }
 
        ruby {
            code => "tstamp = event.get('log_timestamp2').to_i
                        event.set('logdatetime', Time.at(tstamp).strftime('%Y-%m-%d %H:%M:%S'))
                        event.set('logdate', Time.at(tstamp).strftime('%Y-%m-%d'))"
        }
 
      if [bytesSent] {
        ruby {
          code => "event['kilobytesSent'] = event['bytesSent'].to_i / 1024.0"
        }
      }
 
 
      if [bytesReceived] {
        ruby {
          code => "event['kilobytesReceived'] = event['bytesReceived'].to_i / 1024.0"
        }
      }
 
   
        ruby {
            code => "event.set('clientRealIP', event.get('clientIP'))"
        }
        if [xrealIP] {
            ruby {
                code => "event.set('clientRealIP', event.get('xrealIP'))"
            }
        }
        if [xforwarderfor] {
            ruby {
                code => "event.set('clientRealIP', event.get('xforwarderfor'))"
            }
        }
 
      mutate {
        convert => ["bytesSent", "integer"]
        convert => ["bytesReceived", "integer"]
        convert => ["timetaken", "integer"] 
        convert => ["port", "integer"]
 
        add_field => {
            "clientHostname" => "%{clientIP}"
        }
      }
 
        useragent {
            source=> "useragent"
            prefix=> "browser"
        }
 
        kv {
            source => "uriQuery"
            prefix => "uriQuery__"
            allow_duplicate_values => false
            field_split => "&"
            include_keys => [ "utm_medium", "utm_source", "utm_campaign", "utm_term", "utm_content", "yclid", "region" ]
        }
 
        mutate {
            join => { "uriQuery__utm_source" => "," }
            join => { "uriQuery__utm_medium" => "," }
            join => { "uriQuery__utm_campaign" => "," }
            join => { "uriQuery__utm_term" => "," }
            join => { "uriQuery__utm_content" => "," }
            join => { "uriQuery__yclid" => "," }
            join => { "uriQuery__region" => "," }
        }
 
}
 
output { 
  #stdout {codec => rubydebug}
    clickhouse {
      headers => ["Authorization", "Basic abcdsfks..."]
      http_hosts => ["http://127.0.0.1:8123"]
      save_dir => "/etc/logstash/tmp"
      table => "log_web"
      request_tolerance => 1
      flush_size => 10000
      idle_flush_time => 1
        mutations => {
            "fld_log_file_name" => "fld_log_file_name"
            "fld_server_name" => "fld_server_name"
            "fld_app_name" => "fld_app_name"
            "fld_app_module" => "fld_app_module"
            "fld_website_name" => "fld_website_name"
 
            "logdatetime" => "logdatetime"
            "logdate" => "logdate"
            "serverIP" => "serverIP"
            "method" => "method"
            "uriStem" => "uriStem"
            "uriQuery" => "uriQuery"
            "port" => "port"
            "username" => "username"
            "clientIP" => "clientIP"
            "clientRealIP" => "clientRealIP"
            "userAgent" => "userAgent"
            "referer" => "referer"
            "response" => "response"
            "subresponse" => "subresponse"
            "win32response" => "win32response"
            "timetaken" => "timetaken"
             
            "uriQuery__utm_medium" => "uriQuery__utm_medium"
            "uriQuery__utm_source" => "uriQuery__utm_source"
            "uriQuery__utm_campaign" => "uriQuery__utm_campaign"
            "uriQuery__utm_term" => "uriQuery__utm_term"
            "uriQuery__utm_content" => "uriQuery__utm_content"
            "uriQuery__yclid" => "uriQuery__yclid"
            "uriQuery__region" => "uriQuery__region"
        }
    }
 
}

పైపులైన్లు.yml

# This file is where you define your pipelines. You can define multiple.
# For more information on multiple pipelines, see the documentation:
#   https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
 
- pipeline.id: log_web__filebeat_clickhouse
  path.config: "/etc/logstash/log_web__filebeat_clickhouse.conf"

క్లిక్‌హౌస్. లాగ్ నిల్వ

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

పట్టికను రూపకల్పన చేసేటప్పుడు, ప్రాథమిక కీని నిర్ణయించడం చాలా ముఖ్యం (నిల్వ సమయంలో డేటా క్రమబద్ధీకరించబడుతుంది). డేటా కంప్రెషన్ డిగ్రీ మరియు ప్రశ్న వేగం దీనిపై ఆధారపడి ఉంటుంది. మా ఉదాహరణలో, కీ
ఆర్డర్ ద్వారా ఆర్డర్ (fld_app_name, fld_app_module, logdatetime)
అంటే, సిస్టమ్ పేరు, సిస్టమ్ కాంపోనెంట్ పేరు మరియు ఈవెంట్ తేదీ ద్వారా. ప్రారంభంలో, ఈవెంట్ యొక్క తేదీ మొదట వచ్చింది. దానిని చివరి స్థానానికి తరలించిన తర్వాత, ప్రశ్నలు దాదాపు రెండు రెట్లు వేగంగా పని చేయడం ప్రారంభించాయి. ప్రాథమిక కీని మార్చడం వలన పట్టికను మళ్లీ సృష్టించడం మరియు డేటాను మళ్లీ అప్‌లోడ్ చేయడం అవసరం, తద్వారా ClickHouse డిస్క్‌లోని డేటాను మళ్లీ క్రమబద్ధీకరిస్తుంది. ఇది చాలా కష్టమైన ఆపరేషన్, కాబట్టి క్రమబద్ధీకరణ కీలో ఏమి చేర్చాలి అనే దాని గురించి ముందుగానే జాగ్రత్తగా ఆలోచించడం మంచిది.

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

మేము ప్రస్తుతం సంస్కరణ 19.6ని ఉపయోగిస్తున్నాము మరియు మేము తాజా సంస్కరణకు నవీకరించడానికి ప్రయత్నించాలనుకుంటున్నాము. అవి అడాప్టివ్ గ్రాన్యులారిటీ, స్కిప్పింగ్ ఇండెక్స్‌లు మరియు డబుల్‌డెల్టా కోడెక్ వంటి అద్భుతమైన లక్షణాలను కలిగి ఉన్నాయి.

డిఫాల్ట్‌గా, ఇన్‌స్టాలేషన్ సమయంలో కాన్ఫిగరేషన్ లాగింగ్ స్థాయి ట్రేస్ చేయడానికి సెట్ చేయబడింది. లాగ్‌లు తిప్పబడతాయి మరియు ఆర్కైవ్ చేయబడతాయి, కానీ అదే సమయంలో అవి గిగాబైట్ వరకు విస్తరిస్తాయి. అవసరం లేకపోతే, మీరు హెచ్చరిక స్థాయిని సెట్ చేయవచ్చు, అప్పుడు లాగ్ పరిమాణం బాగా తగ్గుతుంది. లాగింగ్ సెట్టింగ్‌లు config.xml ఫైల్‌లో పేర్కొనబడ్డాయి:

<!-- Possible levels: https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/Logger. h#L105 -->
<level>warning</level>

కొన్ని ఉపయోగకరమైన ఆదేశాలు

Поскольку оригинальные пакеты установки собираются по Debian, то для других версий Linux необходимо использовать пакеты собранные компанией Altinity.
 
Вот по этой ссылке есть инструкции с ссылками на их репозиторий: https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse
sudo yum search clickhouse-server
sudo yum install clickhouse-server.noarch
  
1. проверка статуса
sudo systemctl status clickhouse-server
 
2. остановка сервера
sudo systemctl stop clickhouse-server
 
3. запуск сервера
sudo systemctl start clickhouse-server
 
Запуск для выполнения запросов в многострочном режиме (выполнение после знака ";")
clickhouse-client --multiline
clickhouse-client --multiline --host 127.0.0.1 --password pa55w0rd
clickhouse-client --multiline --host 127.0.0.1 --port 9440 --secure --user default --password pa55w0rd
 
Плагин кликлауза для логстеш в случае ошибки в одной строке сохраняет всю пачку в файл /tmp/log_web_failed.json
Можно вручную исправить этот файл и попробовать залить его в БД вручную:
clickhouse-client --host 127.0.0.1 --password password --query="INSERT INTO log_web FORMAT JSONEachRow" < /tmp/log_web_failed__fixed.json
 
sudo mv /etc/logstash/tmp/log_web_failed.json /etc/logstash/tmp/log_web_failed__fixed.json
sudo chown user_dev /etc/logstash/tmp/log_web_failed__fixed.json
sudo clickhouse-client --host 127.0.0.1 --password password --query="INSERT INTO log_web FORMAT JSONEachRow" < /etc/logstash/tmp/log_web_failed__fixed.json
sudo mv /etc/logstash/tmp/log_web_failed__fixed.json /etc/logstash/tmp/log_web_failed__fixed_.json
 
выход из командной строки
quit;
## Настройка TLS
https://www.altinity.com/blog/2019/3/5/clickhouse-networking-part-2
 
openssl s_client -connect log.domain.com:9440 < /dev/null

లాగ్‌స్టాష్. FileBeat నుండి RabbitMQ క్యూకి రౌటర్‌ని లాగ్ చేయండి

FileBeat నుండి RabbitMQ క్యూకి వచ్చే లాగ్‌లను రూట్ చేయడానికి ఈ భాగం ఉపయోగించబడుతుంది. ఇక్కడ రెండు పాయింట్లు ఉన్నాయి:

1. దురదృష్టవశాత్తూ, FileBeat నేరుగా RabbitMQకి వ్రాయడానికి అవుట్‌పుట్ ప్లగ్ఇన్‌ను కలిగి లేదు. మరియు అటువంటి కార్యాచరణ, వారి గితుబ్‌లోని పోస్ట్ ద్వారా నిర్ణయించడం, అమలు కోసం ప్రణాళిక చేయబడదు. కాఫ్కా కోసం ఒక ప్లగ్ఇన్ ఉంది, కానీ కొన్ని కారణాల వల్ల మనం దానిని ఉపయోగించలేము.
2. DMZలో లాగ్‌లను సేకరించడానికి అవసరాలు ఉన్నాయి. వాటి ఆధారంగా, లాగ్‌లను ముందుగా క్యూలో ఉంచాలి, ఆపై లాగ్‌స్టాష్ క్యూ నుండి రికార్డులను బాహ్యంగా చదువుతుంది.

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

iis_w3c_logs__filebeat_rabbitmq.conf

input {
 
    beats {
        port => 5044
        type => 'iis'
        ssl => true
        ssl_certificate_authorities => ["/etc/pki/tls/certs/app/ca.pem", "/etc/pki/tls/certs/app/ca-issuing.pem"]
        ssl_certificate => "/etc/pki/tls/certs/app/queue.domain.com.cer"
        ssl_key => "/etc/pki/tls/certs/app/queue.domain.com-pkcs8.key"
        ssl_verify_mode => "peer"
    }
 
}
 
output { 
  #stdout {codec => rubydebug}
 
    rabbitmq {
        host => "127.0.0.1"
        port => 5672
        exchange => "monitor.direct"
        exchange_type => "direct"
        key => "%{[fields][fld_app_name]}"
        user => "q-writer"
        password => "password"
        ssl => false
    }
}

కుందేలుMQ. సందేశ క్యూ

ఈ భాగం DMZలో లాగ్ ఎంట్రీలను బఫర్ చేయడానికి ఉపయోగించబడుతుంది. ఫైల్‌బీట్ → లాగ్‌స్టాష్ లింక్ ద్వారా రికార్డింగ్ జరుగుతుంది. LogStash ద్వారా DMZ వెలుపలి నుండి చదవడం జరుగుతుంది. RabbitMQ ద్వారా పనిచేసేటప్పుడు, సెకనుకు దాదాపు 4 వేల సందేశాలు ప్రాసెస్ చేయబడతాయి.

మెసేజ్ రూటింగ్ సిస్టమ్ పేరు ద్వారా కాన్ఫిగర్ చేయబడింది, అంటే FileBeat కాన్ఫిగరేషన్ డేటా ఆధారంగా. అన్ని సందేశాలు ఒకే వరుసలోకి వెళ్తాయి. కొన్ని కారణాల వలన క్యూయింగ్ సేవ నిలిపివేయబడితే, ఇది సందేశ నష్టానికి దారితీయదు: FileBeats కనెక్షన్ లోపాలను స్వీకరిస్తుంది మరియు తాత్కాలికంగా పంపడం ఆపివేస్తుంది. మరియు క్యూ నుండి చదివే లాగ్‌స్టాష్ కూడా నెట్‌వర్క్ లోపాలను స్వీకరిస్తుంది మరియు కనెక్షన్ పునరుద్ధరించబడే వరకు వేచి ఉంటుంది. ఈ సందర్భంలో, వాస్తవానికి, డేటా ఇకపై డేటాబేస్కు వ్రాయబడదు.

క్యూలను సృష్టించడానికి మరియు కాన్ఫిగర్ చేయడానికి క్రింది సూచనలు ఉపయోగించబడతాయి:

sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare exchange --vhost=/ name=monitor.direct type=direct sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare queue --vhost=/ name=web_log durable=true
sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site1.domain.ru"
sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site2.domain.ru"

గ్రాఫానా. డాష్‌బోర్డ్‌లు

పర్యవేక్షణ డేటాను దృశ్యమానం చేయడానికి ఈ భాగం ఉపయోగించబడుతుంది. ఈ సందర్భంలో, మీరు Grafana 4.6+ ప్లగిన్ కోసం ClickHouse డేటాసోర్స్‌ను ఇన్‌స్టాల్ చేయాలి. డాష్‌బోర్డ్‌లో SQL ఫిల్టర్‌లను ప్రాసెస్ చేసే సామర్థ్యాన్ని మెరుగుపరచడానికి మేము దీన్ని కొద్దిగా సర్దుబాటు చేయాల్సి వచ్చింది.

ఉదాహరణకు, మేము వేరియబుల్స్‌ని ఉపయోగిస్తాము మరియు అవి ఫిల్టర్ ఫీల్డ్‌లో పేర్కొనబడకపోతే, ఫారమ్‌లోని ఎక్కడ షరతును రూపొందించకూడదని మేము కోరుకుంటున్నాము ( uriStem = "మరియు uriStem != "). ఈ సందర్భంలో, ClickHouse uriStem కాలమ్‌ని చదువుతుంది. కాబట్టి, మేము వేర్వేరు ఎంపికలను ప్రయత్నించాము మరియు చివరికి కాలమ్‌ను పేర్కొనకుండా, ఖాళీ విలువ విషయంలో 1ని తిరిగి ఇచ్చేలా ప్లగ్ఇన్ ($valueIfEmpty మాక్రో)ను పరిష్కరించాము.

ఇప్పుడు మీరు గ్రాఫ్ కోసం ఈ ప్రశ్నను ఉపయోగించవచ్చు

$columns(response, count(*) c) from $table where $adhoc
and $valueIfEmpty($fld_app_name, 1, fld_app_name = '$fld_app_name')
and $valueIfEmpty($fld_app_module, 1, fld_app_module = '$fld_app_module') and $valueIfEmpty($fld_server_name, 1, fld_server_name = '$fld_server_name') and $valueIfEmpty($uriStem, 1, uriStem like '%$uriStem%')
and $valueIfEmpty($clientRealIP, 1, clientRealIP = '$clientRealIP')

ఇది ఇలా SQLకి మార్చబడుతుంది (ఖాళీ uriStem ఫీల్డ్‌లు కేవలం 1కి మార్చబడతాయని గమనించండి)

SELECT
t,
groupArray((response, c)) AS groupArr
FROM (
SELECT
(intDiv(toUInt32(logdatetime), 60) * 60) * 1000 AS t, response,
count(*) AS c FROM default.log_web
WHERE (logdate >= toDate(1565061982)) AND (logdatetime >= toDateTime(1565061982)) AND 1 AND (fld_app_name = 'site1.domain.ru') AND (fld_app_module = 'web') AND 1 AND 1 AND 1
GROUP BY
t, response
ORDER BY
t ASC,
response ASC
)
GROUP BY t ORDER BY t ASC

తీర్మానం

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

ElasticSearchతో పోలిస్తే, ప్రాథమిక అంచనాల ప్రకారం లాగ్‌లను నిల్వ చేయడానికి మరియు ప్రాసెస్ చేయడానికి అయ్యే ఖర్చు ఐదు నుండి పది రెట్లు తగ్గుతుంది. మరో మాటలో చెప్పాలంటే, ప్రస్తుత డేటా వాల్యూమ్ కోసం మనం అనేక మెషీన్ల క్లస్టర్‌ను సెటప్ చేయాల్సి వస్తే, క్లిక్‌హౌస్‌ని ఉపయోగిస్తున్నప్పుడు మనకు ఒక తక్కువ-పవర్ మెషీన్ మాత్రమే అవసరం. అవును, వాస్తవానికి, ElasticSearch కూడా ఆన్-డిస్క్ డేటా కంప్రెషన్ మెకానిజమ్‌లను మరియు వనరుల వినియోగాన్ని గణనీయంగా తగ్గించగల ఇతర లక్షణాలను కలిగి ఉంది, అయితే ClickHouseతో పోలిస్తే దీనికి ఎక్కువ ఖర్చులు అవసరమవుతాయి.

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

ముగింపులో, లాభాలు మరియు నష్టాల గురించి కొంచెం.

Минусы

1. పెద్ద బ్యాచ్‌లలో రికార్డులను లోడ్ చేస్తోంది. ఒక వైపు, ఇది ఒక లక్షణం, కానీ మీరు ఇప్పటికీ రికార్డులను బఫర్ చేయడానికి అదనపు భాగాలను ఉపయోగించాలి. ఈ పని ఎల్లప్పుడూ సులభం కాదు, కానీ ఇప్పటికీ పరిష్కరించదగినది. మరియు నేను పథకాన్ని సరళీకృతం చేయాలనుకుంటున్నాను.
2. కొన్ని అన్యదేశ కార్యాచరణలు లేదా కొత్త ఫీచర్లు తరచుగా కొత్త వెర్షన్‌లలో విరిగిపోతాయి. ఇది ఆందోళనలను పెంచుతుంది, కొత్త సంస్కరణకు అప్‌గ్రేడ్ చేయాలనే కోరికను తగ్గిస్తుంది. ఉదాహరణకు, కాఫ్కా టేబుల్ ఇంజిన్ అనేది వినియోగదారులను అమలు చేయకుండా, కాఫ్కా నుండి ఈవెంట్‌లను నేరుగా చదవడానికి మిమ్మల్ని అనుమతించే చాలా ఉపయోగకరమైన లక్షణం. కానీ గితుబ్‌లోని సమస్యల సంఖ్యను బట్టి చూస్తే, ఉత్పత్తిలో ఈ ఇంజిన్‌ను ఉపయోగించడం గురించి మేము ఇంకా జాగ్రత్తగా ఉన్నాము. అయితే, మీరు వైపుకు ఆకస్మిక కదలికలు చేయకపోతే మరియు ప్రాథమిక కార్యాచరణను ఉపయోగించకపోతే, అది స్థిరంగా పనిచేస్తుంది.

Плюсы

1. నెమ్మదించదు.
2. తక్కువ ప్రవేశ త్రెషోల్డ్.
3. ఓపెన్ సోర్స్.
4. ఉచిత.
5. స్కేలబుల్ (షార్డింగ్/అవుట్-ఆఫ్-ది-బాక్స్ రెప్లికేషన్)
6. కమ్యూనికేషన్స్ మంత్రిత్వ శాఖ సిఫార్సు చేసిన రష్యన్ సాఫ్ట్‌వేర్ రిజిస్టర్‌లో చేర్చబడింది.
7. Yandex నుండి అధికారిక మద్దతు లభ్యత.

మూలం: www.habr.com