Praeteritis his paucis annis, temporis series databases ab re extranea versa (maxime propria adhibita vel in rationibus vigilantiae apertis (et ad solutiones specificas ligatas) vel in inceptis Big Datarum) in "productum dolor". In territorio Foederationis Russicae, gratias speciales Yandex et ClickHouse tribuendae sunt. Hucusque, si permagna temporis notitiarum serie opus condere debes, vel convenire debes cum monstrum Hadoop acervum construendi et conservandum, vel cum singulis protocollis pro singulis systematis communicandum.
Videri potest quod in 2019 articulus, de quo TSDB utens valet, una tantum sententia constabit: "iusta utere ClickHouse". Sed nuances sunt.
Re quidem, ClickHouse active augetur, basis usoris crescit, auxiliumque valde activum est, sed obsides facti sumus publico successu ClickHouse, quae alias obumbravit, fortasse solutiones validiores/fideles?
Ineunte anno proxime praeterito nostram propriam vigilantiam ratiocinari coepimus, per quem quaestio orta est de opportunitate datorum ad notitias recondendas. De historia huius electionis hic loqui volo.
DE PECCATO quaestio
Ante omnia praefatio necessaria. Cur nostra magna ratio omnino opus est et quomodo ordinatum est?
Operas in 2008 sustentare coepimus, et per 2010 manifestatum est difficile factum esse notitias aggregatas de processibus infrastructuris in clientelam occurrentibus cum solutionibus tunc temporis (loquimur, Deus, ignosce mihi, Cacti, Zabbix. et exstare Graphite).
Praecipua nostra requisita erant:
- auxilio clientium (tunc - justo et in futurum centenis) intra unum systema et simul praesentiam systematis intenti centralised;
- flexibilitas in systemate acris administrandi (exaltatio summorum inter officiarios praefectos, scheduling, basis cognitionis);
- facultas graphi profundius explicatur (Zabbix eo tempore graphs in modum picturarum reddit);
- longum tempus reposita magna copia notitiarum (annum vel amplius) et facultatem cito recuperandi.
In hoc articulo quaeritur in ultimo puncto.
Loquens de repositione, requisita erant haec:
- ratio cito laborandum est;
- optandum est ut ratio SQL interfaciei habeat;
- systema stabilis esse debet ac basim usoris activam habere et sustentare (olim praemittebatur cum necessitate ad systemata sustinenda sicut MemcacheDB, quae iam non evoluta erat, vel repositionis MooseFS distributa, cuius venator cimex in Sinica servabatur; hanc fabulam ad propositum nostrum repetere noluimus);
- obsequio theorematis CAP: Consitentia (requiritur) - notitia debet esse in hodiernum diem, nolumus nos intenti systematis administratione non recipere novas notitias et summas exspuere circa notitiarum non-adventus pro omnibus inceptis; Partitio Tolerantia - Discidium ratio cerebri obtinere nolumus; Disponibilitas (non critica, si imago activa est) - possumus nosmetipsos ad tergum systematis accidentis flectere, codice utentes.
Incommode, tunc MySQL evasit specimen solutionis nobis. Nostra notitia compages valde simplex erat: id, contra id, indicationem et valorem; ieiunium notitiarum calidarum sampling per magnum quiddam piscinae praestatum est, et notitia historica sampling a SSD conservata est.
Ita specimen notitiarum duarum hebdomadarum recentium consecuti sumus, cum singillatim usque ad alterum 200 ms antequam notitia omnino reddita est, et in hoc systemate satis diu viximus.
Interea temporis spatium crevit notitia. Ab anno 2016, data volumina decem terabytarum pervenerunt, quae in contextu magni pretii SSD tabulariorum conductorum erant.
Hoc tempore, databases columnares late patentes facti sunt, quod de actu cogitare coepimus: in datorum columnaribus, in columnis, ut potes, notitia reponitur, et si nostras notitias spectes, perspicere facile est. numerus duplicatorum qui potuit, in Si database columnari uteris, eum comprime utendo compressione.
Nihilominus, societatis systema clavis stabiliter laborandum permansit, et experiri nolebam cum commutatione ad aliquid aliud.
In 2017, in colloquio Percona Live in San Jose, Clickhouse tincidunt primum se probabiliter annuntiavit. Primo aspectu, ratio productionis-parata erat (bene, Yandex.Metrica est dura ratio productionis), firmamentum erat celere et simplex, et, praesertim, operatio simplex erat. Cum MMXVIII, processus transitus incepimus. Sed eo tempore multa erant "adulta" et systemata TSDB temporis probata, et decrevimus tempus multum vacare et alterum comparare, ut certas solutiones Clickhouse nullae alternae essent, secundum exigentias nostras.
Praeter requisita repositionis iam definita, novae apparuerunt;
- nova ratio saltem eadem agendi ratione ac MySQL in eadem ferramentorum copia praebere debet;
- ceptaculum novae systematis minus signanter spatium assumere debet;
- DBMS adhuc facile administrare debet;
- Applicationem mutare minime volui cum in DBMS mutando.
Quas rationes considerare incipimus?
Apache Alveare / Apache Impala
Acervus senex proelio probatus Hadoop. Interface SQL essentialiter aedificatum est super notitias actarum in formatis indigenis HDFS.
Pros.
- Operatione stabili, notitia scala facillime.
- Sunt columnae solutiones pro notitia repono (minus spatii).
- Celerrimus exsecutio officiorum parallelorum cum facultates in promptu sunt.
Cons.
- Hadoop suus et difficile est uti. Si parati non sumus ad solutionem paratam in nube (nec parati sumus ad sumptus), totum acervum congregari et sustentari per administratorum manus debebit, et vere nolumus. hoc.
- Data est aggregatur .
Sed:
Celeritas scalis numerus servorum computandi perficitur. Simpliciter, si magna societas sumus, in analyticis versamur, et criticum est negotium ut notitias quam celerrime aggregare (etiam magno opum computandi copia utendi), haec nostra electio esse potest. Sed parati non eramus classem ferrariam multiplicare ad operas accelerandas.
Druid/Pinot
Multo magis de TSDB specie, sed iterum acervus Hadoop.
Sunt .
Paucis verbis: Druid/Pinot vide melius quam Clickhouse in quibus casibus:
- Habetis heterogeneam notitiarum naturam (in nostro casu solum temporas metri ministrantis commemoramus, et re vera haec est una tabula. Sed esse possunt alii casus: apparatum temporis series, series temporis oeconomicae, etc. propriam structuram, quam necesse est aggregata et discursum).
- Etiam sit amet elit mauris.
- Tabulae et notitiae cum temporis serie apparent et evanescunt (id est, nonnulla copia notitiarum pervenerunt, enucleata et deleta sunt).
- Nulla est perspicua regula qua partiri potest notitia.
In casibus oppositis, ClickHouse melius facit, et haec causa est.
clickhouse
- SQL-sicut
- Facilis expedita.
- Homines opera dicunt.
Ad tentationem shortlisted accipit.
InfluxDB
Peregrina optio ad ClickHouse. De minusibus: High Availability tantum adest in versione commerciali, sed comparanda est.
Ad tentationem shortlisted accipit.
Venus
Ex altera parte novimus eam adhibitam esse ad reponendas temporarias metricas per eiusmodi systematum vigilantias, v. gr. or OkMeter. Sed specialia sunt.
Cassandra in sensu tradito non est columnaris database. Spectat magis ut ordo sententiarum, sed unaquaeque linea numerum columnarum diversos habere potest, ut facile visum columnarem ordinare possit. Hoc sensu patet quod, limite 2 miliarda columnarum, aliquas notitias in columnis condere posse (et simul series). Exempli gratia, in MySQL limitatio 4096 columnarum est et in codice 1117 errorem facile offendi, si idem facere conaris.
Cassandra machina in magna copia notitiarum in systemate distributo sine domino sumitur, et theorema supradicta Cassandra plus est de AP, hoc est de notitia promptitudinis et resistentiae partitionis. Hoc igitur instrumentum magnum esse potest si tantum huic datorum opus est scribere et raro ex eo legeris. Atque hic consentaneum est Cassandram uti "frigus" repono. Hoc est, ut diuturnum, certum locum condere ingentes copiae notitiarum historicarum, quae raro requiruntur, sed insanabiles si necesse est. Tamen propter complementum hoc etiam probabimus. Sed, ut ante dixi, nullum est codicem ad solutionem datorum delectorum actuose rescribere, sic paulo strictius probabimus - quin structuram datorum speciebus Cassandrae adaptemus.
Prometheum
Bene curiositate placuit explorare opus repositionis Promethei - tantum intellegere utrum velociores simus an tardiores solutionibus currentibus et quantopere.
Probatio methodi et eventus
Ita probavimus 5 databases in sequentibus 6 configurationibus: ClickHouse (1 node), ClickHouse (distributa mensa pro 3 nodis), InfluxDB, Mysql 8, Cassandra (3 nodi) et Prometheus. Probatio consilii talis est:
- Notatio historica notitia hebdomadae (840 decies centena millia per diem; 208 milia metrica);
- onus recordationis generamus (6 onus modi considerabantur, vide infra);
- Parallela cum notatione, periodice excerpta facimus, petitiones usoris cum chartis operantis aemulantes. Ut res nimium non inpedirent, notitias metricas 10 delegimus (quod prorsus quot sunt in CPU graphio) per hebdomadam.
Oneratis imitando mores nostri agentis vigilantia, quae bona unicuique metrica semel singulis 15 secundis emittit. In eodem tempore intersunt variae;
- numerus metri in quem scribitur;
- inter- mittens valores metricos;
- praepostere magnitudine.
De praepostere magnitudine. Cum non commendatum sit ut omnes fere experimentales databases nostras singulis insertis oneratis, egebimus nullam, quae metros et circulos in circulos ineuntes colligit et eas datorum quasi massam insertas scribit.
Etiam, ut melius intelligatur quomodo notitias receptas interpretandas, cogitemus nos non solum fasciculum metri mittens, sed metrici in servientibus - 125 metrics per servers ordinantur. Hic cultor simpliciter ens virtuale est - modo intellegendum est, exempli gratia, 10000 metrice respondere circiter 80 servientibus.
Et hic, cum omnia haec in ratione habita sint, modia oneraria scribenda sunt 6 datorum nostrorum:
Circa primum quaeruntur duo. Primo, quia Cassandrae hae moles nimis magnae evaserunt, ibi valores 50 vel 100 usi sumus. ipsa it et notitias e fontibus metricis colligit (et etiam pushgateway, nomine, condicionem fundamentaliter non mutat), onera correspondentia adhibita confisus statice complexionis ad effectum adducuntur.
Proventus examinatoria sunt haec:
Quod est dignum: fantastically fast exempla ex Prometheo, horrida exempla ex Cassandra, ingratum lentum exempla ex InfluxDB; Secundum celeritatem memoriae, ClickHouse vicit omnes, et Prometheus non participat certamen, quia se inserit et nihil metimur.
Ut a praecessi,: ClickHouse et InfluxDB se optimum esse ostendit, sed botrus ab Influxu solum aedificari potest ob versionis Incepti, quae pecunia constat, dum nihil constat et in Russia factum est. Consentaneum est in USA electum probabiliter esse in favorem InfluxDB, et in patria nostra in favorem ClickHouse.
Source: www.habr.com