Salve, Habr.
Meum nomen est Misha Butrimov, tibi pauca de Cassandra narrare velim. Fabula mea utilis erit iis qui NoSQL databases nunquam offenderunt - multum habet ad exsequendam lineamenta et foveas quae scire debes. Et si quid aliud quam Oraculum aut aliud database relationis vidisti, haec vitam tuam servabunt.
Quid tam bene de Cassandra? NoSQL database designatum est sine aliquo puncto defectus qui bene librat. Si duos terabytes aliquot datorum addere debes, nodos anuli simpliciter addis. Mauris interdum expand ad alium? Nodos adde botri. RPS crescat processionaliter? Nodos adde botri. In oppositum quoque operatur.
Quid est aliud bonum? De petitionibus tractandis multum est. Sed quantum est multum? X, 10, XXX, XL milia petitionum per alterum non amplius. petitiones 20 milia secundo pro memoria — quoque. Societates sunt quae dixit se 30 decies centena millia petitionum secundarum servare. Probabile erit credere.
Et in principio, Cassandra unam magnam differentiam habet a notitia relationis, non est similis omnino. Et hoc ipsum meminisse.
Non omnia quae eadem operantur
Cum collega ad me venit et quaesivit: "Ecce lingua interrogationis Cassandrae CQL est et electionem habet selectam, ubi habet, habet et habet. Litteras scribo et non operatur. Quare?". Cassandra tractans sicut database relationis est perfectus modus ad mortem violentam committendam. Et ego non promoveo, prohibetur in Russia. Aliquid cogitabis tantum mali.
Exempli gratia, emptor ad nos venit et dicit: "Faciamus database pro serie TV, vel datorum pro recipe presul. Vasa escaria ibi habebimus, vel index seriei TV et histriones in eo". Laeti dicimus: Eamus! Modo duos bytes mittas, duo signa et facta es, omnia celerrime ac fideliter operabuntur. Omnia denique donec clientes veniunt et dicunt mulierculae etiam problema contrarium solvendo: index productorum habent, et scire volunt quid disco coquere volunt. Et mortuus es.
Causa est, quia Cassandra datorum hybridarum est: simul praebet valorem clavis ac notitia in latis columnis recondit. In Java vel Kotlin, sic describi potest;
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Id est, chartam geographicam quae etiam tabulam digestam continet. Prima clavis huic tabulae est clavis Row seu clavis partitionis - clavis partitionis. Secunda clavis, quae clavis est tabulae iam digestae, clavis ligatura est.
Ad distributionem datorum illustrandam, tres nodos stringamus. Nunc intelligere debes notitias in nodos dissoluere. Quia si omnia in unum redigimus (modo potest esse mille, duo milia, quinque, quot voles), hoc vere non est de distributione. Ergo opus est munere mathematico, quod numerum reducet. Sicut numerus, longus int quod in aliquo range incidet. Et habebimus unam nodi responsalem pro uno manso, secundo pro secundo, et una pro quarta.
Hic numerus detrahetur usus functionis detrahendae, quae applicatur iis quae clavis Partitionis vocamus. Haec est columna quae designatur in directivis clavibus primariis, et haec est columna quae erit prima et principalissima clavis tabulae. Qua data nodo accipiet quem determinat. Mensa Cassandra creatur eadem fere syntaxi ac in SQL:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Clavis primaria in hoc casu ex una columna constat, estque etiam clavis partitionis.
Quomodo usores nostri praestant? Ibunt alia ad unam nodi, alia ad aliam, et alia ad tertiam. Proventus est mensa detrahe ordinaria, quae chartam geographicam notat, Python quoque dictionarii notam, vel simplicem valorem Key structuram e qua omnia bona legere et scribere per clavem possumus.
Lego: cum eliquare permittite in plenam scan converti, vel quid non facere
Scriptum est quaedam propositio selecta: select * from users where, userid = . Simile evenit in Oraculo: selectas scribimus, conditiones et omnia opera specificamus, utentes possidemus. Quod si deligas, exempli gratia, utentem certo anno nativitatis, Cassandra queritur petitionem suam implere non posse. Quia nihil omnino scit quomodo notitias distribuimus circa annum nativitatis - una tantum columna clavis indicata est. Deinde dicit: “Bene, petitionem hanc adimplere possum. Adde sinas eliquare.' Addimus directivum omnia opera. Et in hoc momento aliquid terribile accidit.
Cum in test notitia curritur, omnia denique sunt. Et cum quaesitum fueris in productione, ubi habebimus, exempli gratia, 4 decies centena milia, omnia nobis non valde bona sunt. Quia eliquare permittit directivum est quod Cassandra permittit omnes notitias ex hac tabula colligere ex omnibus nodis, centra omnia (si plures sunt in hoc botro), et tunc demum illam spargunt. Analogia haec est plenae Scaniae, et vix aliquis eo delectatur.
Si usoribus tantum ID per id opus esset, cum hoc bene essemus. Sed interdum opus est ut alias quaestiones conscribas et alias restrictiones in delectu imponas. Ideo meminimus: haec est tota tabula quae clavem partitionem habet, sed intra tabulam digestam est.
Habet etiam ipsa clavem, quam Clavis Clustering appellamus. Hic clavus, qui vicissim constat ex columnis quam eligimus, quorum ope Cassandra intelligit quomodo ejus notitia physice digesta sit et in unaquaque nodo collocabitur. Hoc est, pro aliqua divisione clavem, clavis ligaturas exacte tibi indicabit quomodo notitias in hanc arborem impellere, quo loco ibi capiet.
Haec est vere arbor, ibi comparator simpliciter dicitur, ad quam transimus certam columnarum speciem in specie objecti, et etiam speciem columnarum.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Attende ad directivam principalem clavem: prima eius ratio (in nostro casu annus) semper est clavis Partitionis. Ex una vel pluribus columnis constare potest, non refert. Si plures columnae sunt, uncis denuo removendum est ut praeprocessoris lingua intelligat hanc esse clavem Primariam, et post eam omnes aliae columnae clavis ligaturae sunt. in hoc casu tradentur in comparatione eo ordine quo apparent. id est, prima columna est magis significativa, secunda est minus significativa, et sic de aliis. Quomodo scribimus, exempli gratia, pares agros pro data classibus: agros ponimus, et pro his scribimus qui maiores sint, et qui minores. In Cassandra haec sunt, relative loquendo, agri notitie, ad quos pares scripti applicabuntur.
Constituimus genus et imponere restrictiones
Meminisse debes qualemcumque ordinem (descendendo, ascendendo, quidquid) eodem momento constituatur quo clavis creatur, nec postea mutari potest. Determinat physice quomodo data erit sorted et quomodo condietur. Si ligaturam clavem vel ordinem qualemcumque mutare debes, novam mensam condere et in eam notitias transferre debebis. Hoc non erit cum ente existenti.
Mensam nostram cum usoribus implevimus et vidimus incidere in anulum primo anno nativitatis, deinde intra in singulis nodi salario et usuario ID. Nunc eligere possumus restrictiones imponendo.
Nostrum opus apparet iterum where, andet utentes consequimur, et omnia denique rursus. Si autem conamur tantum parte claviculi uti et minus notabili, statim conqueretur Cassandra non posse reperire locum in tabula nostra, ubi hoc obiectum, quod habet hos agros nullo comparato, et hoc unum. quae mox posita , — ubi iacet. Omnia indicia ex hoc nodo iterum evellere et illud percolare debebo. Et haec est similitudo plenae nodi intra Scan, hoc malum est.
In omni situ incerto, novam mensam creare
Si velimus utentes per ID, vel aetate, vel stipendio poterimus oppugnare, quid faciemus? Nihil. Utere duabus tabulis. Si tribus modis utentes attingere debes, tres tabulae erunt. Periere dies, quibus spatium cochleae servavimus. Hoc est resource vilissimum. Multo minus temporis constat quam responsio, quod usuenti obesse potest. Multo iucundius est utentem recipere aliquid in secunda quam in 10 minuta.
Superfluum spatium mercamur et notitias detormatae pro facultate bene scandendi ac fideliter operandi. Etenim botrus qui constat ex tribus centris notitiis, quorum unumquodque habet quinque nodos, cum gradu acceptabili notitiae conservationis (cum nihil deperditur), mortem unius centri omnino superesse potest. Nodi duo in singulis reliquiis. Et nonnisi post haec incipiunt problemata. Haec satis bona redundantia est, valet duos extra SSD agitet processus. Ut igitur utatur Cassandra, quae nunquam SQL, in qua nullae sunt relationes, claves exterae, debes scire regulas simplices.
Designamus omnia secundum tuam petitionem. Summa data non est, sed opus est uti applicatio. Si autem necesse est ut diversimode recipiat notitias diversas, vel diversimode eadem notitia, oportet quod applicatio conveniat ponere. Alioquin in plena Scan et Cassandra nihil nobis commodi dabimus.
Denormalizing data norma est. Obliviscimus formas normales, databases relationes non iam habemus. Si 100 vicibus posuerimus aliquid, 100 vicibus dormiet. Est adhuc vilius quam mora.
Claves partiendi eligemus ut regulariter distribuantur. Nolumus Nullam claves nostrarum in angusto ambitu cadere. Id est malum exemplum supra anno nativitatis. Accuratius, bonum est si usores nostri ordinarie per annum nativitatis distribuuntur, et mali si loquimur de 5 gradu studiosorum - partitio non erit valde bona.
Genus electum est semel in scaena Clustering Key creationis. Si mutari debet, tabulam nostram cum alia clavi renovare debebimus.
Et potissima res: si necesse habemus eandem notam in 100 diversis modis recuperare, tunc 100 diversarum tabularum habebimus.
Source: www.habr.com