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:

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

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

Проблеми с SQL

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

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

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

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

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

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

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

За това можеше да се приложи 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();

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

При изпълнението на транзакция може да се случи конкурентно модифициране на същите данни от друга система. Например, Антиспам може да реши, че потребителят е подозрителен и затова всички снимки на потребителя вече не трябва да са публични, те трябва да бъдат изпратени за модерация, а това означава да се промени 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 kernel, повреда на хардуера или загуба на мрежа. Въпреки това, това не влияе по никакъв начин на операциите на клиента и на данните.

Подходът, когато се обръщаме към трите нода и получаваме отговор от двата, се нарича спекулация: заявката за излишни реплики се изпраща преди да „отпадне“.

Още едно от предимствата на Cassandra е Batchlog — механизъм, който гарантира или пълното приложение, или пълното неприлагане на пакет от вашите промени. Това ни позволява да решим A в ACID — атомарност от кутия.

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

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

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

C*One

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

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

Сървърите от всички типове са част от общ клъстер, използват вътрешен протокол за съобщения Cassandra за комуникация помежду си и госип за обмен на информация в клъстера. С помощта на 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 мс. В Java е трудно да се гарантира отзивчивост на приложението в рамките на 50 мс, заради сравнимата продължителност на паузите, причинени от garbage collector. Успяхме да постигнем такава отзивчивост, използвайки G1 garbage collector, който позволява задаване на цел за продължителността на паузите от GC. Въпреки това, понякога, доста рядко, паузите на сглобителя надвишават 50 мс, което може да доведе до фалшиво откритие на отказ. За да се избегне това, координаторът не съобщава за отказ на отдалечен възел при загубата на първото heartbeat съобщение от него, а само ако изгуби няколко последователни. Така успяхме да постигнем откритие на отказа на координатор възела за 200 мс.

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

Резервиране

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

Да приемем, че искаме да извършим транзакция в група 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 с фактор на репликация = 1 (но в RAID 10), метаинформацията за снимките се съхраняваше на високо достъпен кластер от 32 машини с Microsoft SQL Server (плюс 11 резервни). Също така бяха отделени 10 сървъра за съхранение на резервни копия. Общо 50 скъпи машини. При това системата работеше на номинална натовареност, без резерв.

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

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

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

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

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