Alexey Lizunov ប្រធានមជ្ឈមណ្ឌលជំនាញសម្រាប់បណ្តាញសេវាពីចម្ងាយនៃនាយកដ្ឋានព័ត៌មានវិទ្យានៃ ICB
ជាជម្រើសមួយសម្រាប់ជង់ ELK (ElasticSearch, Logstash, Kibana) យើងកំពុងធ្វើការស្រាវជ្រាវលើការប្រើប្រាស់មូលដ្ឋានទិន្នន័យ ClickHouse ជាកន្លែងផ្ទុកទិន្នន័យសម្រាប់កំណត់ហេតុ។
នៅក្នុងអត្ថបទនេះ យើងចង់និយាយអំពីបទពិសោធន៍របស់យើងដោយប្រើមូលដ្ឋានទិន្នន័យ ClickHouse និងលទ្ធផលបឋមពីប្រតិបត្តិការសាកល្បង។ វាគួរឱ្យកត់សម្គាល់ភ្លាមៗថាលទ្ធផលគួរឱ្យចាប់អារម្មណ៍។
បន្ទាប់ យើងនឹងរៀបរាប់លម្អិតបន្ថែមទៀតអំពីរបៀបដែលប្រព័ន្ធរបស់យើងត្រូវបានកំណត់រចនាសម្ព័ន្ធ និងសមាសធាតុអ្វីខ្លះដែលវាមាន។ ប៉ុន្តែឥឡូវនេះខ្ញុំចង់និយាយបន្តិចអំពីមូលដ្ឋានទិន្នន័យនេះទាំងមូល ហើយហេតុអ្វីបានជាវាគួរយកចិត្តទុកដាក់។ មូលដ្ឋានទិន្នន័យ ClickHouse គឺជាមូលដ្ឋានទិន្នន័យជួរឈរវិភាគដែលមានប្រសិទ្ធភាពខ្ពស់ពី Yandex ។ ត្រូវបានប្រើនៅក្នុងសេវាកម្ម Yandex ដំបូងបង្អស់នេះគឺជាការផ្ទុកទិន្នន័យសំខាន់សម្រាប់ Yandex.Metrica ។ ប្រព័ន្ធប្រភពបើកចំហ ឥតគិតថ្លៃ។ តាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍ ខ្ញុំតែងតែឆ្ងល់ថាតើពួកគេអនុវត្តវាដោយរបៀបណា ពីព្រោះវាមានទិន្នន័យធំអស្ចារ្យ។ ហើយចំណុចប្រទាក់អ្នកប្រើ Metrica ខ្លួនវាគឺអាចបត់បែនបាន និងដំណើរការបានយ៉ាងឆាប់រហ័ស។ នៅពេលអ្នកស្គាល់មូលដ្ឋានទិន្នន័យនេះជាលើកដំបូង អ្នកទទួលបានចំណាប់អារម្មណ៍ថា “មែនហើយ ទីបំផុត! បង្កើត "សម្រាប់ប្រជាជន"! ចាប់ពីដំណើរការដំឡើងរហូតដល់ការផ្ញើសំណើ។"
មូលដ្ឋានទិន្នន័យនេះមានរបាំងចូលទាបបំផុត។ សូម្បីតែអ្នកអភិវឌ្ឍន៍ជាមធ្យមអាចដំឡើងមូលដ្ឋានទិន្នន័យនេះក្នុងរយៈពេលពីរបីនាទី ហើយចាប់ផ្តើមប្រើវា។ អ្វីៗដំណើរការយ៉ាងរលូន។ សូម្បីតែមនុស្សដែលទើបប្រើលីនុចក៏អាចដោះស្រាយបានយ៉ាងឆាប់រហ័សជាមួយនឹងការដំឡើង និងធ្វើប្រតិបត្តិការសាមញ្ញដែរ។ ប្រសិនបើមុននេះ នៅពេលឮពាក្យថា Big Data, Hadoop, Google BigTable, HDFS អ្នកអភិវឌ្ឍន៍ជាមធ្យមមានគំនិតថាពួកគេកំពុងនិយាយអំពី terabytes, petabytes មួយចំនួន ដែលមនុស្សអស្ចារ្យមួយចំនួនបានចូលរួមក្នុងការបង្កើត និងអភិវឌ្ឍប្រព័ន្ធទាំងនេះ បន្ទាប់មកជាមួយនឹងវត្តមាន នៃមូលដ្ឋានទិន្នន័យ ClickHouse យើងទទួលបានឧបករណ៍សាមញ្ញមួយដែលអាចយល់បាន ដែលអ្នកអាចដោះស្រាយបញ្ហាជាច្រើនដែលមិនអាចទទួលបានពីមុនបាន។ អ្វីទាំងអស់ដែលវាត្រូវការគឺម៉ាស៊ីនជាមធ្យមមួយ និងប្រាំនាទីដើម្បីដំឡើង។ នោះគឺយើងទទួលបានមូលដ្ឋានទិន្នន័យដូចជាឧទាហរណ៍ MySql ប៉ុន្តែសម្រាប់តែរក្សាទុកកំណត់ត្រារាប់ពាន់លានប៉ុណ្ណោះ! ប្រភេទនៃ superarchiver ដែលមានភាសា SQL ។ វាដូចជាមនុស្សត្រូវបានផ្តល់អាវុធពីភពក្រៅ។
អំពីប្រព័ន្ធប្រមូលកំណត់ហេតុរបស់យើង។
ដើម្បីប្រមូលព័ត៌មាន ឯកសារកំណត់ហេតុ IIS នៃកម្មវិធីគេហទំព័រនៃទ្រង់ទ្រាយស្តង់ដារត្រូវបានប្រើ (បច្ចុប្បន្នយើងក៏កំពុងចូលរួមក្នុងការញែកកំណត់ហេតុកម្មវិធីដែរ ប៉ុន្តែគោលដៅចម្បងរបស់យើងនៅដំណាក់កាលសាកល្បងគឺការប្រមូលកំណត់ហេតុ IIS)។
យើងមិនអាចបោះបង់ចោលទាំងស្រុងនូវជង់ ELK សម្រាប់ហេតុផលផ្សេងៗនោះទេ ហើយយើងបន្តប្រើប្រាស់សមាសធាតុ LogStash និង Filebeat ដែលបានបង្ហាញឱ្យឃើញពីខ្លួនពួកគេយ៉ាងល្អ និងដំណើរការយ៉ាងជឿជាក់ និងអាចព្យាករណ៍បាន។
គ្រោងការណ៍នៃការកាប់ឈើជាទូទៅត្រូវបានបង្ហាញនៅក្នុងរូបភាពខាងក្រោម:
លក្ខណៈពិសេសនៃការកត់ត្រាទិន្នន័យនៅក្នុងមូលដ្ឋានទិន្នន័យ ClickHouse គឺការបញ្ចូលកំណត់ត្រាដែលមិនញឹកញាប់ (ម្តងក្នុងមួយវិនាទី) ជាបាច់ធំ។ តាមមើលទៅនេះគឺជាផ្នែក "បញ្ហា" បំផុតដែលអ្នកជួបប្រទះនៅពេលធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ ClickHouse ជាលើកដំបូង៖ គ្រោងការណ៍កាន់តែស្មុគស្មាញបន្តិច។
កម្មវិធីជំនួយសម្រាប់ LogStash ដែលបញ្ចូលទិន្នន័យដោយផ្ទាល់ទៅក្នុង ClickHouse បានជួយច្រើននៅទីនេះ។ សមាសភាគនេះត្រូវបានដាក់ពង្រាយនៅលើម៉ាស៊ីនមេដូចគ្នាជាមួយនឹងមូលដ្ឋានទិន្នន័យខ្លួនឯង។ ដូច្នេះ និយាយជាទូទៅ វាមិនត្រូវបានណែនាំឱ្យធ្វើបែបនេះទេ ប៉ុន្តែតាមទស្សនៈជាក់ស្តែង ដើម្បីកុំឱ្យបង្កើតម៉ាស៊ីនមេដាច់ដោយឡែក ខណៈពេលដែលវាត្រូវបានដាក់ពង្រាយនៅលើម៉ាស៊ីនមេតែមួយ។ យើងមិនបានសង្កេតឃើញការបរាជ័យ ឬជម្លោះធនធានណាមួយជាមួយមូលដ្ឋានទិន្នន័យទេ។ លើសពីនេះទៀតវាគួរតែត្រូវបានកត់សម្គាល់ថាកម្មវិធីជំនួយមានយន្តការ retray ក្នុងករណីមានកំហុស។ ហើយក្នុងករណីមានកំហុស កម្មវិធីជំនួយសរសេរទៅថាសមួយបាច់នៃទិន្នន័យដែលមិនអាចបញ្ចូលបាន (ទម្រង់ឯកសារគឺងាយស្រួល៖ បន្ទាប់ពីកែសម្រួល អ្នកអាចបញ្ចូលបាច់ដែលបានកែបានយ៉ាងងាយស្រួលដោយប្រើ clickhouse-client)។
បញ្ជីពេញលេញនៃកម្មវិធីដែលប្រើក្នុងគ្រោងការណ៍ត្រូវបានបង្ហាញក្នុងតារាង៖
បញ្ជីកម្មវិធីដែលបានប្រើ
ចំណងជើង
បរិយាយ
តំណភ្ជាប់ទៅការចែកចាយ
NGINX
ប្រូកស៊ីបញ្ច្រាសសម្រាប់ការរឹតបន្តឹងការចូលប្រើតាមច្រកនិងការរៀបចំការអនុញ្ញាត
បច្ចុប្បន្ននេះមិនត្រូវបានប្រើក្នុងគ្រោងការណ៍នេះទេ។
ឯកសារប៊ីត
ការផ្ទេរឯកសារកំណត់ហេតុ។
(ការចែកចាយសម្រាប់វីនដូ 64 ប៊ីត) ។
LogStash
អ្នកប្រមូលកំណត់ហេតុ។
ប្រើដើម្បីប្រមូលកំណត់ហេតុពី FileBeat ក៏ដូចជាដើម្បីប្រមូលកំណត់ហេតុពីជួរ RabbitMQ (សម្រាប់ម៉ាស៊ីនមេដែលមានទីតាំងនៅ DMZ ។ )
Logstash- ទិន្នផល- clickhouse
កម្មវិធីជំនួយ Loagstash សម្រាប់ផ្ទេរកំណត់ហេតុទៅមូលដ្ឋានទិន្នន័យ 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
ចុចផ្ទះ
ការផ្ទុកកំណត់ហេតុ
ចំណាំ។ ចាប់ផ្តើមពីខែសីហា ឆ្នាំ 2018 ការបង្កើត rpm "ធម្មតា" សម្រាប់ RHEL បានបង្ហាញខ្លួននៅក្នុងឃ្លាំង Yandex ដូច្នេះអ្នកអាចសាកល្បងប្រើពួកវាបាន។ នៅពេលដំឡើង យើងកំពុងប្រើកញ្ចប់ដែលចងក្រងដោយ Altinity។
ហ្គ្រេណាណា
ការមើលឃើញនៃកំណត់ហេតុ។ ការដំឡើងផ្ទាំងគ្រប់គ្រង
Redhat & Centos (64 ប៊ីត) - កំណែចុងក្រោយបំផុត។
ប្រភពទិន្នន័យ ClickHouse សម្រាប់ Grafana 4.6+
កម្មវិធីជំនួយសម្រាប់ Grafana ជាមួយប្រភពទិន្នន័យ ClickHouse
LogStash
ចូលរ៉ោតទ័រពី FileBeat ទៅជួរ RabbitMQ ។
ចំណាំ។ ជាអកុសល FileBeat មិនមានលទ្ធផលដោយផ្ទាល់ទៅ RabbitMQ ទេ ដូច្នេះតំណភ្ជាប់កម្រិតមធ្យមក្នុងទម្រង់ Logstash ត្រូវបានទាមទារ។
RabbitMQ
ជួរសារ។ នេះគឺជាបណ្តុំនៃធាតុកំណត់ហេតុនៅក្នុង DMZ
Erlang Runtime (ទាមទារសម្រាប់ RabbitMQ)
ពេលដំណើរការ Erlang ទាមទារសម្រាប់ RabbitMQ ដើម្បីធ្វើការ
ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេជាមួយមូលដ្ឋានទិន្នន័យ ClickHouse ត្រូវបានបង្ហាញក្នុងតារាងខាងក្រោម៖
ចំណងជើង
តម្លៃ
ការកត់សម្គាល់
ការកំណត់រចនាសម្ព័ន្ធ
HDD: 40GB
សតិ: 8GB
ដំណើរការ៖ ស្នូល 2 2 GHz
អ្នកគួរតែយកចិត្តទុកដាក់ចំពោះគន្លឹះសម្រាប់ការប្រើប្រាស់មូលដ្ឋានទិន្នន័យ ClickHouse ()
កម្មវិធីពេញប្រព័ន្ធ
ប្រព័ន្ធប្រតិបត្តិការ៖ Red Hat Enterprise Linux Server (Maipo)
JRE (Java 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;យើងប្រើតម្លៃលំនាំដើមសម្រាប់ការបែងចែក (ប្រចាំខែ) និងសន្ទស្សន៍ granularity ។ វាលទាំងអស់ត្រូវគ្នាទៅនឹងធាតុកំណត់ហេតុ IIS សម្រាប់ការកត់ត្រាសំណើ http ។ ដោយឡែកពីគ្នា យើងកត់សំគាល់ថាមានវាលដាច់ដោយឡែកសម្រាប់រក្សាទុកស្លាក utm (ពួកវាត្រូវបានញែកនៅដំណាក់កាលនៃការបញ្ចូលទៅក្នុងតារាងពីវាលខ្សែអក្សរសំណួរ)។
ដូចគ្នានេះផងដែរ វាលប្រព័ន្ធជាច្រើនត្រូវបានបន្ថែមទៅក្នុងតារាង ដើម្បីរក្សាទុកព័ត៌មានអំពីប្រព័ន្ធ សមាសធាតុ និងម៉ាស៊ីនមេ។ សម្រាប់ការពិពណ៌នាអំពីវាលទាំងនេះ សូមមើលតារាងខាងក្រោម។ នៅក្នុងតារាងមួយ យើងរក្សាទុកកំណត់ហេតុសម្រាប់ប្រព័ន្ធជាច្រើន។
ចំណងជើង
បរិយាយ
ឧទាហរណ៍:
fld_app_name
ឈ្មោះកម្មវិធី/ប្រព័ន្ធ
តម្លៃត្រឹមត្រូវ៖
- site1.domain.com គេហទំព័រខាងក្រៅ ១
- site2.domain.com គេហទំព័រខាងក្រៅ ១
- internal-site1.domain.local គេហទំព័រផ្ទៃក្នុង ១
site1.domain.com
fld_app_module
ម៉ូឌុលប្រព័ន្ធ
តម្លៃត្រឹមត្រូវ៖
- គេហទំព័រ - គេហទំព័រ
- svc - សេវាកម្មគេហទំព័រ
- intgr — សេវាកម្មរួមបញ្ចូលគេហទំព័រ
- បូ - អ្នកគ្រប់គ្រង (BackOffice)
បណ្ដាញ
fld_website_name
ឈ្មោះគេហទំព័រនៅក្នុង IIS
ប្រព័ន្ធជាច្រើនអាចត្រូវបានដាក់ឱ្យប្រើប្រាស់នៅលើម៉ាស៊ីនមេតែមួយ ឬសូម្បីតែឧទាហរណ៍ជាច្រើននៃម៉ូឌុលប្រព័ន្ធមួយ។
គេហទំព័រមេ
fld_server_name
ឈ្មោះម៉ាស៊ីនមេ
web1.domain.com
fld_log_file_name
ផ្លូវទៅកាន់ឯកសារកំណត់ហេតុនៅលើម៉ាស៊ីនមេ
ពី៖inetpublogsLogFiles
W3SVC1u_ex190711.log
នេះអនុញ្ញាតឱ្យអ្នកបង្កើតក្រាហ្វក្នុង Grafana ប្រកបដោយប្រសិទ្ធភាព។ ឧទាហរណ៍ មើលសំណើពីផ្នែកខាងមុខនៃប្រព័ន្ធជាក់លាក់មួយ។ នេះគឺស្រដៀងគ្នាទៅនឹងបញ្ជរគេហទំព័រនៅក្នុង 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.ការពិពណ៌នាអំពីសមាសធាតុដែលបានប្រើ
ឯកសារប៊ីត។ ការផ្ទេរឯកសារកំណត់ហេតុ
សមាសភាគនេះត្រួតពិនិត្យការផ្លាស់ប្តូរទៅឯកសារនៅលើថាស ហើយបញ្ជូនព័ត៌មានទៅ 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: ~LogStash ។ អ្នកប្រមូលកំណត់ហេតុ
សមាសភាគនេះត្រូវបានរចនាឡើងដើម្បីទទួលបានកំណត់ត្រាពី FileBeat (ឬតាមរយៈជួរ RabbitMQ) ញែក និងបញ្ចូលពួកវាជាបាច់ទៅក្នុងមូលដ្ឋានទិន្នន័យ ClickHouse ។
ដើម្បីបញ្ចូលទៅក្នុង ClickHouse សូមប្រើកម្មវិធីជំនួយ Logstash-output-clickhouse ។ កម្មវិធីជំនួយ Logstash មានយន្តការសម្រាប់ការដកសំណើ ប៉ុន្តែក្នុងអំឡុងពេលបិទជាប្រចាំ វាជាការប្រសើរក្នុងការបញ្ឈប់សេវាកម្មដោយខ្លួនឯង។ នៅពេលឈប់ សារនឹងកកកុញនៅក្នុងជួរ RabbitMQ ដូច្នេះប្រសិនបើការឈប់មានរយៈពេលយូរ នោះវាជាការប្រសើរក្នុងការបញ្ឈប់ Filebeats នៅលើម៉ាស៊ីនមេ។ នៅក្នុងគ្រោងការណ៍ដែល RabbitMQ មិនត្រូវបានប្រើ (នៅលើបណ្តាញមូលដ្ឋាន Filebeat ដោយផ្ទាល់ផ្ញើកំណត់ហេតុទៅ Logstash) 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"
}
}
}pipelines.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"ClickHouse។ ការផ្ទុកកំណត់ហេតុ
កំណត់ហេតុសម្រាប់ប្រព័ន្ធទាំងអស់ត្រូវបានរក្សាទុកក្នុងតារាងតែមួយ (សូមមើលនៅដើមអត្ថបទ)។ វាត្រូវបានរចនាឡើងដើម្បីរក្សាទុកព័ត៌មានអំពីសំណើ៖ ប៉ារ៉ាម៉ែត្រទាំងអស់គឺស្រដៀងគ្នាសម្រាប់ទម្រង់ផ្សេងៗគ្នា ឧទាហរណ៍ កំណត់ហេតុ IIS, apache និងកំណត់ហេតុ nginx ។ សម្រាប់កំណត់ហេតុកម្មវិធី ដែលឧទាហរណ៍ កំហុស សារព័ត៌មាន ការព្រមានត្រូវបានកត់ត្រា តារាងដាច់ដោយឡែកមួយនឹងត្រូវបានផ្តល់ជូនជាមួយនឹងរចនាសម្ព័ន្ធសមស្រប (បច្ចុប្បន្ននៅដំណាក់កាលរចនា)។
នៅពេលរចនាតារាង វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការសម្រេចចិត្តលើសោចម្បង (ដែលទិន្នន័យនឹងត្រូវបានតម្រៀបកំឡុងពេលផ្ទុក)។ កម្រិតនៃការបង្ហាប់ទិន្នន័យ និងល្បឿនសំណួរអាស្រ័យលើនេះ។ នៅក្នុងឧទាហរណ៍របស់យើងគន្លឹះគឺ
បញ្ជាទិញដោយ (fld_app_name, fld_app_module, logdatetime)
នោះគឺតាមឈ្មោះប្រព័ន្ធ ឈ្មោះនៃសមាសភាគប្រព័ន្ធ និងកាលបរិច្ឆេទនៃព្រឹត្តិការណ៍។ ដំបូងកាលបរិច្ឆេទនៃព្រឹត្តិការណ៍បានមកមុន។ បន្ទាប់ពីផ្លាស់ទីវាទៅកន្លែងចុងក្រោយ សំណួរចាប់ផ្តើមដំណើរការលឿនជាងប្រហែលពីរដង។ ការផ្លាស់ប្តូរសោចម្បងនឹងតម្រូវឱ្យបង្កើតតារាងឡើងវិញ និងផ្ទុកទិន្នន័យឡើងវិញ ដូច្នេះ ClickHouse នឹងតម្រៀបទិន្នន័យឡើងវិញនៅលើថាស។ នេះគឺជាប្រតិបត្តិការដ៏លំបាក ដូច្នេះគួរតែគិតឱ្យបានហ្មត់ចត់ជាមុនអំពីអ្វីដែលគួរបញ្ចូលក្នុងសោតម្រៀប។
វាគួរតែត្រូវបានកត់សម្គាល់ផងដែរថាប្រភេទទិន្នន័យ LowCardinality បានបង្ហាញខ្លួននៅក្នុងកំណែថ្មីៗ។ នៅពេលប្រើវា ទំហំនៃទិន្នន័យដែលបានបង្ហាប់ត្រូវបានកាត់បន្ថយយ៉ាងខ្លាំងសម្រាប់វាលទាំងនោះដែលមានកម្រិតទាប (ជម្រើសតិចតួច)។
បច្ចុប្បន្នយើងកំពុងប្រើកំណែ 19.6 ហើយយើងគ្រោងនឹងព្យាយាមធ្វើបច្ចុប្បន្នភាពទៅកំណែចុងក្រោយបំផុត។ ពួកវាមានលក្ខណៈពិសេសដ៏អស្ចារ្យដូចជា Adaptive Granularity, Skiping Indices និង DoubleDelta codec ជាឧទាហរណ៍។
តាមលំនាំដើម កំឡុងពេលដំឡើង កម្រិតកំណត់រចនាសម្ព័ន្ធកំណត់ហេតុត្រូវបានកំណត់ដើម្បីតាមដាន។ កំណត់ហេតុត្រូវបានបង្វិល និងទុកក្នុងប័ណ្ណសារ ប៉ុន្តែក្នុងពេលតែមួយពួកវាពង្រីករហូតដល់មួយជីហ្គាបៃ។ ប្រសិនបើមិនមានតម្រូវការទេនោះ អ្នកអាចកំណត់កម្រិតជាការព្រមាន នោះទំហំកំណត់ហេតុនឹងថយចុះយ៉ាងខ្លាំង។ ការកំណត់ការកត់ត្រាត្រូវបានបញ្ជាក់នៅក្នុងឯកសារ 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/nullLogStash ។ ចូលរ៉ោតទ័រពី FileBeat ទៅជួរ RabbitMQ
សមាសភាគនេះត្រូវបានប្រើដើម្បីបញ្ជូនកំណត់ហេតុចេញពី FileBeat ទៅកាន់ជួរ RabbitMQ ។ មានពីរចំណុចនៅទីនេះ៖
- ជាអកុសល FileBeat មិនមានកម្មវិធីជំនួយលទ្ធផលសម្រាប់ការសរសេរដោយផ្ទាល់ទៅ RabbitMQ ទេ។ ហើយមុខងារបែបនេះ វិនិច្ឆ័យដោយការបង្ហោះនៅលើ github របស់ពួកគេ មិនត្រូវបានគ្រោងសម្រាប់ការអនុវត្តនោះទេ។ មានកម្មវិធីជំនួយសម្រាប់ Kafka ប៉ុន្តែសម្រាប់ហេតុផលជាក់លាក់ យើងមិនអាចប្រើវាដោយខ្លួនឯងបានទេ។
- មានតម្រូវការសម្រាប់ការប្រមូលកំណត់ហេតុនៅក្នុង DMZ ។ ដោយផ្អែកលើពួកវា កំណត់ហេតុត្រូវតែត្រូវបានដាក់ជាជួរជាមុនសិន ហើយបន្ទាប់មក LogStash អានកំណត់ត្រាពីជួរខាងក្រៅ។
ដូច្នេះជាពិសេសសម្រាប់ករណីនៃម៉ាស៊ីនមេដែលមានទីតាំងនៅ 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
}
}RabbitMQ ជួរសារ
សមាសភាគនេះត្រូវបានប្រើដើម្បីផ្ទុកធាតុកំណត់ហេតុនៅក្នុង DMZ ។ ការថតត្រូវបានធ្វើតាមរយៈតំណ Filebeat → LogStash ។ ការអានត្រូវបានធ្វើឡើងពីខាងក្រៅ DMZ តាមរយៈ LogStash ។ នៅពេលដំណើរការតាមរយៈ RabbitMQ ប្រហែល 4 ពាន់សារក្នុងមួយវិនាទីត្រូវបានដំណើរការ។
ការកំណត់ផ្លូវសារត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយឈ្មោះប្រព័ន្ធ ពោលគឺផ្អែកលើទិន្នន័យកំណត់រចនាសម្ព័ន្ធ FileBeat ។ សារទាំងអស់ចូលទៅក្នុងជួរមួយ។ ប្រសិនបើសម្រាប់ហេតុផលមួយចំនួន សេវាកម្មតម្រង់ជួរត្រូវបានបញ្ឈប់ វានឹងមិននាំទៅរកការបាត់បង់សារទេ៖ FileBeats នឹងទទួលបានកំហុសក្នុងការតភ្ជាប់ ហើយនឹងបញ្ឈប់ការផ្ញើជាបណ្តោះអាសន្ន។ ហើយ LogStash ដែលអានពីជួរក៏នឹងទទួលបានកំហុសបណ្តាញដែរ ហើយរង់ចាំការភ្ជាប់ឡើងវិញ។ ក្នុងករណីនេះ ទិន្នន័យនឹងមិនត្រូវបានសរសេរទៅមូលដ្ឋានទិន្នន័យទៀតទេ។
ការណែនាំខាងក្រោមត្រូវបានប្រើដើម្បីបង្កើត និងកំណត់រចនាសម្ព័ន្ធជួរ៖
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"ហ្គ្រាហ្វាណា។ ផ្ទាំងគ្រប់គ្រង
សមាសភាគនេះត្រូវបានប្រើដើម្បីមើលឃើញទិន្នន័យត្រួតពិនិត្យ។ ក្នុងករណីនេះ អ្នកត្រូវដំឡើងប្រភពទិន្នន័យ ClickHouse សម្រាប់កម្មវិធីជំនួយ Grafana 4.6+ ។ យើងត្រូវកែប្រែវាបន្តិច ដើម្បីបង្កើនប្រសិទ្ធភាពនៃដំណើរការតម្រង SQL នៅលើផ្ទាំងគ្រប់គ្រង។
ឧទាហរណ៍ យើងប្រើអថេរ ហើយប្រសិនបើពួកវាមិនត្រូវបានបញ្ជាក់ក្នុងវាលតម្រង នោះយើងមិនចង់ឱ្យវាបង្កើតលក្ខខណ្ឌនៅក្នុង WHERE នៃទម្រង់ (uriStem = "AND uriStem !=") ។ ក្នុងករណីនេះ ClickHouse នឹងអានជួរឈរ uriStem ។ ដូច្នេះ យើងបានសាកល្បងជម្រើសផ្សេងៗ ហើយទីបំផុតបានជួសជុលកម្មវិធីជំនួយ (ម៉ាក្រូ $valueIfEmpty) ដើម្បីត្រឡប់លេខ 1 ក្នុងករណីតម្លៃទទេ ដោយមិននិយាយពីជួរឈរខ្លួនឯង។
ហើយឥឡូវនេះអ្នកអាចប្រើសំណួរនេះសម្រាប់ក្រាហ្វ
$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សេចក្តីសន្និដ្ឋាន
រូបរាងនៃមូលដ្ឋានទិន្នន័យ ClickHouse បានក្លាយជាព្រឹត្តិការណ៍សំខាន់មួយនៅក្នុងទីផ្សារ។ វាពិបាកក្នុងការស្រមៃថា ក្នុងពេលភ្លាមៗ ដោយមិនគិតថ្លៃទាំងស្រុង យើងបានបំពាក់ដោយឧបករណ៍ដ៏មានឥទ្ធិពល និងជាក់ស្តែងសម្រាប់ធ្វើការជាមួយទិន្នន័យធំ។ ជាការពិតណាស់ នៅពេលដែលតម្រូវការកើនឡើង (ឧទាហរណ៍ ការបំបែក និងការចម្លងទៅកាន់ម៉ាស៊ីនមេច្រើន) គ្រោងការណ៍នឹងកាន់តែស្មុគស្មាញ។ ប៉ុន្តែយោងទៅតាមចំណាប់អារម្មណ៍ដំបូងការធ្វើការជាមួយមូលដ្ឋានទិន្នន័យនេះគឺរីករាយណាស់។ វាច្បាស់ណាស់ថាផលិតផលត្រូវបានបង្កើតឡើង "សម្រាប់មនុស្ស" ។
បើប្រៀបធៀបទៅនឹង ElasticSearch តម្លៃនៃការរក្សាទុក និងដំណើរការកំណត់ហេតុ យោងតាមការប៉ាន់ស្មានបឋមត្រូវបានកាត់បន្ថយពីប្រាំទៅដប់ដង។ ម្យ៉ាងវិញទៀត ប្រសិនបើសម្រាប់បរិមាណទិន្នន័យបច្ចុប្បន្ន យើងនឹងត្រូវរៀបចំចង្កោមម៉ាស៊ីនជាច្រើន បន្ទាប់មកនៅពេលប្រើ ClickHouse យើងត្រូវការតែម៉ាស៊ីនថាមពលទាបមួយប៉ុណ្ណោះ។ បាទ ពិតណាស់ ElasticSearch ក៏មានយន្តការបង្ហាប់ទិន្នន័យនៅលើថាស និងមុខងារផ្សេងទៀតដែលអាចកាត់បន្ថយការប្រើប្រាស់ធនធានយ៉ាងច្រើន ប៉ុន្តែបើប្រៀបធៀបទៅនឹង ClickHouse វានឹងត្រូវការការចំណាយកាន់តែច្រើន។
ដោយគ្មានការបង្កើនប្រសិទ្ធភាពពិសេសណាមួយនៅលើផ្នែករបស់យើង ជាមួយនឹងការកំណត់លំនាំដើម ការផ្ទុកទិន្នន័យ និងការទាញយកទិន្នន័យពីមូលដ្ឋានទិន្នន័យដំណើរការក្នុងល្បឿនដ៏អស្ចារ្យ។ យើងមិនទាន់មានទិន្នន័យច្រើននៅឡើយទេ (ប្រហែល 200 លានកំណត់ត្រា) ប៉ុន្តែម៉ាស៊ីនមេខ្លួនឯងខ្សោយ។ យើងអាចប្រើឧបករណ៍នេះនាពេលអនាគតសម្រាប់គោលបំណងផ្សេងទៀតដែលមិនទាក់ទងនឹងការរក្សាទុកកំណត់ហេតុ។ ឧទាហរណ៍ សម្រាប់ការវិភាគពីចុងដល់ចប់ ក្នុងវិស័យសុវត្ថិភាព ការរៀនម៉ាស៊ីន។
នៅចុងបញ្ចប់បន្តិចអំពីគុណសម្បត្តិនិងគុណវិបត្តិ។
Минусы
- កំពុងផ្ទុកកំណត់ត្រាជាបាច់ធំ។ នៅលើដៃមួយ នេះគឺជាលក្ខណៈពិសេសមួយ ប៉ុន្តែអ្នកនៅតែត្រូវប្រើសមាសធាតុបន្ថែមដើម្បីកត់ត្រាសតិបណ្ដោះអាសន្ន។ កិច្ចការនេះមិនតែងតែសាមញ្ញទេ ប៉ុន្តែនៅតែអាចដោះស្រាយបាន។ ហើយខ្ញុំចង់ធ្វើឱ្យគ្រោងការណ៍សាមញ្ញ។
- មុខងារកម្រនិងអសកម្មមួយចំនួន ឬមុខងារថ្មីជារឿយៗខូចនៅក្នុងកំណែថ្មី។ នេះធ្វើឱ្យមានការព្រួយបារម្ភ ដោយកាត់បន្ថយការចង់ដំឡើងកំណែទៅកំណែថ្មី។ ឧទាហរណ៍ ម៉ាស៊ីនតារាង Kafka គឺជាមុខងារដ៏មានប្រយោជន៍ដែលអនុញ្ញាតឱ្យអ្នកអានព្រឹត្តិការណ៍ដោយផ្ទាល់ពី Kafka ដោយមិនចាំបាច់អនុវត្តអ្នកប្រើប្រាស់។ ប៉ុន្តែការវិនិច្ឆ័យដោយចំនួនបញ្ហានៅលើ Github យើងនៅតែប្រយ័ត្នចំពោះការប្រើប្រាស់ម៉ាស៊ីននេះនៅក្នុងការផលិត។ ទោះជាយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកមិនធ្វើចលនាភ្លាមៗទៅចំហៀង ហើយប្រើមុខងារមូលដ្ឋានទេនោះ វាដំណើរការដោយស្ថេរភាព។
ផត
- មិនបន្ថយល្បឿនទេ។
- កម្រិតចូលទាប។
- ប្រភពបើកចំហ។
- ឥតគិតថ្លៃ។
- អាចធ្វើមាត្រដ្ឋានបាន (ការចម្លង/ការចម្លងចេញពីប្រអប់)
- រួមបញ្ចូលនៅក្នុងការចុះឈ្មោះកម្មវិធីរុស្ស៊ីដែលត្រូវបានណែនាំដោយក្រសួងទំនាក់ទំនង។
- ភាពអាចរកបាននៃការគាំទ្រផ្លូវការពី Yandex.
ប្រភព: www.habr.com