Nuper tibi narravi quomodo uti coquinariis usitatis. ex database PostgreSQL. Hodie de eo loquemur quomodo inscriptionem efficaciorem reddere potes in basi datorum sine ullis "mutationibus" in configuratione adhibitis β simpliciter recte ordinando fluxus datorum.
#1. Sectio
Articulus de quomodo et cur operae pretium sit ordinare iam exstabant, sed hic de usu quarundam rationum intra limites nostri loquemur. .
"Res praeteritorum dierum..."
Initio, sicut quodlibet MVP, proiectum nostrum sub onere satis levi coepit - monitorium tantum duodecim ex servitoribus criticissimis peractum est, omnes tabulae relative compactae erant... Sed tempus processit, numerus machinarum monitoriarum crevit, et postquam iterum conatus est aliquid facere cum uno ex... tabulae magnitudinis 1.5 TB, intelleximus, quamquam sic vivere pergere posse, id tamen valde incommodum esse.
Tempora illa fere legendaria erant, et versiones variae PostgreSQL 9.x pertinentes erant, ita omnis partitio "manu" fieri debebat β per... hereditas tabulae et incitamenta itineratio cum dynamica EXECUTE.
Solutio inde orta satis universalis apparuit ut ad omnes tabulas transferri posset:
- Tabula parentis "capitularis" vacua declarata est, quae omnia describebat. Indices et incitamenta necessaria.
- Ex parte clientis, ingressus in tabulam "radicem" factus est, et interne ope... impulsus itineris
BEFORE INSERTDocumentum "physice" in sectionem requisitam insertum est. Si sectio nondum exstabat, exceptionem deprehendimus et... - ... utendo creatum est secundum exemplar tabulae parentis pars cum restrictione diei requisitiut cum data recuperantur, lectio in eis solis peragatur.
PG10: Primum Conatum
Sed partitio per hereditatem historice minus apta fuit ad tractandum negotiationem scripturae activam vel magnum numerum partitionum descendentium. Exempli gratia, fortasse meminisse possis algorithmum ad partitionem requisitam deligendum habuisse... complexitas quadratica, quod cum plus quam centum sectionibus operatur, scis quomodo operatur...
In PG10, haec condicio magnopere optimizata est per implementationem auxilii. Itaque statim post migrationem repositorii eo uti conati sumus, sed...
Ut apparet post perlustrationem manualem, tabula native partita in hac versione:
- Descriptiones indicum non sustinet
- non sustinet incitamenta
- non potest esse cuiusquam "progenies"
- non support
INSERT ... ON CONFLICT - Sectionem automatice generare non potest
Gravi ictu in fronte rastro affecti, intelleximus nos non posse proficere nisi applicationem modificaremus, et investigationes ulteriores sex menses distulimus.
PG10: Secunda Occasio
Itaque, problemata singillatim orta solvere coepimus:
- Quia incitant et
ON CONFLICTIn quibusdam locis tamen necessaria esse invenimus, itaque stadium intermedium ad ea elaboranda fecimus. tabula procuratoria. - "Iter" abiectum est. in incitamentis - id est, ab
EXECUTE. - Seorsum extraxerunt. tabula exemplaris cum omnibus indicibusita ut ne in tabula procuratorum quidem praesentes sint.
Tandem, post haec omnia, tabula principalis native partita est. Novam partitionem creare adhuc in applicatione est officium.
Dictionaria "serramus"
Sicut cum quolibet systemate analytico, etiam habuimus "facta" et "sectiones" (dictionaria). In nostro casu, exempli gratia, similes interrogationes tardae vel textus interrogationis ipsa.
"Res" nostrae diu per dies divisae erant, ita ut partes obsoletas facile delere possemus sine illis impedimento (nam, diaria erant!). Sed lexica aliquantum problematica erant...
Non dicerem multos fuisse, sed circiter Centum TB "factorum" in dictionario duorum et dimidii TB effecerunt.Nihil ex tali tabula commode delere potes, eam intra tempus rationabile comprimere non potes, et scribere in eam paulatim tardius factum est.
Simile dictionario videtur... unaquaeque inscriptio in eo semel tantum praesentanda est... et recte est, sed!... Nemo nos prohibet quominus habeamus... dictionarium separatum pro singulis diebusIta, hoc redundantiam quandam affert, sed permittit:
- celerius scribe/lege propter minorem magnitudinem sectionis
- memoriae minus consumere operando cum indicibus compactioribus
- minus notitiarum serva propter facultatem celeriter removendi obsoleta
Propter totam seriem mensurarum Onus CPU ~30% imminutum est, onus disci ~50%:
Simul, eadem prorsus rem in basim datorum scribere perreximus, sed minore onere.
#2. Evolutio et refactorizatio basis datorum
Itaque, in iis quae habemus constituimus est sectio pro quolibet die cum datis. Re vera, CHECK (dt = '2018-10-12'::date) β et clavis partitionis et condicio est ut documentum in sectionem specificam cadat.
Cum omnes relationes in nostro servitio ad diem certum construantur, indices earum ab "temporibus non partitis" iidem fuerunt. (Servus, diem, Formula consilii), (Servus, diem, Nodus Consilii), (diem, Classis Erroris, Servus)...
Sed nunc homines in omni regione habitant tua exemplaria quisque talis index... Et intra quamque sectionem dies est constans... Evenit ut nunc in unoquoque tali indice simus simpliciter constantem inserimus ut unum ex campis, quod et magnitudinem et tempus investigationis auget, sed nullos eventus producit. Nobis ipsis in foveam reliquerimus, eheu...
Directio optimizationis manifesta est - modo Campum diei ex omnibus indicibus remove in tabulis partitis. Cum nostris voluminibus, lucrum est circiter 1 TB/hebdomada!
Nunc notemus hoc terabyte tamen aliquo modo scribendum esse. Id est, nos etiam... Discus nunc minus onerari debetHaec imago clare ostendit eventus purgationis quam per hebdomadem perfecimus:
#3. Summum onus distribuere
Unum ex magnis difficultatibus systematum occupatorum est synchronizatio redundans Quaedam chirurgiae id non requirunt. Interdum "quia non animadvertimus," interdum "facilius tantum," sed citius aut serius eo carere debemus.
Imaginem priorem propius inspiciamus et videamus nos discum habere. "antliae" sub onere cum duplici amplitudine inter lectiones adiacentes, quod manifeste "statistice" cum tot operationibus fieri non debet:
Hoc satis facile est assequi. Systema monitorium iam institutum habebamus. fere mille servi, unumquodque a filo logico separato tractatur, et unumquodque filum informationem accumulatam ad databasim mittendam effundit certa frequentia, fere hoc modo:
setInterval(sendToDB, interval)Problema hic in eo ipso consistit quod omnes rivi fere eodem tempore incipiunt, ergo tempora missionis eorum fere semper "ad rem" congruunt. Vae #2...
Fortuna favente, hoc satis facile reficitur, addendo dispersionem "fortuitatam" tempore:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#4. Quod nobis opus est, recondimus in cella recondendo.
Tertium problema traditionale oneris magni est nulla memoria celata ubi est posset esse.
Exempli gratia, nodos consilii (omnes hi) analyzare licuit. Seq Scan on users), sed statim cogitaverunt eos, in genere, eosdem esse - obliti sunt.
Non, scilicet, nihil iterum in basim datorum scribitur, hoc a trigger intercluditur. INSERT ... ON CONFLICT DO NOTHINGSed haec data adhuc ad basim datorum perveniunt, et etiam superflua insuper. legendo ad conflictum investigandum Facere debeo. Vae #3...
Discrimen in numero inscriptionum ad basim datorum missarum ante/post activationem celandi manifesta est:
Et haec est concomitans diminutio oneris in repositione:
in summa
"Terabytes per diem" tantummodo formidulosum sonat. Si omnia recte facis, tantum... 2^40 octeti / 86400 secunda = ~12.5MB/s, quod etiam cochleae IDE computatralis tenere possent. π
Sed serio, etiam cum decuplo onere "inclinato" interdiu, facile intra facultates SSD modernorum aptari potes.
Source: www.habr.com
