NewSQL = NoSQL+ACID

Доскоро в Odnoklassniki около 50 TB данни, обработвани в реално време, се съхраняваха в SQL Server. За такъв обем е почти невъзможно да се осигури бърз и надежден и дори устойчив на грешки достъп до центъра за данни с помощта на SQL СУБД. Обикновено в такива случаи се използва едно от хранилищата на NoSQL, но не всичко може да бъде прехвърлено към NoSQL: някои обекти изискват гаранции за транзакция на ACID.

Това ни доведе до използването на NewSQL съхранение, тоест СУБД, която осигурява толерантност към грешки, мащабируемост и производителност на NoSQL системите, но в същото време запазва ACID гаранциите, познати на класическите системи. Има малко работещи индустриални системи от този нов клас, така че сами внедрихме такава система и я пуснахме в търговска експлоатация.

Как работи и какво се случи - прочетете под разреза.

Днес месечната аудитория на Odnoklassniki е повече от 70 милиона уникални посетители. Ние влезе в челната петица най-големите социални мрежи в света и в първите двадесет сайта, на които потребителите прекарват най-много време. Инфраструктурата „OK“ се справя с много големи натоварвания: над милион HTTP заявки/сек на фронт. Части от сървърния парк в размер на повече от 8000 броя са разположени близо една до друга - в четири московски центъра за данни, което позволява да се осигури мрежово забавяне по-малко от 1 ms между тях.

Използваме Cassandra от 2010 г., започвайки с версия 0.6. Днес работят няколко десетки клъстера. Най-бързият клъстер обработва над 4 милиона операции в секунда, докато най-големият съхранява 260 TB.

Това обаче са всички обикновени NoSQL клъстери, използвани за съхранение слабо координирани данни. Също така искахме да заменим основното последователно хранилище, Microsoft SQL Server, което се използва от основаването на Odnoklassniki. Хранилището се състоеше от повече от 300 машини SQL Server Standard Edition, които съдържаха 50 TB данни - бизнес обекти. Тези данни се модифицират като част от ACID транзакции и изискват висока консистенция.

За да разпределим данни между възлите на SQL Server, използвахме както вертикални, така и хоризонтални преграждане (шардинг). В исторически план използвахме проста схема за разделяне на данни: всеки обект беше свързан с токен - функция на идентификатора на обекта. Обекти със същия токен бяха поставени на един и същ SQL сървър. Връзката главен-детайл беше внедрена по такъв начин, че токените на главния и дъщерния запис винаги съвпадат и се намират на един и същи сървър. В една социална мрежа почти всички записи се генерират от името на потребителя, което означава, че всички потребителски данни в рамките на една функционална подсистема се съхраняват на един сървър. Това означава, че една бизнес транзакция почти винаги включва таблици на един SQL сървър, което прави възможно осигуряването на съгласуваност на данните с помощта на локални ACID транзакции, без да е необходимо да се използва бавен и ненадежден разпределени ACID транзакции.

Благодарение на шардинга и за ускоряване на SQL:

• Ние не използваме ограничения на външен ключ, тъй като при шардинг идентификационният номер на обекта може да бъде разположен на друг сървър.
• Не използваме запомнени процедури и тригери поради допълнителното натоварване на процесора на СУБД.
• Ние не използваме JOIN поради всичко по-горе и много произволни четения от диск.
• Извън транзакция ние използваме нивото на изолация Read Uncommitted, за да намалим блокиранията.
• Ние изпълняваме само кратки транзакции (по-малко от 100ms средно).
• Ние не използваме многоредови UPDATE и DELETE поради голям брой блокирания - актуализираме само един запис наведнъж.
• Заявките винаги се изпълняват само от индекси - заявка с пълен план за сканиране на таблица означава за нас претоварване на базата данни и нейния отказ.

Тези стъпки ни позволиха да изстискаме почти максималната производителност от SQL сървърите. Проблемите обаче ставаха все повече. Нека да ги разгледаме.

Проблеми със SQL

• Тъй като използвахме самонаписано шардинг, добавянето на нови шардове се извършваше ръчно от администраторите. През цялото това време мащабируемите реплики на данни не са обслужвали заявки.
• Тъй като броят на записите в таблицата расте, скоростта на вмъкване и модифициране намалява, когато се добавят индекси към съществуваща таблица, скоростта пада многократно, създаването и повторното създаване на индекси отнема време на престой.
• Наличието на малко количество Windows за SQL Server в производство затруднява управлението на инфраструктурата

Но основният проблем е

отказоустойчивост

Класическият SQL Server има лоша толерантност към грешки. Да приемем, че имате само един сървър на база данни и той се проваля на всеки три години. По това време сайтът не работи за 20 минути, това е приемливо. Ако имате 64 сървъра, тогава сайтът спира веднъж на всеки три седмици. И ако имате 200 сървъра, тогава сайтът не работи всяка седмица. Това е проблем.

Какво може да се направи, за да се подобри устойчивостта на грешки на SQL сървъра? Уикипедия ни кани да строим клъстер с висока достъпност: където в случай на повреда на някой от компонентите има резервно копие.

Това изисква флот от скъпо оборудване: множество дублирани, оптични влакна, споделено съхранение и включването на резерва не работи надеждно: около 10% от включванията завършват с повреда на резервния възел с влак зад главния възел.

Но основният недостатък на такъв клъстер с висока достъпност е нулевата наличност в случай на повреда на центъра за данни, в който се намира. Odnoklassniki има четири центъра за данни и ние трябва да осигурим работа в един от тях в случай на пълна повреда.

За това може да се използва Multi Master репликация, вградена в SQL Server. Това решение е много по-скъпо поради цената на софтуера и страда от добре известни проблеми с репликацията - непредвидими забавяния на транзакциите при синхронна репликация и забавяния при прилагане на репликация (и в резултат на това загубени модификации) при асинхронна. подразбира се ръчно разрешаване на конфликти прави тази опция напълно неприложима за нас.

Всички тези проблеми изискваха кардинално решение и ние пристъпихме към техния подробен анализ. Тук трябва да се запознаем с това какво основно прави SQL Server – транзакциите.

Проста транзакция

Помислете за най-простата транзакция от гледна точка на приложен SQL програмист: добавяне на снимка към албум. Албумите и снимките се съхраняват в различни табели. Албумът има публичен брояч на снимки. След това такава транзакция се разделя на следните стъпки:

1. Блокираме албума по ключ.
2. Създайте запис в таблицата със снимки.
3. Ако снимката има публичен статус, тогава затваряме брояча на публичните снимки в албума, актуализираме записа и извършваме транзакцията.

Или в псевдокод:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

Виждаме, че най-често срещаният сценарий за бизнес транзакция е да се прочетат данни от базата данни в паметта на сървъра на приложения, да се промени нещо и да се запишат новите стойности обратно в базата данни. Обикновено при такава транзакция обновяваме няколко обекта, няколко таблици.

Когато се изпълнява транзакция, може да възникне едновременна модификация на същите данни от друга система. Например, Antispam може да реши, че потребителят е подозрителен по някакъв начин и следователно всички снимки на потребителя вече не трябва да бъдат публични, те трябва да бъдат изпратени за модериране, което означава промяна на photo.status на друга стойност и изключване на съответните броячи. Очевидно, ако тази операция ще се случи без гаранции за атомарност на приложението и изолиране на конкуриращи се модификации, както в ACID, тогава резултатът няма да бъде това, от което се нуждаете - или броячът на снимките ще покаже грешна стойност, или не всички снимки ще бъдат изпратени за модериране.

По време на съществуването на Odnoklassniki е написан много такъв код, който манипулира различни бизнес обекти в рамките на една транзакция. Според опита от миграцията към NoSQL с Последователност на събитията ние знаем, че най-голямото предизвикателство (и отнема много време) е необходимостта от разработване на код за поддържане на последователност на данните. Затова считаме, че основното изискване за новото хранилище е осигуряването на логиката на приложението на реални ACID транзакции.

Други също толкова важни изисквания бяха:

• В случай на повреда в центъра за данни трябва да има достъп както за четене, така и за запис в новото хранилище.
• Запазване на сегашната скорост на развитие. Тоест, когато работите с ново хранилище, количеството код трябва да бъде приблизително същото, не трябва да има нужда да добавяте нещо към хранилището, да разработвате алгоритми за разрешаване на конфликти, поддържане на вторични индекси и т.н.
• Скоростта на новото хранилище трябва да е достатъчно висока, както при четене на данни, така и при обработка на транзакции, което на практика означава, че академично строги, с общо предназначение, но бавни решения, като напр. двуфазови ангажименти.
• Автоматично мащабиране в движение.
• Използвайки обикновени евтини сървъри, без да е необходимо да купувате екзотични железа.
• Възможност за развитие на съхранение от разработчиците на компанията. С други думи, беше даден приоритет на патентовани решения или решения с отворен код, за предпочитане в Java.

Решения, решения

Анализирайки възможните решения, стигнахме до два възможни варианта на архитектура:

Първият е да вземете всеки SQL сървър и да приложите необходимата толерантност към грешки, механизъм за мащабиране, клъстериране при отказ, разрешаване на конфликти и разпределени, надеждни и бързи ACID транзакции. Ние оценихме тази опция като много нетривиална и отнемаща време.

Вторият вариант е да вземете готово NoSQL хранилище с внедрено мащабиране, failover clustering, разрешаване на конфликти и сами да внедрите транзакции и SQL. На пръв поглед дори задачата за внедряване на SQL, да не говорим за ACID транзакциите, изглежда като задача от години. Но тогава осъзнахме, че наборът от SQL функции, които използваме на практика, е толкова далеч от ANSI SQL Касандра CQL далеч от ANSI SQL. Разглеждайки по-отблизо CQL, разбрахме, че е достатъчно близо до това, от което се нуждаем.

Касандра и CQL

И така, какво е интересно за Касандра, какви характеристики има?

Първо, тук можете да създавате таблици с поддръжка на различни типове данни, можете да правите SELECT или UPDATE чрез първичен ключ.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

За да осигури съгласуваност на репликите на данните, Cassandra използва кворумен подход. В най-простия случай това означава, че при поставяне на три реплики на един и същи ред на различни възли на клъстера, записът се счита за успешен, ако по-голямата част от възлите (т.е. два от три) потвърдиха успеха на тази операция за запис. Данните от серия се считат за последователни, ако при четене повечето от възлите са анкетирани и са ги потвърдили. По този начин, ако има три реплики, пълната и незабавна съгласуваност на данните е гарантирана, ако един възел се повреди. Този подход ни позволи да приложим още по-надеждна схема: винаги изпращайте заявки до трите реплики, чакайки отговор от двете най-бързи. След това късният отговор на третата реплика се отхвърля. В същото време възел, който закъснява с отговор, може да има сериозни проблеми - спирачки, събиране на боклук в JVM, директно възстановяване на паметта в ядрото на linux, хардуерен срив, прекъсване на връзката с мрежата. Операциите и данните на клиента обаче не са засегнати по никакъв начин.

Извиква се подходът, когато имаме достъп до три възела и получаваме отговор от два спекулация: изпраща се заявка за допълнителни реплики, преди да "падне".

Друго предимство на Cassandra е Batchlog, механизъм, който гарантира, че промените, които правите, са напълно приложени или не напълно приложени към пакета. Това ни позволява да решим А в ACID - атомарност извън кутията.

Най-близкото нещо до транзакциите в Касандра е т.нар. "леки транзакции". Но те са далеч от „истински“ ACID транзакции: всъщност това е възможност да се направи CAS върху данните само на един запис, използвайки консенсуса на протокола за тежка категория Paxos. Следователно скоростта на такива транзакции е ниска.

Какво пропуснахме в Касандра

И така, трябваше да внедрим истински ACID транзакции в Cassandra. С помощта на които бихме могли лесно да внедрим две други удобни функции на класическата СУБД: последователни бързи индекси, които биха ни позволили да избираме данни не само чрез първичния ключ, и обичайния генератор на монотонни идентификатори с автоматично нарастване.

C*One

Така се роди новата СУБД C*One, състоящ се от три типа сървърни възли:

• Хранилищата са (почти) стандартни сървъри на Cassandra, отговорни за съхраняването на данни на локални дискове. С нарастването на натоварването и обема на данните техният брой може лесно да се увеличи до десетки и стотици.
• Транзакционни координатори – осигуряват изпълнението на транзакциите.
• Клиентите са сървъри на приложения, които изпълняват бизнес операции и инициират транзакции. Може да има хиляди такива клиенти.

Сървъри от всички видове са в общ клъстер, използват вътрешния протокол за съобщения на Cassandra, за да комуникират помежду си и клюка за обмен на клъстерна информация. С помощта на Heartbeat сървърите научават за взаимни повреди, поддържат единна схема на данни - таблици, тяхната структура и репликация; схема на разделяне, клъстерна топология и др.

Клиентите

Вместо стандартните драйвери се използва режим Fat Client. Такъв възел не съхранява данни, но може да действа като координатор за изпълнение на заявка, т.е. самият клиент действа като координатор на своите заявки: той проверява реплики за съхранение и разрешава конфликти. Това е не само по-надеждно и по-бързо от стандартния драйвер, който изисква комуникация с отдалечен координатор, но също така ви позволява да контролирате предаването на заявки. Извън транзакция, отворена на клиента, заявките се изпращат до хранилищата. Ако клиентът е отворил транзакция, тогава всички заявки в рамките на транзакцията се изпращат до координатора на транзакцията.

C*One Transaction Coordinator

Координаторът е това, което внедрихме за C*One от нулата. Той отговаря за управлението на транзакциите, заключванията и реда, в който се прилагат транзакциите.

За всяка обслужвана транзакция координаторът генерира времева марка: всяка следваща е по-голяма от тази на предишната транзакция. Тъй като системата за разрешаване на конфликти в Cassandra се основава на времеви клейма (на два конфликтни записа, последният времеви клеймо се счита за релевантен), конфликтът винаги ще бъде разрешен в полза на последващата транзакция. Така внедрихме часовник Lamport е евтин начин за разрешаване на конфликти в разпределена система.

Брави

За да осигурим изолация, решихме да използваме най-лесния начин - песимистични ключалки на първичния ключ на записа. С други думи, при транзакция записът трябва първо да бъде заключен, едва след това прочетен, модифициран и запазен. Само след успешно извършване на запис може да бъде отключен, така че конкурентните транзакции да могат да го използват.

Внедряването на такова заключване е лесно в неразпределена среда. В една разпределена система има два основни начина: или да се приложи разпределено заключване на клъстер, или да се разпределят транзакциите, така че транзакциите, включващи един и същи запис, винаги да се обслужват от един и същ координатор.

Тъй като в нашия случай данните вече са разпределени между групи от локални транзакции в SQL, беше решено да се присвоят групи от локални транзакции на координаторите: един координатор извършва всички транзакции с токен от 0 до 9, вторият - с токен от 10 до 19 и т.н. В резултат на това всеки от екземплярите на координатора става главен на групата транзакции.

Тогава заключванията могат да бъдат реализирани като банална HashMap в паметта на координатора.

Откази на координатори

Тъй като един координатор обслужва изключително група транзакции, е много важно бързо да се определи фактът на неговия неуспех, така че повторният опит за изпълнение на транзакцията да е в рамките на времето за изчакване. За да направим това бързо и надеждно, използвахме напълно свързан протокол за слушане на кворум:

Всеки център за данни хоства поне два координационни възела. Периодично всеки координатор изпраща сърдечно съобщение до другите координатори и ги информира за функционирането си, както и кога за последен път е получил сърдечно съобщение от кои координатори в клъстера.

Получавайки подобна информация от останалите като част от техните сърдечни съобщения, всеки координатор решава за себе си кои възли на клъстера функционират и кои не, ръководейки се от принципа на кворума: ако възел X получи информация от по-голямата част от възлите в клъстера за нормалното получаване на съобщения от възел Y, тогава , Y работи. Обратно, веднага щом мнозинството съобщи за липсващи съобщения от възел Y, тогава Y е неуспешно. Любопитно е, че ако кворумът каже на възел X, че не получава повече съобщения от него, тогава самият възел X ще се счита за неуспешен.

Сърдечните съобщения се изпращат с висока честота, около 20 пъти в секунда, с период от 50 ms. В Java е трудно да се гарантира отговор на приложението в рамките на 50 ms поради сравними времена на пауза, причинени от събирача на отпадъци. Успяхме да постигнем това време за реакция, използвайки G1 събирача на отпадъци, който ви позволява да посочите цел за продължителността на GC паузите. Въпреки това, понякога, доста рядко, паузите на колектора надхвърлят 50 ms, което може да доведе до фалшиво откриване на повреда. За да се избегне това, координаторът не съобщава за повреда на отдалечения възел, когато първото сърдечно съобщение от него е загубено, само ако липсват няколко подред.Така успяхме да открием повреда на координационния възел за 200 ms.

Но не е достатъчно бързо да разберете кой възел е престанал да функционира. Трябва да се направи нещо по въпроса.

Резервиране

Класическата схема предполага, че в случай на повреда на капитана да стартира избора на нов, използвайки един от модерен универсален алгоритми. Такива алгоритми обаче имат добре известни проблеми с конвергенцията във времето и продължителността на самия изборен процес. Успяхме да избегнем такива допълнителни забавяния, използвайки схемата за подмяна на координатор в напълно свързана мрежа:

Да приемем, че искаме да изпълним транзакция в група 50. Нека предварително дефинираме схема за заместване, тоест кои възли ще изпълнят транзакции от група 50 в случай на повреда на главния координатор. Нашата цел е да поддържаме системата работеща в случай на повреда в центъра за данни. Нека дефинираме, че първият резерв ще бъде възел от друг център за данни, а вторият резерв ще бъде възел от третия. Тази схема се избира веднъж и не се променя, докато топологията на клъстера не се промени, тоест докато в него не влязат нови възли (което се случва много рядко). Редът за избор на нов активен мастер в случай на повреда на стария винаги ще бъде следният: първият резерв ще стане активен мастер, а ако той е престанал да функционира, ще стане вторият резерв.

Такава схема е по-надеждна от универсален алгоритъм, тъй като за активиране на нов капитан е достатъчно да се определи фактът на повреда на стария.

Но как клиентите ще разберат кой от майсторите работи в момента? Невъзможно е да се изпрати информация до хиляди клиенти за 50 ms. Възможно е клиентът да изпрати заявка за отваряне на транзакция, без все още да знае, че този мастер вече не функционира и заявката ще остане в изчакване. За да не се случи това, клиентите спекулативно изпращат заявка за отваряне на транзакция към капитана на групата и двата й резерва наведнъж, но само този, който е активен капитан в момента, ще отговори на тази заявка. Цялата последваща комуникация в рамките на транзакцията ще се извършва от клиента само с активния мастер.

Главните резервни копия поставят получените заявки за транзакции, които не са техни, в опашката от неродени транзакции, където се съхраняват известно време. Ако активният мастер умре, новият главен обработва заявки за отваряне на транзакции от своята опашка и отговаря на клиента. Ако клиентът вече е отворил транзакция със стария мастер, тогава вторият отговор се игнорира (и, очевидно, такава транзакция няма да завърши и ще бъде повторена от клиента).

Как работи транзакцията

Да предположим, че клиентът е изпратил заявка до координатора за отваряне на транзакция за такъв и такъв обект с такъв и такъв първичен ключ. Координаторът заключва този обект и го поставя в таблицата за заключване в паметта. Ако е необходимо, координаторът чете този обект от хранилището и записва получените данни в транзакционно състояние в паметта на координатора.

Когато клиент иска да промени данните в транзакция, той изпраща заявка до координатора за промяна на обекта, а координаторът поставя новите данни в таблицата със състоянието на транзакцията в паметта. Това завършва записа - паметта не се записва.

Когато клиент поиска свои собствени модифицирани данни като част от активна транзакция, координаторът действа по следния начин:

• ако ID вече е в транзакцията, тогава данните се вземат от паметта;
• ако в паметта няма ID, тогава липсващите данни се четат от възлите за съхранение, комбинирани с тези, които вече са в паметта, и резултатът се връща на клиента.

По този начин клиентът може да прочете собствените си промени, а други клиенти не виждат тези промени, тъй като те се съхраняват само в паметта на координатора, те все още не са в възлите на Касандра.

Когато клиентът изпрати ангажимент, състоянието, което услугата е имала в паметта, се съхранява от координатора в регистриран пакет и се изпраща до магазините на Cassandra като регистриран пакет. Репозиториите правят всичко необходимо този пакет да бъде атомарно (напълно) приложен и връщат отговор на координатора, който освобождава ключалките и потвърждава успеха на транзакцията на клиента.

А за връщане назад координаторът трябва само да освободи паметта, заета от състоянието на транзакцията.

В резултат на подобренията, описани по-горе, ние внедрихме принципите на ACID:

• Атомност. Това е гаранция, че нито една транзакция няма да бъде частично фиксирана в системата, или всички нейни подоперации ще бъдат изпълнени, или нито една от тях няма да бъде изпълнена. В нашия случай този принцип се спазва поради регистрираната партида в Cassandra.
• Последователност. Всяка успешна транзакция, по дефиниция, ангажира само валидни резултати. Ако след отваряне на транзакция и извършване на някои от операциите се установи, че резултатът е невалиден, се извършва връщане назад.
• изолация. Когато се изпълнява транзакция, паралелните транзакции не трябва да влияят на нейния резултат. Едновременните транзакции са изолирани с песимистични ключалки на координатора. За четения извън транзакция се спазва принципът на изолация на ниво Read Committed.
• стабилност. Независимо от проблемите на по-ниските нива - затъмнение на системата, хардуерен срив - промените, направени от успешно завършена транзакция, трябва да останат запазени след възобновяване на функционирането.

Четене по индекси

Да вземем проста таблица:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

Има ID (първичен ключ), собственик и дата на промяна. Трябва да направите много проста заявка - изберете данни за собственика с датата на промяната "за последния ден".

SELECT *
WHERE owner=?
AND modified>?

За да обработите бързо такава заявка, в класическа SQL СУБД, трябва да изградите индекс върху колоните (собственик, модифициран). Можем да направим това съвсем просто, тъй като вече имаме гаранции от ACID!

Индекси в C*One

Има начална таблица със снимки, в която ID на записа е първичен ключ.

За индекс C*One създава нова таблица, която е копие на оригиналната таблица. Ключът е същият като индексния израз, но включва и първичния ключ на записа от изходната таблица:

Сега заявката за „собственик през последните XNUMX часа“ може да бъде пренаписана като избор от друга таблица:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

Съгласуваността на данните между снимките на изходната таблица и индекс i1 се поддържа автоматично от координатора. Въз основа само на схемата на данните, когато се получи промяна, координаторът генерира и запомня промяната не само на основната таблица, но и промените на копията. Не се извършват допълнителни действия с индексната таблица, регистрационните файлове не се четат, заключванията не се използват. Това означава, че добавянето на индекси почти не консумира ресурси и практически не влияе на скоростта на прилагане на модификации.

С помощта на ACID успяхме да внедрим индекси "като в SQL". Те са последователни, мащабируеми, бързи, композируеми и вградени в езика за заявки CQL. Поддръжката на индекс не изисква промени в кода на приложението. Всичко е просто, както в SQL. И най-важното е, че индексите не влияят на скоростта на изпълнение на модификациите на оригиналната таблица на транзакциите.

Какво стана

Разработихме C*One преди три години и го пуснахме в търговска експлоатация.

Какво завършихме? Нека да оценим това на примера на подсистема за обработка и съхранение на снимки, един от най-важните видове данни в социалната мрежа. Не става дума за телата на самите фотографии, а за всякакъв вид метаинформация. Сега в Odnoklassniki има около 20 милиарда такива записи, системата обработва 80 хиляди заявки за четене в секунда, до 8 хиляди ACID транзакции в секунда, свързани с модификация на данни.

Когато използвахме SQL с коефициент на репликация = 1 (но в RAID 10), мета-информацията за снимката се съхраняваше на силно наличен клъстер от 32 машини на Microsoft SQL Server (плюс 11 резервни). Също така бяха разпределени 10 сървъра за съхранение на резервни копия. Общо 50 скъпи коли. В същото време системата работи при номинално натоварване, без марж.

След мигриране към нова система получихме репликационен фактор = 3 - копие във всеки център за данни. Системата се състои от 63 Cassandra възли за съхранение и 6 координиращи машини, за общо 69 сървъра. Но тези машини са много по-евтини, общо около 30% от цената на SQL система. В този случай натоварването се поддържа на ниво от 30%.

С въвеждането на C*One забавянето също намаля: в SQL операцията за запис отне около 4,5 ms. В C * One - около 1,6 ms. Продължителността на една транзакция е средно по-малка от 40 ms, ангажиментът завършва за 2 ms, продължителността на четене и запис е средно 2 ms. 99-ият процентил е само 3-3,1 ms, броят на изчакванията е намалял със 100 пъти - всичко това се дължи на широкото използване на спекулации.

Към днешна дата повечето от възлите на SQL Server са изведени от експлоатация, новите продукти се разработват само с помощта на C * One. Адаптирахме C*One да работи в нашия облак еднооблачен, което направи възможно ускоряването на внедряването на нови клъстери, опростяването на конфигурацията и автоматизирането на работата. Без изходния код това би било много по-трудно и изтъркано.

Сега работим върху прехвърлянето на другите ни хранилища в облака - но това е съвсем различна история.

Източник: www.habr.com