Hi omnes! Nomen mihi est Golov Nikolay. Antea apud Avito laboravi et Datam rostris sex annis administravi, hoc est, in omnibus databases laboravi: analytica (Vertica, ClickHouse), effusis et OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Hoc tempore de pluribus databases - valde diversis et insolitis egi et cum eorum usu incognitis.
I'm currently working at ManyChat. Essentialiter, hoc est satus - novum, ambitiose et celeriter crescens. Et cum primum societatem adiunxi, quaestio classica orta est: "Quid nunc ex DBMS et foro datorum sumo adulescens?"
In hoc articulo, secundum meam relationem Huic quaestioni respondebo. Video versionem fama est available at .
Vulgo notae databases 2020
Suus 2020, circumspexi et tria database genera vidi.
Primum genus - classic OLTP databases: PostgreSQL, SQL Servo, Oraculum, MySQL. Iam olim scripta sunt, sed adhuc pertinentes quia tam familiares erant cum communitate elit.
Secundum genus est bases a "nulla". A classicis exemplaribus discedere conati sunt, SQL, traditionales structuras et ACID relinquentes, constructis-sharding aliisque lineamentis attractivis addere. Verbi gratia, hoc est Cassandra, MongoDB, Redis vel Tarantool. Omnes hae solutiones volebant mercatum aliquid fundamentaliter novum offerre ac suum angulum occupabant, quod ad quaedam negotia maxime commoda evasit. Has databases cum termino umbellae NOSQL denotabo.
"Zeros" supra, nos in databases NOSQL usi sumus, et mundus, ex mea parte, proximum gradum - ad managed databases. Haec databases eundem nucleum habent ac databases classic OLTP vel novos NoSQL. Sed DBA et DevOps non opus habent, ac ferramenta in nubibus administrata currunt. Elit enim, hoc est "solum turpe" quod alicubi operatur, sed nemo curat quomodo institutum est in calculonis, qui servo figuram fecit et qui illud updates est.
Exempla talium database:
- AWS RDS involucrus administratus est pro PostgreSQL/MySQL.
- DynamoDB est analogum AWS documenti innixum database, simile Redis et MongoDB.
- Amazon Redshift database analytica managed est.
Hae databases plerumque antiquae sunt, sed in ambitu moderato excitantur, sine ferramentis laborandi.
Nota. Exempla pro ambitu AWS sumuntur, sed eorum analoga etiam sunt in Microsoft Azure, Google Cloud, vel Yandex.Cloud.
Quid hoc novi? In 2020, nulla id.
Servo conceptu
Quid vere novum in mercato in anno 2020 solutiones ministrae vel ministrae sunt.
Experiar exponere quid hoc sit utens exemplo servitii ordinarii vel applicationis tergum.
Ad explicandam applicationem regularem backendi, servo emimus vel emimus, codicem in illum effingo, terminum extra evulgamus et regulariter redditum, electricitatem et operas centrum data. Regula haec est.
Estne alia via? Servitiis servientibus potes.
Quod est umbilicus aditus: nullus est cultor, ne conducit quidem exemplum virtuale in nube. Ad servitium explicandum, codicem (munera) ad repositorium effingo et ad finem divulgandum. Tunc simpliciter pro singulis vocationibus ad hoc munus solvemus, plane neglectis ferramentis ubi supplicium est.
Hanc aditum imaginibus illustrare conabor.
Classic deployment. Servitium habemus cum quodam onere. Duos instantias suscitamus: corporis ministratores vel instantias in AWS. Petitiones externae his instantiis mittuntur et ibi discesserunt.
Ut videre potes in tabula, ministri non aeque disponuntur. Una est 100% adhibita, duae petitiones sunt, una tantum 50% parte otiosus. Si non tres petitiones venerint, sed 30 tunc tota ratio oneris obire non poterit et morabor incipiet.
Serverless instruere. In ambitu deserviente, talis servitus instantias vel ministrantes non habet. Piscina quaedam est opum calefactorum - vascula parva parata Docker cum codice functionis instruxit. Systema petitiones externas accipit et pro singulis earum compage inserviens parvam vasculum cum codice levat: hoc maxime petit et continens necat.
Unam petitionem, unum continens petitiones 1000 pro 1000 vasis. Servientes ferramentis instruere iam opus est provisoris nubis. Omnino ab inculto compage occultatur. In quo nobis vocent singulis expetenda conceptam. Exempli gratia, una vocatio venit dies - nos pro una voce solvimus, decies centena millia per minutum pervenerunt - nos pro decies centena millia solvebamus. Vel secundo hoc etiam fit.
Notio evulgandi munus ministrantis est idoneum ad servitium staterem. Et si opus statutum servitii, tunc datorum servituti addimus. In hoc casu, cum ad rem publicam operatur, unumquodque status officium simpliciter scribit et legit ex datorum. Porro ex cuiusvis trium generum datorum initio articuli descripti sunt.
Quae est communis limitatio omnium horum datorum? Haec sunt sumptuum nubis vel ferrariae servientis (vel pluribus servientibus). Nihil refert utrum utamur classico vel datorum administrato, sive Devops et admin habemus necne, adhuc pro ferramentis, electricitate et centri datarum rentalis 24/7 solvimus. Si basim classicam habemus, pro domino et servo solvimus. Si datorum oneratus est valde oneratus, pro X, XX vel XXX servientibus pensamus, et constanter damus.
Praesentia perpetuo reservata ministris in structuram sumptum antea malum necessarium perceptum est. Datorum conventionales alias quoque difficultates habent, ut limites in numero nexuum, restrictiones restrictiones, consensus geo-distinctus β in quibusdam databases quodammodo solvi possunt, sed non omnes simul et non idealiter.
Servo database - theoria
Quaeritur de 2020: Estne possibile ut etiam servientem database facere? Unusquisque audivit de servitore backend... conemur facere servitori datorum?
Mirum hoc sonat, quod in datorum servitute stata, non servitori infrastructurae aptissima est. Eodem tempore, status datorum amplissimus est: gigabytes, terabytes et in analyticis databases etiam petabytis. Non tam facile est illud in vasis leve Docker levari.
Ex altera parte, omnes fere moderni databases logicam et componentium summam continent: transactiones, integritas coordinatio, agendi ratio, relativa dependentia et logica multum. Nam satis multa est logica datorum, parva status satis. Gigabytes et Terabytes directe usi sunt solum parva portio logicae datorum quae in quaestionibus directe exsequendis implicatur.
Itaque idea est: si pars logicae sine statu executioni permittit, cur non basim in partes statas et statas non dividat.
Serverless pro OLAP solutiones
Videamus quid secans database in partes statas et res publicas tamquam exemplis practicis utens videri possit.
Exempli gratia, habemus database analyticam: notitia externa (cylindrici rubri in sinistra), processus ETL, qui onerat notitias in datorum datorum, et analysta quae SQL queries datorum mittit. Haec est res classica notitia CELLA operandi.
In hoc schemate, ETL semel sub condicione peragitur. Tunc necesse est ut ministris quos datorum currit cum notitia repleta ETL, constanter solvere debes, ut quaestionibus mittendi aliquid sit.
Intueamur jocus accessus effectus in AWS Athena Serverless. Nulla perpetuo dedicata hardware in qua reposita notitia recepta est. Hoc loco:
- Usor interrogationem SQL submittit Athenae. Athena optimizer quaestionem SQL analysuit et metadata copia (Metadata) scrutatur pro notitia certa ad quaestionem perficiendam.
- Optimiser, innixus e notitia collecta, necessarias notitias ab externis fontibus in tempus repositionis (dato temporalis) downloads necessarias notat.
- Interrogatio SQL ab usore supplicium in repositione temporaria et effectus usori redditur.
- Temporaria repositio expurgatur et facultates dimittuntur.
In hac architectura tantum pro processu petitionis exequendae solvemus. Nullae petitiones - no aliqua.
Hic accessus laborat et perficitur non solum in Athena Serverless, sed etiam in Imagine Redshift (in AWS).
Exemplum ostendit Athena quod serverless datorum opera in quaestionibus realibus cum decem et centenis Terabytarum notitiarum. Centum Terabytes centum servientium requirent, sed pro illis solvendum non habemus - petitiones solvemus. Cuiusque petitionis celeritas humilis est comparata cum specialibus databases analyticis sicut Vertica, sed tempus downtime non solvimus.
Talis database applicabilis est pro raris analyticis ad-hoc quaestionibus. Exempli gratia, cum hypothesin in aliquod ingens notitiae quantitatem sponte statuimus probare. His casibus perfecta est Athena. Pro iustis postulationibus talis ratio cara est. Hoc in casu, notitias in aliqua solutione speciali condire.
Serverless pro OLTP solutiones
Praecedens exemplum negotium OLAP (analyticum) spectavit. Nunc inspiciamus OLTP opera.
Imaginemur scalabilem PostgreSQL vel MySQL. Instantiam PostgreSQL vel MySQL cum minimis facultatibus, iustam tractatam, suscitemus. Cum instantia plus oneris recipiat, alias replicationes coniungemus quibus partem oneris lectionis distribuemus. Si nullae sunt petitiones vel onera, nos replicas avertimus. Prima instantia est dominus, et cetera sunt replicationes.
Haec idea impletur in database nomine Aurora Serverless AWS. Principium simplex est: postulationes ab applicationibus externis a procuratore classe accipiuntur. Cum onus auget, computare facultates ab instantiis minimis prae-calefactis - nexus quam celerrime factus est. Eodem modo occurrunt instantiae inactivare.
Intus Aurora est conceptus Aurorae Capacity Unit, ACU. Hoc est exemplum. ACU quilibet specifica potest esse dominus vel servus. Quaelibet Unitas Capacitas suum RAM, processus et disci minimi habet. Itaque unus dominus est, reliquae tantum replicationes leguntur.
Numerus harum Aurorae Capacitas Unitates cursus est parameter configurabilis. Quantitas minima potest esse una vel nulla (hoc in casu, datorum non operatur si petitiones non sunt).
Cum base petitiones accipit, procurator classis Aurorae CapacityUnits suscitat, augens facultates systematis perficiendi. Facultas augendi et minuendi facultates systema "juggle" facultates permittit: automatice singulas ACUs (reponentibus novis) evolvunt et omnes venas ad opes subtractas evolvunt.
Aurora Servers basi legendi sarcinam scandere potest. Sed documentum hoc non directe dicit. Ut sentiant multi dominum se levare possunt. Nulla venenatis.
Hoc database bene convenit ad vitare ingentes pecuniae in systemata cum vagus accessu. Exempli gratia, cum MVP creando vel sites negotiatores venalicium card, onus stabile non exspectamus. Proinde, si adsit aditus, non dabimus exempla. Cum onus inopinatum incidit, exempli gratia post expeditionem colloquio vel vendo, turbae hominum situm visit et onus dramatically augetur, Aurora Serverless automatice hoc onus sumit et celeriter absentium opes coniungit (ACU). Tum colloquium transit, quisque de prototypo obliviscitur, ministri (ACU) obscura eunt et gratuita ad nihilum - commodam decident.
Haec solutio non convenit stabili oneri, quia scripturam oneris non attingit. Omnes hae nexus et disiunctio opum occurrunt in puncto, quod dicitur "scala" - punctum temporis, quo datorum tabularum transactionis vel temporariae non sustinetur. Exempli gratia, intra hebdomadem punctum librae fieri non potest, et opera turpia in eisdem facultatibus et simpliciter dilatare vel contrahere non possunt.
Nulla magicae est - regularis PostgreSQL est. Sed processus machinarum addendi et eas disiungendi partim automated est.
Serverless by design
Aurora Serverless vetus database rescriptum ob nubes uti aliquorum beneficiorum Serverless. Et nunc dicam tibi de basi, quae initio pro nube scripta erat, accessu inservili - Serverless-by-design. Statim sine suppositione elaboratum est ut ministris corporis incurreret.
Haec basis dicitur Snowflake. Tres clavos clausos habet.
Prima metadata scandalum est. Hoc est ieiunium in- memoria muneris quod quaestiones solvit cum securitate, metadata, transactionibus et interrogatione optimizatione (in illustratione sinistris ostensa).
Secundus clausus est botri computandi virtualis pro calculis (in illustratione est copia circulorum caeruleorum).
Tertius clausus est ratio repositionis notitiae innixa in S3. S3 dimensionless object storage in AWS, sort of like dimensionless Dropbox for business.
Videamus quomodo Snowflake laborat, si frigidum initium sumit. Id est, database, in eo notitia oneratur, nullae cursus queries sunt. Proinde, si petitiones datorum non sunt, tunc memoriam metadatae servitutis in- struximus ieiunium (primum scandalum). Et habemus S3 repositiones, ubi notitia mensae reponitur, in micropartitiones sic dictae divisae. Pro simplici: si in mensa continet transactiones, micropartitiones sunt dies negotiorum. Quotidie est micropartitio separata, fasciculus separatus. Et cum datorum hoc modo operatur, tantum pro spatio dato solves. Praeterea, rate per sedem valde humilis est (praesertim compressionis significantium habita ratione). Ministerium metadata constanter operatur, sed opibus non multum opus est ut quaestiones optimizes, et ministerium participes considerari possunt.
Nunc cogitemus aliquem usorem ad datorum nostrorum venisse et interrogationem SQL misisse. SQL quaesitum est statim ad Metadata servitium pro processus mittendum. Itaque, accepta petitione, hoc officium petitionem, notitias, permissiones usorum in promptu resolvit et, si bene omnia habet, consilium trahit ad petitionem expediendam.
Deinceps religio botri computandi launchem inchoat. Botrus computans est botrus ministrantium qui calculas exercent. Hoc est, botrus est qui continere potest 1 servo, 2 servientes, 4, 8, 16, 32 - quotquot vis. Petitionem mittes et immissionem huius botri statim incipit. Is vere seconds accipit.
Deinde postquam botrus incepit, micropartitiones necessariae ad processum postulationis tuae incipiunt in botrum ex S3 exscribi. Hoc est, cogitemus interrogationem SQL faciendam duas partitiones ab una mensa et unam e secunda requirere. In hoc casu tantum tres partitiones necessariae ad botrum transcribendae erunt, et non omnes tabulae ex toto. Hanc ob rem, et praecise quia omnia intra unum centrum data et canalibus velocissimis connexa sunt, totius processus translationis celerrime occurrit: in secundis, rarissime in minutis, nisi de monstrosis quibusdam petitionibus loquimur. Itaque micropartitiones ad botrum computandum transmittuntur, et, expleto, quaestio SQL in hoc botro computando agitur. Effectus huius rogationis potest esse una linea, plures lineae vel tabulae - extrinsecus ad utentem mittuntur ut eam extrahere possit, eam in BI instrumento ostendat vel alio modo utatur.
Singulae SQL query non solum aggregata ex data antea onerata legere possunt, sed etiam novas notitias in datorum onere/generate. Hoc est, quaesitum esse potest quod, exempli gratia, tabulas novas in aliam tabulam inserere, quae speciem novae partitionis in botro computando ducit, quae vicissim ipso facto in una S3 reposita servatur.
Sessio supra descripta, ab adventu utentis ad botrum resuscitationem, datas onerarias, inquisitiones exsecutiones, consecutiones eventus, solvitur pro minutis utendi virtuali botri computandi, virtualis horreis utendi. Rate variat secundum AWS zonam et molem botri, sed in mediocris est pauca per horae dollariorum. Botrus quattuor machinis est duplo carus quam botrus duarum machinarum, et botrus octo machinis adhuc bis carus est. Optiones XVI, 16 machinae praesto sunt, secundum multiplicitatem petitionum. Sed tantum illis minutis cum botrus vere currit, quia cum non sunt petitiones, tolle manus tuas, et post 32-5 minuta morans (parametrum configurabile) abibit per seipsum; liberare facultates ac liberi.
Missionis omnino realistica est cum petitionem mittis, botrum popslum relative loquendo minutum, alterum minutum computat, deinde quinque minuta ad clausuram, et tandem solvens per septem minutas operationis huius botri, et non mensibus et annis.
Primum missionem descripsit usus Snowflake in uno-usore occasu. Nunc fingamus multos esse utentes, qui missione reali propinquior est.
'Dicamus nos multum habere analystarum et Tableau refert quae constanter bombardas nostras databases cum magno numero simplicium analyticorum SQL queries.
Praeterea dicamus nos data inventiva Scientistae, qui portenta cum notitia facere conantur, cum decem Terabytis agunt, billions et trillions ordinum notitiarum analyses.
Ad duo genera quod inposuit supra descriptum, Snowflake permittit ut plures uvas variarum facultatum independentes computandi. Praeterea hae racemi computandi independenter operantur, sed cum data communi convenientia.
Magna vis lucis quaesitorum, racemos 2-3 parvos, circiter 2 machinas singulas erigere potes. Haec agendi ratio perfici potest, inter alia, adhibitis automaticis fundis. Sic ais, βSnowflake, botrum parvum excita. Si onus supra modulum quemdam auget, secundo simile, tertium. Cum coeperit onus quiescere, excessum extingue. Ita ut quamvis multi analytae veniant et relationes aspicere incipiant, omnes satis facultates habent.
Simul, si analystae dormiunt et rumores nemo inspicit, racemi funditus tenebrosi sunt et cessant dare pro illis.
Eodem tempore, pro gravibus quaestionibus (ex Data Scientists), unum botrum maximum pro 32 machinis erigere potes. Botrus hic etiam pro illis minutis et horis tantum solvetur, cum illic rogatio gigas currit.
Facultas supra scripta permittit ut non solum 2, sed etiam plura genera quae inposuit in racemis dividere (ETL, vigilantia, materiationem referre, ....).
Summatim Sit Snowflake. Turpis idea pulchram coniungit et exsequendam operabilem. In ManyChat, Snowflake utimur ad resolvendas omnes notitias quas habemus. Non habemus tres ligaturas, ut in exemplo, sed ab 5 ad 9, variarum magnitudinum. Machinam conventionalem 16-machinam, 2-machinam ac etiam super parvam 1-machinam pro aliquibus operibus habemus. Feliciter onus distribuunt et nos multum salvare permittunt.
Datorum feliciter legendi scribendique pondera scandet. Ingens differentia haec est et ingens perruptio eidem βAuroraβ comparata, quae tantum oneris lectionis portabat. Snowflake permittit te ut scripturam tuam inposuit cum his racemis computandis scandere. Hoc est, ut monui, pluribus racemis in ManyChat utimur, racemis parvis et super-parvis maxime adhibitis pro ETL, ad onerandas notitias. Et analystae iam in racemis mediis vivunt, quae omnino non afficiuntur ab ETL onere, ideo celerrime laborant.
Proinde, datorum OLAP operibus bene aptum est. Tamen, proh dolor, nondum applicabilis est pro laboribus OLTP. Uno modo, hoc datorum columnar, cum omnibus consequentibus. Secundo adventus ipsius, quando pro singulis petitionibus, si opus est, computationem glomeratam attollis et cum notitia inundabis, proh dolor, nondum satis est pro oneribus OLTP. Exspectans secunda negotia OLAP normalia est, sed pro operibus OLTP inconveniens est, 100 ms melius esset, vel 10 ms melius esset.
exitum
Datorum servitori possibilis est dividendo datorum in partes publicas et res publicas. Animadvertere licet in omnibus his exemplis, partem publicam esse relative loquendo, parvas partitiones in S3 recondere, et Stateless est optimizer, operans metadata, quaestiones securitatis tractantem, quae velut leves ponderis sine servitiis publicis elevari possunt.
Exsecutioni SQL queries etiam percipi possunt officia levia quae in modum servoless, sicut Snowflake racemos computantes, solum necessarias notitias, interrogationem facient et "exire".
Servo gradu productionis databases iam praesto sunt ad usum, qui laborant. Hae databases inservientes iam paratae sunt ad opera OLAP tractandum. Infeliciter, pro OLTP opera, cum nuances adhibentur..., quia limitationes sunt. Hinc, hoc minus. Sed haec e contrario facultas est. Forsitan aliquis legentium viam inveniet ut OLTP datorum omnino servo carens, sine Aurorae limitibus inveniatur.
Spero te interesting invenisti. Serverless futurum est :)
Source: www.habr.com