{"id":56365,"date":"2020-02-11T00:00:00","date_gmt":"2020-02-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike"},"modified":"2020-02-18T14:04:37","modified_gmt":"2020-02-18T11:04:37","slug":"highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>J\u00e4rgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis. <br \/>\n\u00dcksikasjad ja piletid <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">linki pidi<\/a><\/noindex>. HighLoad++ Siberia 2019. Saal \"Krasnojarsk\". 25. juuni, 12:00. Teesid ja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5253\">esitlus<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/cded9c5434d670db7295aadf5da0a9f1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJuhtub, et praktilised n\u00f5uded on vastuolus teooriaga, kus ei ole arvesse v\u00f5etud kaubandusliku toote jaoks olulisi aspekte. Selles ettekandes tutvustatakse erinevate l\u00e4henemisviiside valimise ja kombineerimise protsessi p\u00f5hjusliku j\u00e4rjekindluse (Causal consistency) komponentide loomisel, tuginedes akadeemilistele uuringutele, l\u00e4htudes kaubandusliku toote n\u00f5uetest. Kuulajad saavad teada, milliseid teoreetilisi l\u00e4henemisviise on olemas loogiliste kellade, s\u00f5ltuvuste j\u00e4lgimise, s\u00fcsteemi turvalisuse ja kellas\u00fcnkroniseerimise osas ning miks MongoDB valis just teatud lahendused.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><b>Mikhail Tyulenev (edaspidi \u2013 MT):<\/b> \u2013 R\u00e4\u00e4gin p\u00f5hjuslikust j\u00e4rjekindlusest \u2013 see on funktsioon, mille kallal me t\u00f6\u00f6tasime MongoDBs. T\u00f6\u00f6tan hajutatud s\u00fcsteemide grupis, me j\u00f5udsime selleni umbes kaks aastat tagasi.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/b8d0a5b64e715f53b033fa8c398e2eb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProtsessi k\u00e4igus tuli tutvuda suure hulga akadeemilise uurimist\u00f6\u00f6ga, sest see funktsioon on \u00fcsna h\u00e4sti uuritud. Selgus, et \u00fckski artikkel ei vasta produktiivsuse n\u00f5uetele andmebaasi osas, millel on \u00fcsna spetsiifilised n\u00f5uded, mis esinevad t\u00f5en\u00e4oliselt igas tootmisrakenduses.<\/p>\n<p>R\u00e4\u00e4gin sellest, kuidas me, olles akadeemilise uurimist\u00f6\u00f6 tarbijad, valmistame sellest midagi, mida saame seej\u00e4rel meie kasutajatele serveerida valmisroana, mida on mugav ja ohutu kasutada.<\/p>\n<h3>P\u00f5hjuslik j\u00e4rjekindlus (Causal consistency). M\u00e4\u00e4ratleme m\u00f5isted<\/h3>\n<p>\nEsmalt tahan \u00fcldiselt r\u00e4\u00e4kida, mis on p\u00f5hjuslik j\u00e4rjekindlus. On kaks tegelast \u2013 Leonard ja Penny (sarjast \"Teooria suurest plahvatusest\"):<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/ee0835b604ae5d5d6c0fa1bc369e6b18.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOletame, et Penny on Euroopas, ja Leonard tahab talle \u00fcllatuse korraldada. Ja ta ei tule paremat v\u00e4lja kui eemaldada ta s\u00f5bralistist, saata k\u00f5igile s\u00f5pradele uuendus feed'is: \"K\u00fcsimus, miks me ei \u00fcllata Penny'd!\" (ta on Euroopas, magab hetkel, ei n\u00e4e seda ja ei saa n\u00e4ha, kuna ta ei ole seal). L\u00f5puks kustutab ta selle postituse, kustutab \"Feedi\" ja taastab juurdep\u00e4\u00e4su, et ta ei m\u00e4rkaks midagi ja skandaali ei oleks.<br \/>\nSee, \u044d\u0442\u043e \u0432\u0441\u0451 \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e, \u043d\u043e \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043c, \u0447\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u0430\u044f \u0438 \u0441\u043e\u0431\u044b\u0442\u0438\u044f \u043f\u043e\u0448\u043b\u0438 \u0447\u0443\u0442\u044c \u043d\u0435 \u0442\u0430\u043a. \u041c\u043e\u0436\u0435\u0442 \u0441\u043b\u0443\u0447\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0435 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u0434\u043b\u044f \u041f\u0435\u043d\u043d\u0438 \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u043f\u043e\u0441\u043b\u0435 \u0442\u043e\u0433\u043e, \u043a\u0430\u043a \u044d\u0442\u043e\u0442 \u043f\u043e\u0441\u0442 \u0443\u0436\u0435 \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f, \u0435\u0441\u043b\u0438 \u0441\u043e\u0431\u044b\u0442\u0438\u044f \u043d\u0435 \u0441\u0432\u044f\u0437\u0430\u043d\u044b \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439 \u043f\u0440\u0438\u0447\u0438\u043d\u043d\u043e-\u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c\u0438 \u0441\u0432\u044f\u0437\u044f\u043c\u0438. \u042d\u0442\u043e \u043f\u0440\u0438\u043c\u0435\u0440 \u0441\u043b\u0443\u0447\u0430\u044f, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u0430 \u043f\u0440\u0438\u0447\u0438\u043d\u043d\u0430\u044f \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u044c \u0434\u043b\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0431\u0438\u0437\u043d\u0435\u0441-\u0444\u0443\u043d\u043a\u0446\u0438\u0438 (\u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435).<\/p>\n<p>\u041d\u0430 \u0441\u0430\u043c\u043e\u043c \u0434\u0435\u043b\u0435 \u044d\u0442\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2013 \u043e\u0447\u0435\u043d\u044c \u043d\u0435\u043c\u043d\u043e\u0433\u043e\u0435 \u0438\u0445 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442. \u0414\u0430\u0432\u0430\u0439\u0442\u0435 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u043c\u043e\u0434\u0435\u043b\u044f\u043c.<\/p>\n<h3>\u041c\u043e\u0434\u0435\u043b\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 (Consistency Models)<\/h3>\n<p>\n\u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043c\u043e\u0434\u0435\u043b\u044c \u043a\u043e\u043d\u0441\u0438\u0441\u0442\u0435\u043d\u0442\u043d\u043e\u0441\u0442\u0438 \u0432 \u0431\u0430\u0437\u0430\u0445 \u0434\u0430\u043d\u043d\u044b\u0445? \u042d\u0442\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0435 \u0433\u0430\u0440\u0430\u043d\u0442\u0438\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0441\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0442\u043e\u0433\u043e, \u043a\u0430\u043a\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0438 \u0432 \u043a\u0430\u043a\u043e\u043c \u043f\u043e\u0440\u044f\u0434\u043a\u0435 \u043a\u043b\u0438\u0435\u043d\u0442 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c.<\/p>\n<p>\u0421\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043c\u043e\u0434\u0435\u043b\u0435\u0439 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0432\u043e\u0434\u044f\u0442\u0441\u044f \u043a \u0442\u043e\u043c\u0443, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043f\u043e\u0445\u043e\u0436\u0430 \u043d\u0430 \u0442\u0430\u043a\u0443\u044e, \u0447\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0443\u0437\u043b\u0435 \u043d\u0430 \u043d\u043e\u0443\u0442\u0431\u0443\u043a\u0435. \u0418 \u0442\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0430\u044f \u043d\u0430 \u0442\u044b\u0441\u044f\u0447\u0430\u0445 \u0433\u0435\u043e\u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0443\u0437\u043b\u043e\u0432, \u043f\u043e\u0445\u043e\u0436\u0430 \u043d\u0430 \u043d\u043e\u0443\u0442\u0431\u0443\u043a, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u0432\u0441\u0435 \u044d\u0442\u0438 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u044e\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438.<\/p>\n<p>\u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u043e\u0434\u0435\u043b\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u043a \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c. \u0412\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0440\u0430\u043d\u044c\u0448\u0435 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043e\u0432\u0430\u043b\u0438 \u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043d\u0430 \u043e\u0434\u043d\u043e\u043c \u0432\u0435\u0440\u0442\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438, \u0442\u0430\u043a\u0438\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043d\u0435 \u0438\u0441\u043f\u044b\u0442\u044b\u0432\u0430\u043b\u0438. \u0422\u0430\u043c \u0431\u044b\u043b \u043e\u0434\u0438\u043d \u0431\u0443\u0444\u0435\u0440\u043d\u044b\u0439 \u043a\u044d\u0448, \u0438 \u0438\u0437 \u043d\u0435\u0433\u043e \u0432\u0441\u0451 \u0432\u0441\u0435\u0433\u0434\u0430 \u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f.<\/p>\n<h3>\u041c\u043e\u0434\u0435\u043b\u044c Strong<\/h3>\n<p>\n\u0421\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043f\u0435\u0440\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u2013 \u044d\u0442\u043e Strong (\u0438\u043b\u0438 line of visibility, \u043a\u0430\u043a \u0435\u0451 \u0447\u0430\u0441\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442). \u042d\u0442\u043e \u043c\u043e\u0434\u0435\u043b\u044c \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0433\u0430\u0440\u0430\u043d\u0442\u0438\u0440\u0443\u0435\u0442, \u0447\u0442\u043e \u043a\u0430\u0436\u0434\u043e\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0435, \u043a\u0430\u043a \u0442\u043e\u043b\u044c\u043a\u043e \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u043e, \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u0432\u0438\u0434\u043d\u043e \u0432\u0441\u0435\u043c \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u044b.<\/p>\n<p>\u042d\u0442\u043e \u0441\u043e\u0437\u0434\u0430\u0435\u0442 \u0433\u043b\u043e\u0431\u0430\u043b\u044c\u043d\u044b\u0439 \u043f\u043e\u0440\u044f\u0434\u043e\u043a \u0432\u0441\u0435\u0445 \u0441\u043e\u0431\u044b\u0442\u0438\u0439 \u0432 \u0411\u0414. \u042d\u0442\u043e \u043e\u0447\u0435\u043d\u044c \u0441\u0438\u043b\u044c\u043d\u043e\u0435 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u043e \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438, \u0438 \u043e\u043d\u043e \u0432\u0435\u0441\u044c\u043c\u0430 \u0434\u043e\u0440\u043e\u0433\u043e\u0435. \u0422\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u043e\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u041f\u0440\u043e\u0441\u0442\u043e \u044d\u0442\u043e \u043e\u0447\u0435\u043d\u044c \u0434\u043e\u0440\u043e\u0433\u043e\u0435 \u0438 \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u043e\u0435 \u2013 \u0438\u043c \u0440\u0435\u0434\u043a\u043e \u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f. \u042d\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f line of visibility.<\/p>\n<p>\u0421\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0435\u0449\u0451 \u043e\u0434\u043d\u043e, \u0431\u043e\u043b\u0435\u0435 \u0441\u0438\u043b\u044c\u043d\u043e\u0435 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u043e, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0432 \u00abSpanner\u00bb \u2013 \u044d\u0442\u043e External Consistency. \u041c\u044b \u043e\u0431\u0441\u0443\u0434\u0438\u043c \u0435\u0433\u043e \u0447\u0443\u0442\u044c \u043f\u043e\u0437\u0436\u0435.<\/p>\n<h3>Causal<\/h3>\n<p>\nJ\u00e4rgmine on Causal, just see, millest ma r\u00e4\u00e4kisin. Strongi ja Casual'i vahel on veel m\u00f5ned alamastmed, millest ma ei hakka r\u00e4\u00e4kima, kuid need k\u00f5ik seonduvad Causal'iga. See on oluline mudel, kuna see on k\u00f5ige tugevam k\u00f5igist mudelitest, k\u00f5ige tugevam j\u00e4rjepidevus v\u00f5rgu v\u00f5i osade kaudu.<\/p>\n<p>Causals on tegelikult olukord, kus s\u00fcndmused on omavahel seotud p\u00f5hjuslikku seost. V\u00e4ga tihti tajutakse neid kui Klientide \u00f5iguste lugemise visioonina. Kui klient on n\u00e4inud mingisuguseid v\u00e4\u00e4rtusi, ei saa ta n\u00e4ha v\u00e4\u00e4rtusi, mis olid minevikus. Ta hakkab juba n\u00e4gema prefiks lugemisi. See k\u00f5ik seondub \u00fchte ja sama.<br \/>\nCausals kui j\u00e4rjepidevuse mudel \u2013 osaline s\u00fcndmuste j\u00e4rjestamine serveris, kus k\u00f5igi klientide s\u00fcndmusi j\u00e4lgitakse sama j\u00e4rjestusega. Antud juhul \u2013 Leonard ja Penny.<\/p>\n<h3>Eventual<\/h3>\n<p>\nKolmas mudel on Eventual Consistency. See, mis toetab absoluutselt k\u00f5iki jaotatud s\u00fcsteeme, minimaalne mudel, mis \u00fcldse m\u00f5tet omab. See t\u00e4hendab j\u00e4rgmist: kui toimuvad m\u00f5ned muudatused andmetes, siis mingil hetkel muutuvad need j\u00e4rjepidevaks.<\/p>\n<p>Sellisel hetkel ei r\u00e4\u00e4gi ta midagi, vastasel juhul muutuks see External Consistency'ks \u2013 see oleks t\u00e4iesti teine lugu. Siiski on see v\u00e4ga populaarne mudel, k\u00f5ige levinum. Vaikimisi kasutavad k\u00f5ik jaotatud s\u00fcsteemide kasutajad just Eventual Consistency't.<\/p>\n<p>Soovin tuua m\u00f5ned v\u00f5rdlevad n\u00e4ited:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/c23e59b30d96de6ec456aaa76c67ad61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMida need nooled t\u00e4hendavad?<\/p>\n<ul>\n<li><b>Latency.<\/b> J\u00e4rjepidevuse tugevuse suurenedes muutub see enamike arusaadavate p\u00f5hjuste t\u00f5ttu suuremaks: tuleb teha rohkem kirjeid, saada kinnitus k\u00f5igilt hostidelt ja nodidelt, mis osalevad klastris, et andmed seal juba on. Seet\u00f5ttu on Eventual Consistency puhul k\u00f5ige kiirem vastus, kuna seal v\u00f5ib isegi m\u00e4lus teha ja see oleks p\u00f5him\u00f5tteliselt piisav.<\/li>\n<li><b>Availability.<\/b> Kui seda m\u00f5ista kui s\u00fcsteemi v\u00f5imet vastata, kui on v\u00f5rgu katkestusi, partitions v\u00f5i mingeid t\u00f5rkeid \u2013 t\u00f5rkekindlus suureneb j\u00e4rjepidevuse mudeli v\u00e4hendamisega, kuna piisab sellest, et \u00fcks host elaks ja samal ajal mingisuguseid andmeid annaks. Eventual Consistency ei garanteeri \u00fcldse andmete kohta midagi \u2013 see v\u00f5ib olla mis tahes.<\/li>\n<li><b>Anomalies.<\/b> Sellega muidugi suureneb anomaaliate hulk. Tugevas koosk\u00f5las ei tohiks neid peaaegu olemagi, samas kui l\u00f5ppkokkuv\u00f5tte koosk\u00f5las v\u00f5ivad need olla igasugused. Tekkib k\u00fcsimus: miks inimesed valivad l\u00f5ppkokkuv\u00f5tte koosk\u00f5la, kui see sisaldab anomaaliaid? Vastus peitub selles, et l\u00f5ppkokkuv\u00f5tte mudelid on kasutatavad ja anomaaliad eksisteerivad n\u00e4iteks l\u00fchikese ajavahemiku jooksul; on v\u00f5imalus kasutada meistrit lugemiseks ja enam-v\u00e4hem lugeda j\u00e4rjepidevaid andmeid; sageli on v\u00f5imalus kasutada tugevaid koosk\u00f5la mudeleid. Praktikas see t\u00f6\u00f6tab ja anomaaliate hulk on sageli ajaliselt piiratud.<\/li>\n<\/ul>\n<p><\/p>\n<h3>CAP teoreem<\/h3>\n<p>\nKui n\u00e4ete s\u00f5nu koosk\u00f5la, saadavus \u2013 mis tuleb teile meelde? \u00d5ige \u2013 CAP teoreem! Praegu tahan ma m\u00fc\u00fcti hajutada... See ei ole mina \u2013 see on Martin Kleppmann, kes kirjutas suurep\u00e4rase artikli, suurep\u00e4rase raamatu.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/02a9b84585218c4e85afd65f7e88aa26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCAP teoreem on 2000ndatel formuleeritud p\u00f5him\u00f5te selle kohta, et Koosk\u00f5la, Saadavus, Jagunemised: vali \u00fcksk\u00f5ik kaks, kuid ei saa valida kolme. See oli teatud p\u00f5him\u00f5te. Seda t\u00f5estati teoreemina m\u00f5ni aasta hiljem, selle tegid Gilbert ja Lynch. See sai kasutusele v\u00f5etud nagu mantra \u2013 s\u00fcsteemid hakkasid jagunema CA, CP, AP jne.<\/p>\n<p>See teoreem oli tegelikult t\u00f5estatud j\u00e4rgmiste juhtumite jaoks... Esiteks, Saadavust vaadeldi mitte kui pidevat v\u00e4\u00e4rtust nullist sajani (0 \u2013 s\u00fcsteem on \u2018surnud\u2019, 100 \u2013 vastab kiiresti; oleme harjunud seda nii vaatama), vaid kui algoritmi omadust, mis tagab, et k\u00f5igi oma t\u00e4itmiste korral tagastab ta andmed.<\/p>\n<p>Vastuse aja kohta ei ole seal \u00fchtegi s\u00f5na! On algoritm, mis tagastab andmed 100 aasta jooksul \u2013 t\u00e4iesti suurep\u00e4rane saadav algoritm, mis on osa CAP teoreemist.<br \/>\nTeiseks: teoreemi t\u00f5estati sama v\u00f5tme v\u00e4\u00e4rtuste muutuste jaoks, olles need muutused samas suuruses. See t\u00e4hendab, et neid ei kasutata sisuliselt, kuna teised mudelid on L\u00f5ppkokkuv\u00f5tte koosk\u00f5la, Tugev koosk\u00f5la (v\u00f5ib-olla).<\/p>\n<p>Milleks see k\u00f5ik? Selleks, et CAP teoreem just sellises vormis, nagu see on t\u00f5estatud, on praktiliselt rakendatav, harva kasutatav. Teoreetilises vormis piirab see kuidagi k\u00f5ike. Tulemuseks on teatud p\u00f5him\u00f5te, mis on intuitiivselt t\u00f5ene, kuid ei ole \u00fcldiselt t\u00f5estatud.<\/p>\n<h3>Kausaalne koosk\u00f5la \u2013 k\u00f5ige tugevam mudel<\/h3>\n<p>\nPraegu toimuval on v\u00f5imalik saavutada kolme asja: j\u00e4rjepidevus, k\u00e4ttesaadavus, kasutades partiisid. Eriti causaalne j\u00e4rjepidevus on k\u00f5ige tugevam j\u00e4rjepidevuse mudel, mis t\u00f6\u00f6tab isegi partiide (v\u00f5rkude katkestuste) korral. Seet\u00f5ttu on see nii huvitav ja seet\u00f5ttu oleme sellega tegelenud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/c4320294320261858a6d22faa97b9e23.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsiteks lihtsustab see rakenduste arendajate t\u00f6\u00f6d. Eriti serveri suur toe olemasolu: kui k\u00f5ik kirjed, mis toimuvad \u00fche kliendi sees, j\u00f5uavad garanteeritult teisele kliendile kindlas j\u00e4rjekorras. Teiseks talub see katkestusi.<\/p>\n<h3>MongoDB sisek\u00f6\u00f6k<\/h3>\n<p>\nM\u00e4letades, et on l\u00f5una, liikumme k\u00f6\u00f6ki. R\u00e4\u00e4gin s\u00fcsteemi mudelist, nimelt \u2013 mis on MongoDB nende jaoks, kes kuulevad sellisest andmebaasist esmakordselt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/a1784442ff1c44403b5347f4f43a1197.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/a1f9bcb4daebb43e4fc848a5f5f07c60.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMongoDB (edaspidi \u2013 \u201eMongoDB\u201d) on jaotatud s\u00fcsteem, mis toetab horisontaalset skaleerimist, see t\u00e4hendab sharding\u2019ut; ja iga shard\u2019i sees toetab see ka andmete \u00fcleliigsust, see t\u00e4hendab replikatsiooni.<\/p>\n<p>Sharding \u201eMongoDB-s\u201d (mitte-relatsiooniline andmebaas) teostab automaatset tasakaalustamist, see t\u00e4hendab, et iga dokumentide kogu (v\u00f5i \u201etabel\u201d relatsiooniliste andmete terminoloogias) jaotatakse osadeks, ja server liigutab neid automaatselt shardi vahel.<\/p>\n<p>K\u00fcsimuste router, mis jaotab p\u00e4ringud, on kliendi jaoks teatud klient, mille kaudu ta t\u00f6\u00f6tab. Ta juba teab, kus ja milliseid andmeid leidub, suunab k\u00f5ik p\u00e4ringud \u00f5igele shardile.<\/p>\n<p>Veel \u00fcks oluline punkt: MongoDB on \u00fche peaga. On \u00fcks primaarne \u2013 ta saab vastu v\u00f5tta kirjeid, mis toetavad neid v\u00f5tmeid, mida ta endas sisaldab. Multi-master kirjutamist teha ei saa.<\/p>\n<p>Oleme v\u00e4lja andnud versiooni 4.2 \u2013 seal on uusi huvitavaid asju. Eriti, oleme sisse viinud Lucene'i - otsingu - nimelt k\u00e4ideldava java otse \u201eMongo\u201d sees, ja seal on n\u00fc\u00fcd v\u00f5imalik otsida l\u00e4bi Lucene, sama nagu \u201eElasticsearchis\u201d.<\/p>\n<p>Ja oleme teinud uue toote \u2013 Charts, see on samuti saadaval \u201eAtlasel\u201d (oma Mongo pilve). Neil on Free Tier \u2013 saab sellega katsetada. Charts meeldis mulle v\u00e4ga \u2013 andmete visualiseerimine, v\u00e4ga intuitiivne.<\/p>\n<h3>Causaalse j\u00e4rjepidevuse koostisosad<\/h3>\n<p>\nOlen lugenud umbes 230 artiklit, mis on sellel teemal avaldatud \u2013 Leslie Lampertilt. Praegu toimetan teieni m\u00f5ningad osad nendest materjalidest oma m\u00e4lust.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/e88b34b7a724e94837b944a4ddd21a04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00f5ik sai alguse Leslie Lamperti artiklist, mis kirjutati 1970. aastatel. Nagu n\u00e4ete, j\u00e4tkatakse endiselt selle teema uurimist. Praegu elab Causal consistency huvi seoses jaotatud s\u00fcsteemide arenguga.<\/p>\n<h3>Piirangud<\/h3>\n<p>\nMillised on piirangud? See on tegelikult \u00fcks peamisi punkte, kuna tootmiss\u00fcsteemide kehtestatud piirangud erinevad oluliselt akadeemilistes artiklites esitatud piirangutest. Tihti on need piisavalt kunstlikud.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/9583ba9ff870e4ddc7aad4ba4c59ecc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>Esiteks, \u201eMongoDB\u201c on \u00fcksikmeistriga, nagu ma juba \u00fctlesin (see lihtsustab oluliselt).<\/li>\n<li>Usume, et s\u00fcsteem peaks toetama umbes 10 000 shard'i. Me ei saa teha mingeid arhitektuurilisi otsuseid, mis piiraksid selgelt seda v\u00e4\u00e4rtust.<\/li>\n<li>Meil on pilv, kuid me arvestame, et inimesel peaks olema v\u00f5imalus, kui ta allalaadib binaari, k\u00e4ivitada see oma s\u00fclearvutis ja et k\u00f5ik t\u00f6\u00f6taks h\u00e4sti.<\/li>\n<li>Me arvame, et teadust\u00f6\u00f6s kasutatakse harva: v\u00e4lised kliendid saavad teha mida iganes. \u201eMongoDB\u201c on avatud l\u00e4htekoodiga. Seega v\u00f5ivad kliendid olla piisavalt nutikad, pahatahtlikud \u2013 nad v\u00f5ivad soovida k\u00f5ike h\u00e4vitada. Arvestame, et v\u00f5ivad esineda B\u00fctsantsi veaolukorrad.<\/li>\n<li>V\u00e4listele klientidele, kes on perimeetri v\u00e4ljaspool \u2013 oluline piirang: kui see funktsioon on v\u00e4lja l\u00fclitatud, ei peaks olema mingeid j\u00f5udluse langusi.<\/li>\n<li>Veel \u00fcks punkt \u2013 t\u00e4iesti antiakadeemiline: varasemate ja tulevaste versioonide \u00fchilduvus. Vanad draiverid peavad toetama uusi uuendusi ja andmebaas peab toetama vanu draivereid.<\/li>\n<\/ul>\n<p>\n\u00dcldiselt, k\u00f5ik see kehtestab piirangud.<\/p>\n<h3>Causal consistency komponendid<\/h3>\n<p>\nK\u00e4in n\u00fc\u00fcd l\u00e4bi m\u00f5ned komponendid. Kui vaadata Causal consistency't laiemalt, saab eristada plokke. Valisime teosed, mis kuuluvad mingisse plokki: s\u00f5ltuvuse j\u00e4lgimine, kellade valik, kuidas neid kellasid omavahel s\u00fcnkroniseerida, ning kuidas tagame turvalisuse \u2013 see on umbkaudne plaan, millest ma r\u00e4\u00e4gin:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/10c2631d6e61a280139b448628db763e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>T\u00e4ielik s\u00f5ltuvuse j\u00e4lgimine (Full Dependency Tracking)<\/h3>\n<p>\nMiks see vajalik on? Selleks, et andmed replikeerimisel sisaldaks iga kirje, iga andme muudatus teavet, millest muudatused s\u00f5ltuvad. K\u00f5ige esimene ja naiivne muudatus on see, et iga s\u00f5num, mis sisaldab kirjet, sisaldab teavet eelnevate s\u00f5numite kohta:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/fa5d0086c3c77e33631d8a2cd5c217fa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00e4esolevas n\u00e4ites t\u00e4histavad sulgudes olevad numbrid kirjeid. M\u00f5nikord edastatakse need kirjed koos v\u00e4\u00e4rtustega tervikuna, m\u00f5nikord edastatakse versioonid. Idee on selles, et iga muudatus sisaldab teavet eelneva kohta (see kannab seda endas).<\/p>\n<p>Miks me otsustasime mitte kasutada sellist l\u00e4henemist (t\u00e4ielik j\u00e4lgimine)? Ilmselgelt, sest see l\u00e4henemine on ebapraktiline: iga muudatus sotsiaalv\u00f5rgustikus s\u00f5ltub k\u00f5ikidest eelnevatest muudatustest selles v\u00f5rgustikus, edastades n\u00e4iteks \"Facebooki\" v\u00f5i \"Vkontakte'i\" igas uuenduses. Siiski on palju uuringuid, mis k\u00e4sitlevad just Full Dependency Tracking\u2019ut \u2013 see on enne sotsiaalv\u00f5rgustikke, teatud olukordades t\u00f6\u00f6tab see t\u00f5epoolest.<\/p>\n<h3>Selge s\u00f5ltuvuse j\u00e4lgimine (Explicit Dependency Tracking)<\/h3>\n<p>\nJ\u00e4rgmine \u2013 piiratum. Siin k\u00e4sitletakse samuti teabe edastamist, kuid ainult selle, mis s\u00f5ltub otseselt. Millest mis s\u00f5ltub, m\u00e4\u00e4rab enamasti juba rakendus. Kui andmed replikeeritakse, siis antakse p\u00e4ringu tulemused ainult siis, kui eelnevad s\u00f5ltuvused on rahuldatud, st n\u00e4idatud. Just selles seisneb p\u00f5hjuslik konsistentsus.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/7fe101b998c1a0c922788d8d36a5243f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTa n\u00e4eb, et kirje 5 s\u00f5ltub kirjete 1, 2, 3, 4-st \u2013 seega ootab ta, enne kui klient saab juurdep\u00e4\u00e4su muudatustele, mis on tehtud Penny juurdep\u00e4\u00e4su m\u00e4\u00e4rusega, kui k\u00f5ik eelnevad muudatused on andmebaasis juba l\u00e4bitud.<\/p>\n<p>See ei sobi meile samuti, kuna teavet on ikkagi liiga palju ja see aeglustab. On teine l\u00e4henemine...<\/p>\n<h3>Lamporti kell (Lamport Clock)<\/h3>\n<p>\nNeed on v\u00e4ga vanad. Lamporti kell t\u00e4hendab, et need s\u00f5ltuvused koondatakse skalaarsesse funktsiooni, mida nimetatakse Lamporti kellaks.<\/p>\n<p>Skalaarfunktsioon on teatud abstraktne number. Tihti nimetatakse seda loogiliseks ajaks. Iga s\u00fcndmuse korral see counter suureneb. Counter, mis hetkel on protsessile tuntud, saadab iga s\u00f5numi. On selge, et protsessid v\u00f5ivad olla des\u00fcnhroniseeritud, neil v\u00f5ib olla t\u00e4iesti erinev aeg. Sellegipoolest tasakaalustab s\u00fcsteem sellise s\u00f5numivahetuse kaudu kellasid. Mis juhtub sellisel juhul?<\/p>\n<p>Ma jagasin selle suure shard'i kaheks, et oleks aru saada: Friends v\u00f5ivad elada samas noodis, mis sisaldab osa kogumist, ja Feed \u2013 t\u00e4iesti teises noodis, kus on osa sellest kogumist. Kuidas nad siis v\u00f5ivad mitte ootele j\u00e4\u00e4da? Esiteks \u00fctleb Feed: \u201eReplitseeritud\u201d, seej\u00e4rel \u2013 Friends. Kui s\u00fcsteem ei taga mingit garantiid, et Feed ei kuvatakse enne, kui Friends'i kogumi s\u00f5ltuvused on samuti toimetatud, siis tekib see olukord, millest ma mainisin.<\/p>\n<p>N\u00e4ete, kuidas loogiliselt counter Feed\u2019is suureneb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/bae152d1890b53804f2cb28122983df6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeega on Lamporti kella ja kausaalse j\u00e4rjepidevuse (mida on selgitatud Lamporti kella kaudu) p\u00f5hijoon j\u00e4rgmine: kui meil on s\u00fcndmused A ja B ning s\u00fcndmus B s\u00f5ltub s\u00fcndmusest A *, siis sellest j\u00e4reldub, et Loogiline Aeg s\u00fcndmusele A on v\u00e4iksem kui Loogiline Aeg s\u00fcndmusele B.<\/p>\n<p><i>* M\u00f5nikord \u00f6eldakse ka, et A juhtus enne B, st A juhtus enne B \u2013 see on teatud suhe, mis osaliselt j\u00e4rjestab kogu s\u00fcndmuste hulga, mis kunagi juhtunud on.<\/i><\/p>\n<p>Tagurpidi ei pea see paika. See on tegelikult \u00fcks peamisi puudusi Lamporti kella \u2013 osaline j\u00e4rjestus. Seal on m\u00f5isted samasugustest s\u00fcndmustest, st s\u00fcndmustest, kus ei (A happened before B) ega (B happened before A). N\u00e4iteks v\u00f5ib tuua paralleelse Lisa, kellele Leonardi s\u00f5braks tegemine on kellegi teise (isegi mitte Leonardi, vaid n\u00e4iteks Sheldoni) poolt.<br \/>\nSee on omadus, mida sageli kasutatakse Lamporti kellade t\u00f6\u00f6s: vaatakse just funktsiooni ja sellest tehakse j\u00e4reldus \u2013 need s\u00fcndmused v\u00f5ivad olla s\u00f5ltuvad. Sest \u00fches suunas see kehtib: kui Loogiline Aeg A on v\u00e4iksem kui Loogiline Aeg B, siis B ei saa juhtuda enne A; kui see on rohkem, siis v\u00f5ib olla.<\/p>\n<h3>Vektorikellad (Vector Clock)<\/h3>\n<p>\nLamporti kellade loogiline areng on Vektorikellad. Need erinevad seet\u00f5ttu, et iga siin olev nood sisaldab oma, eraldi kella, ja need edastatakse vektorina.<br \/>\nAntud juhul n\u00e4ete, et vektori nullindeks vastutab Feed'i eest, samas kui esimene indeks vastutab Friends'i eest (iga\u00fcks neist nodest). Ja need hakkavad n\u00fc\u00fcd suurenema: nullindeks \"Feed\" suureneb, kui see salvestatakse \u2013 1, 2, 3:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/d89292686ed8dd41aef06090f16db1c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMiks on vektorikellad paremad? Kuna nad v\u00f5imaldavad m\u00f5ista, millised s\u00fcndmused on samaaegsed ja millal nad erinevates nodedes toimuvad. See on v\u00e4ga oluline sharding-s\u00fcsteemi jaoks, nagu \"MongoDB\". Kuid me ei valinud seda, kuigi see on suurep\u00e4rane asi, t\u00f6\u00f6tab suurep\u00e4raselt ja oleks meile t\u00f5en\u00e4oliselt sobinud...<\/p>\n<p>Kui meil on 10 000 shard'i, ei saa me edastada 10 000 komponenti, isegi kui me komprimeerime v\u00f5i m\u00f5tleme midagi muud v\u00e4lja \u2013 kasulik koormus j\u00e4\u00e4b ikkagi palju v\u00e4iksemaks kui kogu selle vektori maht. Seet\u00f5ttu, s\u00fcdame ja hammaste krigistamisega, loobusime sellest l\u00e4henemisest ja l\u00e4ksime edasi teise.<\/p>\n<h3>Spanner TrueTime. Aatomikellad<\/h3>\n<p>\nMa r\u00e4\u00e4kisin, et tulemas on jutt \"Spannerist\". See on \u00e4ge asi, justkui XXI sajand: aatomikellad, GPS-s\u00fcnkroniseerimine.<\/p>\n<p>Mis on idee? \"Spanner\" on Google'i s\u00fcsteem, mis hiljuti muutus isegi inimeste jaoks kergesti k\u00e4ttesaadavaks (nad lisasid sellele SQL-i). Igal tehingul on seal teatud ajatemperatuur. Kuna aeg on s\u00fcnkroniseeritud*, saab igale s\u00fcndmusele m\u00e4\u00e4rata kindla ajatemperatuur \u2013 aatomikelladel on ooteaeg, mille m\u00f6\u00f6dudes toimub garantiiga juba mingi muu aeg.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/707b5998fbb500d201aafffccc666f0e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeega, lihtsalt andmebaasi kirjutades ja oodates teatud aja, garanteeritakse automaatselt s\u00fcndmuse Serializability. Neil on k\u00f5ige tugevam Consistency mudel, mida \u00fcldse ette kujutada saab \u2013 see on External Consistency.<\/p>\n<p>* See on peamine probleem Lamporti kelladega \u2013 nad ei ole kunagi s\u00fcnkroonis jaotatud s\u00fcsteemides. Nad v\u00f5ivad t\u00f6\u00f6delda isegi NTP puhul mitte v\u00e4ga h\u00e4sti. \"Spanner\" on varustatud aatomikellade ja s\u00fcnkroniseerimisega, tundub, et mikrosekundite t\u00e4psusega.<\/p>\n<p>Miks me seda ei valinud? Me ei eelda, et meie kasutajatel on olemas sisse ehitatud aatomikellad. Kui need oleksid olemas, korralikult igasse s\u00fclearvutisse integreeritud, oleks seal mingi super\u00e4ge GPS-s\u00fcnkroniseerimine \u2013 siis jah... Siiski, hetkel on parim, mis v\u00f5imalik \u2013 \"Amazon\", Base Stations \u2013 fanaatikute jaoks... Seet\u00f5ttu kasutasime teisi kelli.<\/p>\n<h3>H\u00fcbriidkell (Hybrid Clock)<\/h3>\n<p>\nSee, mis see t\u00f5ukab \u00abMongoDB\u00bb Causal consistency'i tagamiseks. Kuidas need h\u00fcbriidsed on? H\u00fcbriid on skalaarsed v\u00e4\u00e4rtused, kuid need koosnevad kahest komponendist:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/dab03a87d9f6ee2e716f75baff1736bc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>Esimene on unix'i ajajoon (kui palju sekundeid on m\u00f6\u00f6dunud \u00abarvutimaailma algusest\u00bb).<\/li>\n<li>Teine on teatud inkrement, samuti 32-bitine unsigned int.<\/li>\n<\/ul>\n<p>\nSee ongi k\u00f5ik. On olemas l\u00e4henemine: osa, mis vastutab aja eest, s\u00fcnkroniseeritakse pidevalt kelladega; iga kord, kui toimub v\u00e4rskendus, s\u00fcnkroniseeritakse see osa kelladega ja tulemusena on aeg alati enam-v\u00e4hem \u00f5ige, samas kui inkrement v\u00f5imaldab eristada s\u00fcndmusi, mis juhtusid samal ajal.<\/p>\n<p>Miks see on \u00abMongoDB\u00bb jaoks oluline? Sest see v\u00f5imaldab teha varukoopiaid teatud ajahetkel, see t\u00e4hendab, et s\u00fcndmus indekseeritakse ajaks. See on oluline, kui on vaja m\u00f5ningaid s\u00fcndmusi; andmebaasi jaoks on s\u00fcndmused need muudatused andmebaasis, mis toimusid teatud ajahetkedel.<\/p>\n<p>Ma \u00fctlen teile ainult peamise p\u00f5hjuse (palun, \u00e4rge r\u00e4\u00e4kige seda kellelegi)! Me tegime seda nii, kuna just nii n\u00e4evad v\u00e4lja korraldatud, indekseeritud andmed MongoDB OpLog'is. OpLog on andmestruktuur, mis sisaldab k\u00f5iki muudatusi andmebaasis: need satuvad esmalt OpLog'i ja siis rakendatakse need juba andmesalvestamisele, kui tegemist on replikatsiooniandmete v\u00f5i shard'iga.<\/p>\n<p>See oli peamine p\u00f5hjus. Siiski on olemas ka praktilised n\u00f5udmised andmebaasi arendusele, mis t\u00e4hendab, et see peab olema lihtne \u2013 v\u00e4hem koodi, v\u00f5imalikult v\u00e4he purunenud asju, mida tuleks \u00fcmber kirjutada ja testida. See, et meie op-logid osutusid indekseeritud h\u00fcbriidsete kelladega, aitas palju ja v\u00f5imaldas teha \u00f5ige valiku. See t\u00f5esti \u00f5igustas end ja t\u00f6\u00f6tas kuidagi maagiliselt, juba esimeses protot\u00fc\u00fcbis. Oli v\u00e4ga \u00e4ge!<\/p>\n<h3>Kellade s\u00fcnkroniseerimine<\/h3>\n<p>\nOn mitmeid viise s\u00fcnkroonimiseks, nagu on kirjeldatud teaduslikus kirjanduses. Ma r\u00e4\u00e4gin s\u00fcnkroonimisest, kui meil on kaks erinevat shard'i. Kui on olemas vaid \u00fcks replika-grupp, ei ole s\u00fcnkroonimine vajalik: see on '\u00fcks-ise-juhtiv'; meil on OpLog, kuhu k\u00f5ik muudatused j\u00f5uavad \u2013 sellisel juhul on k\u00f5ik juba j\u00e4rjekorras 'OpLogis'. Kuid kui meil on kaks erinevat shard'i, on siin ajas\u00fcnkroonimise t\u00e4htsus suur. Just siin aitasid vektorkellad rohkem! Aga meil neid pole.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/7d3306747490ac044b7f8130defea0c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeine sobiv variant on 'S\u00fcdamel\u00f6\u00f6gid' (Heartbeats). Saame vahetada teatud signaale, mis toimuvad iga ajavahemiku j\u00e4rel. Kuid 'S\u00fcdamel\u00f6\u00f6gid' on liiga aeglased, me ei saa klientidele tagada madalat latentsust.<\/p>\n<p>T\u00f5eline aeg \u2013 muidugi, see on suurep\u00e4rane asi. Kuid j\u00e4lle, see on ilmselt tulevik... Kuigi 'Atlas' v\u00f5imaldab seda juba, on olemas kiired 'Amazon'i aegade s\u00fcnkroonijad. Kuid see ei ole k\u00f5igile kergesti ligip\u00e4\u00e4setav.<\/p>\n<p>Kossipimine (Gossiping) \u2013 see on siis, kui k\u00f5ik s\u00f5numid sisaldavad aega. See on umbes see, mida me kasutame. Iga s\u00f5num node'ide vahel, draiver, andmete node'i ruuter \u2013 absoluutselt k\u00f5ik 'MongoDB' jaoks \u2013 on mingid elemendid, andmebaasi komponendid, mis sisaldavad kelli, mis tiksuvad. Neil k\u00f5igil on h\u00fcbriidse aja v\u00e4\u00e4rtus, see edastatakse. 64 bitti? See on lubatud, see on v\u00f5imalik.<\/p>\n<h3>Kuidas k\u00f5ik see koos t\u00f6\u00f6tab?<\/h3>\n<p>\nSiin vaatlen \u00fchte replika-gruppi, et see oleks veidi lihtsam. On olemas Primaarne ja Sekundaarne. Sekundaarne teostab replikatsiooni ja ei ole alati t\u00e4ielikult s\u00fcnkroonitud Primaarsega.<\/p>\n<p>Toimub sisestamine (insert) 'Primaaris' koos mingi ajav\u00e4\u00e4rtusega. See sisestamine suurendab siseselt loendurit 11 v\u00f5rra, kui see on maksimaalne. V\u00f5i see kontrollib kellade v\u00e4\u00e4rtusi ja s\u00fcnkroonib kellade j\u00e4rgi, kui kellade v\u00e4\u00e4rtused on suuremad. See v\u00f5imaldab aega j\u00e4rjestada.<\/p>\n<p>P\u00e4rast seda, kui ta teeb kirje, toimub oluline moment. Kellad 'MongoDB's' ja inkrementeeritakse ainult kirje tegemise korral 'Oplogis'. See on see s\u00fcndmus, mis muudab s\u00fcsteemi olekut. Absoluutselt k\u00f5igis klassikalistes artiklites peetakse s\u00fcndmuseks s\u00f5numi j\u00f5udmist node'isse: s\u00f5num on saabunud \u2013 see t\u00e4hendab, et s\u00fcsteem muutis oma olekut.<\/p>\n<p>See, when studying this, it's not entirely clear how this message will be interpreted. We know for sure that if it is not reflected in the 'OpLog', it will not be interpreted at all, and changing the state of the system is only a record in the 'OpLog'. This simplifies everything for us: both the model is simplified, and it allows for ordering within a single replica set, along with many other useful things.<\/p>\n<p>The value that has already been recorded in the 'OpLog' is returned \u2013 we know this value is in the 'OpLog', and its time is 12. Now, let's say reading starts from another node (Secondary), and it already transmits afterClusterTime in the message. It says: 'I need everything that happened at least after 12 or at twelve' (see the figure above).<\/p>\n<p>This is what is called Causal and consistent (CAT). There is a concept in theory that this is some slice of time that is consistent in itself. In this case, we can say that this is the state of the system that was observed at the time of 12.<\/p>\n<p>Currently, there's nothing here yet because it simulates a situation where the Secondary needs to replicate data from the Primary. It's waiting... And then the data arrives \u2013 it returns these values back.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/54d9de3e2696c1e5d19f4da206be090b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis is roughly how it works. Almost.<\/p>\n<p>What does 'almost' mean? Let's assume there is a person who read and understood how it all works. They understood that every time there is a ClusterTime, it updates the internal logical clocks, and then the next record increments by one. This function takes 20 lines. Suppose this person transmits the largest possible 64-bit number, minus one.<\/p>\n<p>Why 'minus one'? Because the internal clocks will be substituted into this value (obviously, this is the largest possible, greater than the current time), then a record will be made in the 'OpLog', and the clocks will increment by one more \u2013 and it will already be the maximum value (there are just all ones, there\u2019s nowhere to go, unsigned ints).<\/p>\n<p>It's clear that after this, the system becomes absolutely unavailable for anything. It can only be unloaded, cleaned \u2013 a lot of manual work. Full availability:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/634b25fe0ef1e0af39181cd59c7b522f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKuna see replitseerub kuhugi mujale, siis kukub kogu klaster lihtsalt kokku. Absoluutselt vastuv\u00f5etamatu olukord, mille iga inimene saab kiiresti ja lihtsalt korraldada! Seet\u00f5ttu pidasime seda aspekti \u00fcheks olulisemaks. Kuidas seda ennetada?<\/p>\n<h3>Meie tee on allkirjastada clusterTime<\/h3>\n<p>\nNii edastatakse see s\u00f5numis (sinise teksti all). Kuid me hakkasime ka genereerima allkirja (sinine tekst):<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/c16e985f9610e01a61293e0d6dde459b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAllkiri genereeritakse v\u00f5tme abil, mis on salvestatud andmebaasi, kaitstud perimeetris; see genereeritakse ja uuendatakse (kasutajad ei n\u00e4e sellest midagi). Genereeritakse hash, ja iga s\u00f5num allkirjastatakse loomise ajal ning vastuv\u00f5tmise ajal valideeritakse.<br \/>\nT\u00f5en\u00e4oliselt tekib inimestel k\u00fcsimus: \u201eKui palju see k\u00f5ike aeglustab?\u201d Ma \u00fctlesin, et see peaks kiiresti t\u00f6\u00f6tama, eriti ilma selle funktsioonita.<\/p>\n<p>Mida t\u00e4hendab Causal consistency kasutamine antud juhul? See n\u00e4itab afterClusterTime parameetrit. Ilma selleta edastab see v\u00e4\u00e4rtusi igal juhul. Gossiping t\u00f6\u00f6tab alates versioonist 3.6 alati.<\/p>\n<p>Kui me j\u00e4tame pideva allkirjade genereerimise, siis see aeglustab s\u00fcsteemi isegi funktsioonide puudumisel, mis ei vasta meie l\u00e4henemistele ja n\u00f5uetele. Ja mida me tegime?<\/p>\n<h3>Tee seda kiiresti!<\/h3>\n<p>\nVihtsasti lihtne asi, aga trikk on huvitav \u2013 jagan, v\u00f5ib-olla kellelegi on kasulik.<br \/>\nMeil on hash, milles on allkirjastatud andmed. K\u00f5ik andmed l\u00e4hevad l\u00e4bi cache'i. Cache allkirjastab mitte konkreetselt aja, vaid Rangi. Kui tuleb mingi v\u00e4\u00e4rtus, genereerime Rangi, maskeerime viimased 16 bitti ja seda v\u00e4\u00e4rtust me allkirjastame:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/f4810456f08ba1cc69730ac0079d4206.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSaades sellise allkirja, kiirendame s\u00fcsteemi (tinglikult) 65 tuhat korda. See t\u00f6\u00f6tab suurep\u00e4raselt: katsetades - seal on t\u00f5eliselt 10 tuhande v\u00f5rra aega v\u00e4henenud, kui meil on j\u00e4rjepidev uuendus. Ilmselgelt, kui need on segaduses, ei toimi see. Kuid enamikes praktilistes olukordades see t\u00f6\u00f6tab. Allkirja Rangi kombinatsioon koos allkirjaga aitas lahendada turvalisuse probleemi.<\/p>\n<h3>Selge on, et iga teenus p\u00fc\u00fcab v\u00e4ltida seisakuid. Meie puhul usume, et hiljutised katkestused aitasid teha quay.io paremaks. Meie jaoks t\u00f5ime v\u00e4lja mitmed peamised \u00f5ppetunnid, mida soovime jagada:<\/h3>\n<p>\n\u00d5ppetunnid, mille me sellest \u00f5ppisime:<\/p>\n<ul>\n<li>Materjale, lugusid ja artikleid tuleb lugeda, kuna meil on palju huvitavat. Kui me t\u00f6\u00f6tame mingi funktsiooni kallal (eriti praegu, kui oleme teinud tehingute osas jne), siis tuleb lugeda ja m\u00f5ista. See v\u00f5tab aega, kuid see on tegelikult v\u00e4ga kasulik, kuna selgub, kus me oleme. Me ei ole midagi uut v\u00e4lja m\u00f5elnud \u2013 lihtsalt v\u00f5tsime koostisosad.\n<p>Koosolekute korral, nagu n\u00e4iteks akadeemilised konverentsid (\u201eSigmon\u201d), on m\u00f5tlemises kindel erinevus \u2013 seal keskenduvad k\u00f5ik uutele ideedele. Kus on meie algoritmi uuenduslikkus? Siin uut pole. Uuendus seisneb pigem selles, kuidas me segasime kokku olemasolevaid l\u00e4henemisviise. Seep\u00e4rast tuleb k\u00f5igepealt lugeda klassikuid, alustades Lamportist.<\/li>\n<li>Tootmises on n\u00f5udmised t\u00e4iesti teised. Olen kindel, et paljud teist ei puutu kokku \u201esf\u00e4\u00e4riliste\u201d andmebaasidega abstraktses vaakumis, vaid normaalses, reaalses maailmas, kus esinevad k\u00e4ttesaadavuse, latentsuse ja talitluse j\u00e4rjepidevuse probleemid.<\/li>\n<li>Viimase asjana pidime arvestama erinevaid ideid ja kombineerima mitmest t\u00e4iesti erinevast artiklist \u00fche l\u00e4henemise. N\u00e4ide allkirjastamisest tuli t\u00e4iesti artiklist, mis k\u00e4sitles Paxosi protokolli, mis on m\u00f5eldud mitte-byzantia aluste eba\u00f5nnestumiseks autoriseerimisprotokollis, byzantiaalsete jaoks aga selle piiridest v\u00e4ljas... \u00dches\u00f5naga, see on just see, mida me l\u00f5puks tegime.\n<p>Siin pole absoluutselt midagi uut! Kuid kui me k\u00f5ik selle kokku segasime... On sama, mis \u00f6elda, et Olivier salati retsept on vale, kuna munad, majonees ja kurk on juba v\u00e4lja m\u00f5eldud... See on umbes sama lugu.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/2f9e5cb77079f9a0f7bdf76430c3386e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSellega l\u00f5petan. Ait\u00e4h!<\/p>\n<h3>K\u00fcsimused<\/h3>\n<p>\n<b>K\u00fcsimus saalist (edasi - K):<\/b> \u2013 Ait\u00e4h, Mihhail, et esitlesite! Aeg on huvitav teema. Te kasutate Gossiping'ut. \u00dctlesite, et k\u00f5igil on oma aeg, k\u00f5ik teavad oma kohalikku aega. Olen aru saanud, et meil on draiver \u2013 kliente ja draivereid v\u00f5ib olla palju, samuti query-planner'eid, shard'e, neid on samuti palju... Kuidas s\u00fcsteem sellisel juhul k\u00e4itub, kui \u00e4kki tekib lahknevus: keegi arvab, et ta on minuti ees, keegi \u2013 minuti taga? Kuhu me j\u00e4\u00e4me?<\/p>\n<p><b>MT:<\/b> \u2013 Suurep\u00e4rane k\u00fcsimus! Ma tahtsin just shardidest r\u00e4\u00e4kida. Kui ma \u00f5igesti k\u00fcsimusest aru saan, siis meil on selline olukord: on shard 1 ja shard 2, lugemine toimub nende kahe shardiga \u2013 neil on erinevus, nad ei suhtle omavahel, kuna aeg, mida nad tunnevad, on erinev, eriti aeg, mil nad eksisteerivad oplogides.<br \/>\nOletame, et shard 1 tegi miljon kirjet, shard 2 ei teinud midagi, ja p\u00e4ring tuli kahte shardi. Ja esimesel on afterClusterTime rohkem kui miljon. Sellises olukorras, nagu ma selgitasin, shard 2 kunagi ei vasta.<\/p>\n<p><b>K:<\/b> \u2013 Soovisin teada, kuidas nad s\u00fcnkroniseeruvad ja valivad \u00fche loogilise aja?<\/p>\n<p><b>MT:<\/b> \u2013 Need s\u00fcnkroniseeruvad v\u00e4ga lihtsalt. Shard, kui talle tuleb afterClusterTime ja ta ei leia aega \u201eOplogist\u201d \u2013 algatab no approved. See t\u00e4hendab, et ta t\u00f5stab ise oma aega sellele v\u00e4\u00e4rtusele. See t\u00e4hendab, et tal ei ole s\u00fcndmusi, mis vastavad sellele p\u00e4ringule. Ta loob selle s\u00fcndmuse kunstlikult ja muutub seega Causal Consistent.<\/p>\n<p><b>K:<\/b> \u2013 Ja kui talle p\u00e4rast seda saabuvad veel mingid s\u00fcndmused, mis kuskil v\u00f5rgus kaotsi l\u00e4ksid?<\/p>\n<p><b>MT:<\/b> \u2013 Shard on nii ehitatud, et need ei saabu enam, kuna see on \u00fcksik master. Kui ta on juba kirja pannud, siis need ei saabu enam, vaid j\u00e4\u00e4vad hiljem. Ei saa nii olla, et kuskil midagi j\u00e4\u00e4b seisma, siis ta teeb no write, ja seej\u00e4rel need s\u00fcndmused saabuvad \u2013 ja Causal consistency on rikutud. Kui ta teeb no write, peavad nad k\u00f5ik edasi saabuma (ta ootab neid).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/dbbc7c5c653f0c9fa449cceb88ed62ef.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>K:<\/b> \u2013 Mul on m\u00f5ned k\u00fcsimused j\u00e4rjekordade kohta. Causal consistency eeldab, et on olemas teatud tegevuste j\u00e4rjekord, mis tuleb teostada. Mis juhtub, kui meil kaob \u00fcks pakett? Siis l\u00e4ks 10., 11... 12. kaduma, aga k\u00f5ik teised ootavad, kuni see t\u00e4idetakse. Ja \u00e4kki on meie masin surnud, me ei saa midagi teha. Kas on mingi maksimaalne j\u00e4rjekorra pikkus, mis koguneb, enne kui see t\u00e4idetakse? Mis on fataalne rike, mis juhtub \u00fche staatuse kaotamisel? Eriti kui me salvestame, et on mingi eelmine seisund, siis peaksime justkui sellest l\u00e4htuma? Aga me ei saanudki l\u00e4htuda!<\/p>\n<p><b>MT:<\/b> \u2013 Samuti suurep\u00e4rane k\u00fcsimus! Mida me teeme? MongoDB-s on kvorumkirjete ja kvorumlugemise m\u00f5isted. Millal s\u00f5num v\u00f5ib kaduda? Kui teadmine ei ole kvorum v\u00f5i kui lugemine ei ole kvorum (v\u00f5ib tekkida mingi pr\u00fcgi).<br \/>\nSeoses Causal consistency teostasime ulatusliku eksperimentaalse kontrolli, mille tulemuseks oli, et siis, kui salvestamine ja lugemine on mitte-kvoorumlikud, esinevad Causal consistency rikkumised. Just nii, nagu te r\u00e4\u00e4gite!<\/p>\n<p>Meie soovitus: kasutage v\u00e4hemalt kvoorumlikku lugemist Causal consistency rakendamisel. Sel juhul ei kaota te midagi, isegi kui kvoorumlik salvestamine peaks kaduma... See on ortogonaalne olukord: kui kasutaja ei soovi, et andmed kaoksid, tuleb kasutada kvoorumlikku salvestamist. Causal consistency ei anna p\u00fcsivuse tagatist. P\u00fcsivuse tagatist annab replikaator ja replikatsiooniga seotud mehhanism.<\/p>\n<p><b>K:<\/b> \u2013 Kui me loome instantsi, mis tegeleb shardimisega (mitte master, vaid slave vastavalt), toetub see enda masina unix-ajal v\u00f5i \u00abmaistri\u00bb ajale; kas see s\u00fcnkroniseeritakse esmakordselt v\u00f5i perioodiliselt?<\/p>\n<p><b>MT:<\/b> \u2013 Selgitan hetkel. Shard (st horisontaalne partitsioon) \u2013 seal on alati Primaarne. Ja shardis v\u00f5ib olla \u00abmaaster\u00bb ning replikad. Kuid shard toetab alati salvestamist, sest see peab toetama mingit domeeni (shardis on Primaarne).<\/p>\n<p><b>K:<\/b> \u2013 Kas see t\u00e4hendab, et k\u00f5ik s\u00f5ltub ainult \u00abmaistrist\u00bb? Kas alati kasutatakse \u00abmaistri\u00bb aega?<\/p>\n<p><b>MT:<\/b> \u2013 Jah. Kujundlikult \u00f6eldes: kellad tikuvad, kui salvestamine toimub \u00abmaistris\u00bb, \u00abOplogis\u00bb.<\/p>\n<p><b>K:<\/b> \u2013 Meil on klient, kes \u00fchendub ja ei pea ajast midagi teadma?<\/p>\n<p><b>MT:<\/b> \u2013 \u00dcldse mitte midagi ei pea teadma! Kui r\u00e4\u00e4kida, kuidas see kliendi poolel t\u00f6\u00f6tab: kliendil, kui ta tahab kasutada Causal consistency, tuleb avada sessioon. Seal on k\u00f5ik: nii sessioonis olevad tehingud kui ka \u00f5iguste hankimine\u2026 Sessioon on loogiliste s\u00fcndmuste j\u00e4rjestamine, mis juhtuvad kliendiga.<\/p>\n<p>Kui ta avab selle sessiooni ja \u00fctleb, et tahab Causal consistency (kui sessioon toetab vaikimisi Causal consistency), toimib k\u00f5ik automaatselt. Draiver m\u00e4letab seda aega ja suurendab seda, kui saab uue s\u00f5numi. Ta m\u00e4letab, millise vastuse eelmine server andis, mis andmed tagastas. J\u00e4rgmine p\u00e4ring sisaldab afterCluster (\u00abaeg suurem kui see\u00bb).<\/p>\n<p>Klient ei pea teadma t\u00e4pselt midagi! See on tema jaoks t\u00e4iesti l\u00e4bipainev. Kui inimesed kasutavad neid funktsioone, siis mis see v\u00f5imaldab? Esiteks saab turvaliselt lugeda sekundaarseid: saab kirjutada Primaarsele ja lugeda geograafiliselt replitseeritud sekundaarsetelt ning olla kindel, et see t\u00f6\u00f6tab. Samal ajal saab Primaarsele kirjutatud sessioone edastada isegi Sekundaarsele, st saab kasutada mitut sessiooni.<\/p>\n<p><b>K:<\/b> \u2013 T\u00f6\u00f6tlusteadusest on tihedalt seotud uus plaan, milleks on CRDT (Conflict-free Replicated Data Types) andmet\u00fc\u00fcbid. Kas olete kaalunud nende andmet\u00fc\u00fcpide integreerimist andmebaasi ja mida saate selle kohta \u00f6elda?<\/p>\n<p><b>MT:<\/b> \u2013 Heal k\u00fcsimuse! CRDT-l on m\u00f5tet kirjutamisvaidluste korral: MongoDB-s on see \u00fcksikmeistrina.<\/p>\n<p><b>K:<\/b> \u2013 Mul on dev-opsidelt k\u00fcsimus. T\u00f5elises maailmas esinevad sellised keerulised olukorrad, kus toimub B\u00fctsantsi rike, ja halvad inimesed kaitstud perimeetri sees hakkavad protokolli nuhkima, saates spetsiaalselt valmistatud pakette?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/99a521d04b416e6978aa68ce7c4a4c46.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>MT:<\/b> \u2013 Halvad inimesed perimeetri sees on nagu troojalane! Halvad inimesed perimeetri sees saavad teha palju halbu asju.<\/p>\n<p><b>K:<\/b> \u2013 Loomulikult ei ole \u00f5ige j\u00e4tta serverisse, \u00fctleme, auku, mille kaudu saab suur elevant sisse suruda ja kogu klastrit igaveseks kokku kukutada... See n\u00f5uab k\u00e4sitsi taastamiseks aega... See on, pehmelt \u00f6eldes, vale. Teiselt poolt, huvitav on see, et reaalses elus, praktikas esinevad sellised olukorrad, kus t\u00f5eliselt aset leidnud sisesed r\u00fcnnakud juhtuvad?<\/p>\n<p><b>MT:<\/b> \u2013 Kuna ma ei puutu elus sageli kokku turvalisuse rikkumisega, ei saa ma \u00f6elda - v\u00f5ib-olla need ikkagi juhtuvad. Aga kui r\u00e4\u00e4kida arendustfilosoofiast, siis arvame nii: meil on perimeeter, mis tagab need, kes tegelevad turvalisusega - see on lukustusem\u00fc\u00fcr; ja perimeetri sees v\u00f5ib teha k\u00f5ike, mida iganes. On selge, et on kasutajad, kes saavad ainult vaadata, ja on kasutajad, kellel on v\u00f5imalus katalooge kustutada.<\/p>\n<p>S\u00f5ltuvalt \u00f5igustest v\u00f5ib kasutajate tekitatud kahju olla hiire v\u00f5i isegi elevandi tase. Selge on, et t\u00e4ielike \u00f5igustega kasutaja v\u00f5ib teha absoluutselt k\u00f5ike. Kasutaja, kellel on piiratud \u00f5igused, v\u00f5ib tekitada oluliselt v\u00e4hem kahju. Eriti ei saa ta s\u00fcsteemi purustada.<\/p>\n<p><b>K:<\/b> \u2013 Suletud perimeetris p\u00fc\u00fcab keegi serveri jaoks ootamatuid protokolle koostada, et serverit alandada ja ehk isegi kogu klastrit\u2026 Kas see v\u00f5ib olla nii \"hea\"?<\/p>\n<p><b>MT:<\/b> \u2013 Ma pole kunagi sellistest asjadest kuulnud. Et serverit saab sel viisil t\u00f5rjuda \u2013 see ei ole saladus. T\u00f5rjumine seestpoolt, olles protokollis, olles autoriseeritud kasutaja, kes suudab s\u00f5numisse midagi kirjutada\u2026 Tegelikult ei saa, sest see verifitseeritakse ikkagi. On v\u00f5imalus keelata see autentimine kasutajatele, kes seda ei soovi \u2013 see on siis nende probleem; nad on nagu omal k\u00e4el seinu purustanud ja sinna elevandi toppida, mis k\u00f5ik purustab\u2026 Aga tegelikult, v\u00f5ib remondimehena riides tulla ja v\u00e4lja t\u00f5mmata!<\/p>\n<p><b>K:<\/b> \u2013 Ait\u00e4h ettekande eest. Sergei (\"Yandex\"). \"Mongos\" on konstant, mis piirab h\u00e4\u00e4letavate liikmete arvu Replica Set\u2019is, ja see konstant on 7 (seitsme). Miks see on konstant? Miks mitte m\u00f5ni parameter?<\/p>\n<p><b>MT:<\/b> \u2013 Replica Set\u2019id v\u00f5ivad meil olla ka 40 node\u2019iga. Seal on alati enamuse reegel. Ma ei tea, mis versioon see on\u2026<\/p>\n<p><b>K:<\/b> \u2013 Replica Set\u2019is v\u00f5ib h\u00e4\u00e4letamata liikmeid k\u00e4ivitada, aga h\u00e4\u00e4letavaid \u2013 maksimaalselt 7. Kuidas sel juhul taluda katkestust, kui meie Replica Set on kolme andmekeskuse vahel? \u00dcks andmekeskus v\u00f5ib \u00fcsna lihtsalt v\u00e4lja l\u00fclituda ja veel \u00fcks masin v\u00f5ib kaduda.<\/p>\n<p><b>MT:<\/b> \u2013 See on juba veidi v\u00e4ljaspool ettekannet. See on \u00fcldine k\u00fcsimus. V\u00f5ib-olla r\u00e4\u00e4gin sellest hiljem.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihhail T\u0161ulenjev (MongoDB): Causal consistency: teooriast praktikani\" src=\"\/wp-content\/uploads\/2020\/02\/161966c7e77704dc619674ff0302ff57.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"UnAprFMX1d4\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/UnAprFMX1d4\/hqdefault.jpg\" alt=\"M\u00e4ngi videot\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Veidi reklaami \ud83d\ude42<\/h3>\n<p>\nAit\u00e4h, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite n\u00e4ha rohkem huvitavat sisu? Toetage meid, tellides teenuse v\u00f5i soovitades meid tuttavatele. <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">Pilve VPS arendajatele alates $4.99<\/a><\/noindex>, <b>ainulaadne entry-level serverite analoog, mille oleme teie jaoks v\u00e4lja m\u00f5elnud:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Kogu t\u00f5de VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 v\u00f5i kuidas jagada serverit \u00f5igesti?<\/a><\/noindex> (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).<\/p>\n<p><b>Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam?<\/b> Ainult meie juures <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199<\/a><\/noindex> Hollandis! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 alates $99!<\/b><\/b> Lugege sellest <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Kuidas luua ettev\u00f5tte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?<\/a><\/noindex><br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/487638\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u041a\u0440\u0430\u0441\u043d\u043e\u044f\u0440\u0441\u043a\u00bb. 25 \u0438\u044e\u043d\u044f, 12:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0411\u044b\u0432\u0430\u0435\u0442, \u0447\u0442\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u0443\u044e\u0442 \u0441 \u0442\u0435\u043e\u0440\u0438\u0435\u0439, \u0433\u0434\u0435 \u043d\u0435 \u0443\u0447\u0442\u0435\u043d\u044b \u0432\u0430\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u043a\u043e\u043c\u043c\u0435\u0440\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 \u0430\u0441\u043f\u0435\u043a\u0442\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0432\u044b\u0431\u043e\u0440\u0430 \u0438 \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432 \u043a \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-56365","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u041c\u0438\u0445\u0430\u0438\u043b \u0422\u044e\u043b\u0435\u043d\u0435\u0432 (MongoDB): Causal consistency: \u043e\u0442 \u0442\u0435\u043e\u0440\u0438\u0438 \u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-10T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:04:37+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Mihhail Tjulenjev (MongoDB): Kausaalne j\u00e4rjepidevus: teooriast praktikani | ProHoster","description":"J\u00e4rgmine konverents HighLoad++ toimub 6. ja 7. aprillil 2020 Peterburis. \u00dcksikasjad ja piletid lingil.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u041c\u0438\u0445\u0430\u0438\u043b \u0422\u044e\u043b\u0435\u043d\u0435\u0432 (MongoDB): Causal consistency: \u043e\u0442 \u0442\u0435\u043e\u0440\u0438\u0438 \u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 | ProHoster","og:description":"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-10T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56365","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:26:38","updated":"2022-09-29 16:36:31","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/56365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=56365"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/56365\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=56365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=56365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=56365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}