NewSQL = NoSQL+ACID

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

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

Как работи и какво постигнахме — четете под катото.

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

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

Въпреки това всичко това са обикновени NoSQL клъстери, използвани за съхранение на слабо съгласувани данни. А ние искахме да заменим основното консистентно хранилище, Microsoft SQL Server, което е било използвано от самото създаване на „Одноклассники“. Хранилището се състоеше от повече от 300 машини с SQL Server Standard Edition, на които се съхраняваха 50 Тб данни — бизнес-същности. Тези данни се модифицират в рамките на ACID транзакции и изискват висока съгласуваност.

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

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

• Не използваме Foreign key constraints, тъй като при шардирването ID на единицата може да се намира на друг сървър.
• Не използваме храними процедури и тригери поради допълнителната натовареност на CPU на СУБД.
• Не използваме JOINs поради всичко изброено по-горе и множество случайни четения от диска.
• Извън транзакцията, за намаляване на взаимоблокировките, използваме ниво на изолация Read Uncommitted.
• Изпълняваме само кратки транзакции (в средно по-кратки от 100 мс).
• Не използваме многоредови UPDATE и DELETE поради голямото количество взаимоблокировки — обновяваме само по една запис.
• Запитванията винаги изпълняваме само по индекси — запитване с план за пълно преглеждане на таблицата за нас означава претоварване на БД и отказ от нея.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TX.commit();

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

При изпълнението на транзакция може да се случи конкурентно модифициране на същите данни от друга система. Например, Антиспамът може да реши, че потребителят е подозрителен и следователно всички снимки на потребителя не трябва да бъдат публични, трябва да бъдат изпратени на модерация, а това означава да се промени photo.status на някаква друга стойност и да се коригират съответните броячи. Ясно е, че ако тази операция се извършва без гаранции за атомарност и изолация на конкуриращи модификации, както в ACID, резултатът няма да бъде това, което е необходимо — или броячът на снимките ще показва неправилна стойност, или не всички снимки ще бъдат изпратени на модерация.

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

Други, не по-малко важни, изисквания бяха:

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

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

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

Първият — да вземем произволен SQL сървър и да реализираме необходимата устойчивост на откази, механизъм за скалиране, устойчив клъстер, разрешаване на конфликти и разпределени, надеждни и бързи ACID транзакции. Оценихме този вариант като доста нетривиален и трудоемък.

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

Cassandra и CQL

И така, какво е интересно в Cassandra, какви възможности предлага?

На първо място, тук може да се създават таблици с поддръжка на различни типове данни, може да се прави 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 — механизъм, който гарантира или пълното прилагане, или пълното неизпълнение на пакета от изменения, които правите. Това ни позволява да решим A в ACID — атомарност по подразбиране.

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

Какво ни липсваше в Cassandra

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

C*One

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

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

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

Клиенти

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

Координатор на транзакции C*One

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

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

Блокировки

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

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

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

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

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

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

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

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

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

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

Резервиране

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

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

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

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

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

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

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

Когато клиентът иска да промени данни в транзакцията, той изпраща на координатора заявка за модификация на единицата, а той поставя новите данни в таблицата за състояние на транзакциите в паметта. На този етап записът приключва — запис в хранилището не се извършва.

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

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

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

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

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

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

• Атомарност. Това е гаранция, че нито една транзакция няма да бъде фиксирана в системата частично, всички нейни подоперации ще бъдат или извършени, или нито една няма да бъде извършена. При нас този принцип се спазва благодарение на logged batch в Cassandra.
• Съгласуваност. Всяка успешна транзакция по определение фиксира само допустими резултати. Ако след отварянето на транзакцията и извършването на част от операциите се установи, че резултатът е недопустим, се извършва обратното действие.
• Изолираност. При извършване на транзакция паралелни транзакции не трябва да влияят на нейния резултат. Съперничещите транзакции са изолирани с помощта на песимистични блокировки на координатора. За четене извън транзакцията се спазва принципа на изолираност на ниво Read Committed.
• Устойчивост. Независимо от проблемите на по-ниските нива — прекъсване на системата, провал на оборудването — промените, направени от успешно завършена транзакция, трябва да останат запазени след възобновяване на функционирането.

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

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

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

Тя има ID (първичен ключ), собственик и дата на промяна. Необходимо е да се направи много прост запитване — да се изберат данните по собственик с дата на промяна „за последните 24 часа.“

SELECT *
WHERE owner=?
AND modified>?

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

Индекси в C*One

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

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

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

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

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

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

Какво постигнахме

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

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

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

След мигрирането към новата система получихме replication factor = 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 да работи в нашето облако. one-cloud, което позволи да ускорим разгръщането на нови клъстери, да опростим конфигурацията и да автоматизираме експлоатацията. Без изходния код щеше да бъде значително по-сложно и хромаво.

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

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