NewSQL = NoSQL+ACID

Однокласници до неодамна складираше околу 50 TB податоци обработени во реално време во SQL Server. За таков волумен, речиси е невозможно да се обезбеди брз и сигурен, па дури и толерантен пристап до неуспех на центарот за податоци користејќи SQL DBMS. Вообичаено, во такви случаи, се користи едно од складиштата на NoSQL, но не може сè да се пренесе на NoSQL: некои ентитети бараат гаранции за трансакцијата на ACID.

Ова нè доведе до употреба на NewSQL складирање, односно DBMS што обезбедува толеранција на грешки, приспособливост и перформанси на NoSQL системите, но во исто време одржувајќи ги гаранциите за ACID познати на класичните системи. Има малку работни индустриски системи од оваа нова класа, па ние самите имплементиравме таков систем и го ставивме во комерцијална работа.

Како функционира и што се случи - прочитајте под резот.

Денес, месечната публика на Однокласници е повеќе од 70 милиони уникатни посетители. Ние Ние сме во првите пет најголемите социјални мрежи во светот и меѓу дваесетте сајтови на кои корисниците поминуваат најмногу време. ОК инфраструктурата се справува со многу високи оптоварувања: повеќе од милион HTTP барања/сек по фронт. Делови од флота на сервери од повеќе од 8000 парчиња се наоѓаат блиску еден до друг - во четири центри за податоци во Москва, што овозможува да се обезбеди мрежна латентност помала од 1 ms меѓу нив.

Касандра ја користиме од 2010 година, почнувајќи од верзијата 0.6. Денес постојат неколку десетици кластери во функција. Најбрзиот кластер обработува повеќе од 4 милиони операции во секунда, а најголемите складираат 260 ТБ.

Сепак, сите овие се обични NoSQL кластери кои се користат за складирање слабо координирана податоци. Сакавме да го замениме главното доследно складирање, Microsoft SQL Server, кој се користи од основањето на Однокласници. Складирањето се состоеше од повеќе од 300 SQL Server Standard Edition машини, кои содржеа 50 TB податоци - деловни субјекти. Овие податоци се изменети како дел од ACID трансакциите и бараат висока конзистентност.

За да дистрибуираме податоци низ јазлите на SQL Server, користевме и вертикални и хоризонтални преградување (парчење). Историски гледано, користевме едноставна шема за споделување податоци: секој ентитет беше поврзан со токен - функција на ID на ентитетот. Ентитети со ист токен беа поставени на истиот SQL сервер. Односот господар-детаљ беше имплементиран така што токените на главната и на детската записа секогаш се совпаѓаа и се наоѓаа на истиот сервер. Во социјалната мрежа, речиси сите записи се генерираат во име на корисникот - што значи дека сите кориснички податоци во рамките на еден функционален потсистем се складираат на еден сервер. Односно, деловната трансакција речиси секогаш вклучува табели од еден SQL сервер, што овозможи да се обезбеди конзистентност на податоците користејќи локални трансакции со ACID, без потреба од користење бавно и несигурно дистрибуирани ACID трансакции.

Благодарение на споделувањето и забрзувањето на SQL:

• Не користиме ограничувања за странски клучеви, бидејќи при споделување, ID на ентитетот може да се наоѓа на друг сервер.
• Не користиме складирани процедури и предизвикувачи поради дополнителното оптоварување на процесорот на DBMS.
• Не користиме JOIN поради сето горенаведено и многу случајни читања од дискот.
• Надвор од трансакцијата, го користиме нивото на изолација Read Uncommitted за да ги намалиме ќор-сокакот.
• Вршиме само кратки трансакции (во просек пократки од 100 ms).
• Не користиме Ажурирање и БРИШЕЊЕ со повеќе редови поради големиот број ќор-сокак - ажурираме само еден запис одеднаш.
• Секогаш извршуваме барања само на индекси - барањето со план за целосна скенирање на табелата за нас значи преоптоварување на базата на податоци и нејзино неуспех.

Овие чекори ни овозможија да ги притиснеме речиси максималните перформанси од SQL серверите. Меѓутоа, проблемите стануваа се побројни. Ајде да ги погледнеме.

Проблеми со SQL

• Со оглед на тоа што користевме самостојно напишано сечење, додавањето нови парчиња беше направено рачно од администраторите. Сето ова време, скалабилните реплики на податоци не ги сервисираа барањата.
• Како што расте бројот на записи во табелата, брзината на вметнување и модификација се намалува кога се додаваат индекси на постоечка табела, брзината се намалува за еден фактор и повторното креирање на индексите се случува со застој;
• Имањето мала количина на Windows за SQL Server во производството го отежнува управувањето со инфраструктурата

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

толеранција на грешки

Класичниот SQL сервер има слаба толеранција на грешки. Да речеме дека имате само еден сервер за бази на податоци и тој откажува еднаш на секои три години. За тоа време, страницата е во прекин 20 минути, што е прифатливо. Ако имате 64 сервери, тогаш страницата не работи еднаш на секои три недели. И ако имате 200 сервери, тогаш страницата не работи секоја недела. Ова е проблем.

Што може да се направи за да се подобри толеранцијата на грешки на SQL серверот? Википедија не поканува да градиме високо достапен кластер: каде што во случај на дефект на некоја од компонентите има резервна.

Ова бара флота од скапа опрема: бројни дупликации, оптички влакна, заедничко складирање и вклучувањето на резерва не функционира сигурно: околу 10% од префрлувањата завршуваат со откажување на резервниот јазол како воз зад главниот јазол.

Но, главниот недостаток на таков високо достапен кластер е нулта достапност ако центарот за податоци во кој се наоѓа не успее. Однокласници има четири центри за податоци и треба да обезбедиме работа во случај на целосен дефект во еден од нив.

За ова би можеле да искористиме Мулти-мајстор репликација вградена во 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();

Гледаме дека најчестото сценарио за деловна трансакција е читање податоци од базата на податоци во меморијата на серверот за апликации, промена на нешто и зачувување на новите вредности назад во базата на податоци. Обично во таква трансакција ажурираме неколку ентитети, неколку табели.

При извршување на трансакција, може да дојде до истовремена модификација на истите податоци од друг систем. На пример, Антиспам може да одлучи дека корисникот е некако сомнителен и затоа сите фотографии на корисникот повеќе не треба да бидат јавни, тие треба да се испраќаат на умереност, што значи промена на статусот на фото.статусот на некоја друга вредност и исклучување на соодветните бројачи. Очигледно, ако оваа операција се случи без гаранции за атомичноста на примената и изолацијата на конкурентните модификации, како во Киселина, тогаш резултатот нема да биде она што е потребно - или бројачот за фотографии ќе покаже погрешна вредност, или сите фотографии нема да бидат испратени на умереност.

Многу слични кодови, манипулации со различни деловни субјекти во една трансакција, се напишани низ целото постоење на Однокласници. Врз основа на искуството од миграциите на NoSQL од Евентуална конзистентност Знаеме дека најголемиот предизвик (и инвестиција во време) доаѓа од развивање код за одржување на конзистентноста на податоците. Затоа, сметавме дека главниот услов за новото складирање е обезбедување на реални ACID трансакции за апликативна логика.

Други, не помалку важни, барања беа:

• Ако центарот за податоци не успее, мора да бидат достапни и читањето и пишувањето во новата меморија.
• Одржување на моменталната брзина на развој. Односно, кога работите со ново складиште, количината на код треба да биде приближно иста, не треба да има потреба да се додава ништо во складиштето, да се развиваат алгоритми за решавање на конфликти, одржување на секундарни индекси итн.
• Брзината на новото складирање мораше да биде доста висока, и при читање податоци и при обработка на трансакции, што ефективно значеше дека академски ригорозни, универзални, но бавни решенија, како на пример, не се применливи двофазни обврзувања.
• Автоматско скалирање во лет.
• Користење на редовни евтини сервери, без потреба од купување егзотичен хардвер.
• Можност за развој на складиште од страна на развивачите на компанијата. Со други зборови, приоритет беше даден на сопственички или решенија со отворен код, по можност во Java.

Одлуки, одлуки

Анализирајќи ги можните решенија, дојдовме до два можни избора за архитектура:

Првиот е да се земе кој било SQL сервер и да се имплементира потребната толеранција на грешки, механизмот за скалирање, кластерот за фајловер, разрешување конфликти и дистрибуирани, сигурни и брзи трансакции со ACID. Ја оценивме оваа опција како многу нетривијална и трудоинтензивна.

Втората опција е да земете готово складирање NoSQL со имплементирано скалирање, кластер за фајловер, разрешување конфликти и сами да имплементирате трансакции и 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=?;

За да обезбеди конзистентност на податоците на репликата, Касандра користи кворумски пристап. Во наједноставниот случај, тоа значи дека кога три реплики од истиот ред се поставени на различни јазли од кластерот, запишувањето се смета за успешно ако поголемиот дел од јазлите (односно, два од три) го потврдиле успехот на оваа операција за запишување. . Податоците од редовите се сметаат за конзистентни ако, при читањето, повеќето јазли биле анкетирани и потврдени. Така, со три реплики, се гарантира целосна и инстант конзистентност на податоците ако еден јазол не успее. Овој пристап ни овозможи да спроведеме уште посигурна шема: секогаш испраќајте барања до сите три реплики, чекајќи одговор од двете најбрзи. Доцниот одговор на третата реплика е отфрлен во овој случај. Јазолот што доцни во одговарањето може да има сериозни проблеми - сопирачки, собирање ѓубре во JVM, директно враќање на меморијата во кернелот на Linux, дефект на хардверот, исклучување од мрежата. Сепак, ова не влијае на работењето или податоците на клиентот на кој било начин.

Пристапот кога контактираме со три јазли и добиваме одговор од два се нарекува шпекулации: барање за дополнителни реплики се испраќа дури и пред да „падне“.

Друга придобивка на Касандра е Batchlog, механизам кој гарантира дека серијата промени што ги правите се или целосно применети или воопшто не се применуваат. Ова ни овозможува да го решиме А во КИСЕЛИНА - атомичноста надвор од кутијата.

Најблиску до трансакциите во Касандра се т.н.лесни трансакции“. Но, тие се далеку од „вистински“ трансакции со АЦИД: всушност, ова е можност да се направи CAS на податоци од само еден запис, користејќи консензус користејќи го тешкиот протокол Паксос. Затоа, брзината на таквите трансакции е мала.

Она што ни недостасуваше во Касандра

Значи, моравме да спроведеме вистински ACID трансакции во Касандра. Користејќи го тоа, лесно можевме да имплементираме две други погодни карактеристики на класичните DBMS: конзистентни брзи индекси, кои ќе ни овозможат да вршиме избор на податоци не само со примарниот клуч, и редовен генератор на монотони идентификатори со автоматско зголемување.

C * Еден

Така се роди нов DBMS C * Еден, кој се состои од три типа серверски јазли:

• Складирање – (речиси) стандардни Cassandra сервери одговорни за складирање податоци на локални дискови. Како што расте оптоварувањето и обемот на податоци, нивната количина може лесно да се зголеми на десетици и стотици.
• Координатори на трансакции - обезбедуваат извршување на трансакциите.
• Клиентите се апликациски сервери кои спроведуваат деловни операции и иницираат трансакции. Може да има илјадници такви клиенти.

Серверите од сите типови се дел од заеднички кластер, користете го внатрешниот протокол за пораки Касандра за да комуницираат едни со други и озборувања за размена на информации за кластерот. Со Heartbeat, серверите учат за меѓусебните неуспеси, одржуваат единствена шема на податоци - табели, нивната структура и репликација; шема за партиционирање, топологија на кластери итн.

Клиенти

Наместо стандардни драјвери, се користи режимот Fat Client. Таквиот јазол не складира податоци, но може да дејствува како координатор за извршување на барањата, односно самиот Клиент делува како координатор на неговите барања: бара реплики за складирање и решава конфликти. Ова не само што е посигурно и побрзо од стандардниот двигател, кој бара комуникација со далечински координатор, туку исто така ви овозможува да го контролирате преносот на барањата. Надвор од трансакцијата отворена за клиентот, барањата се испраќаат до складиштата. Доколку клиентот отворил трансакција, тогаш сите барања во рамките на трансакцијата се испраќаат до координаторот на трансакцијата.

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

Координаторот е нешто што го имплементиравме за C*One од нула. Тој е одговорен за управување со трансакциите, бравите и редоследот по кој се применуваат трансакциите.

За секоја сервисирана трансакција, координаторот генерира временска ознака: секоја следна трансакција е поголема од претходната трансакција. Бидејќи системот за решавање конфликти на Касандра се заснова на временски печати (од два конфликтни записи, оној со најновиот временски печат се смета за актуелен), конфликтот секогаш ќе се решава во корист на следната трансакција. Така имплементиравме Часовник Лампорт - евтин начин за решавање на конфликти во дистрибуиран систем.

Брави

За да обезбедиме изолација, решивме да го користиме наједноставниот метод - песимистички брави врз основа на примарниот клуч на записот. Со други зборови, во трансакцијата, записот мора прво да се заклучи, дури потоа да се прочита, измени и зачува. Само по успешно извршување може да се отклучи записот за да можат да го користат конкурентните трансакции.

Спроведувањето на таквото заклучување е едноставно во недистрибуирана средина. Во дистрибуираниот систем, постојат две главни опции: или да се имплементира дистрибуираното заклучување на кластерот или да се дистрибуираат трансакции така што трансакциите што вклучуваат ист запис секогаш да се сервисираат од истиот координатор.

Бидејќи во нашиот случај податоците се веќе дистрибуирани меѓу групи локални трансакции во SQL, беше одлучено да се доделат локални групи на трансакции на координаторите: еден координатор ги извршува сите трансакции со токени од 0 до 9, вториот - со токени од 10 до 19, и така натаму. Како резултат на тоа, секој од координаторските примероци станува господар на трансакциската група.

Тогаш бравите може да се имплементираат во форма на банален HashMap во меморијата на координаторот.

Неуспеси на координаторите

Бидејќи еден координатор исклучиво опслужува група на трансакции, многу е важно брзо да се утврди фактот на неговиот неуспех, така што вториот обид за извршување на трансакцијата ќе истече. За да го направиме ова брзо и сигурно, користевме целосно поврзан протокол за кворумски отчукувања на срцето:

Секој центар за податоци е домаќин на најмалку два координаторски јазли. Периодично, секој координатор испраќа порака за отчукување на срцето на другите координатори и ги информира за неговото функционирање, како и кои пораки за отчукување на срцето ги добил од кои координатори во кластерот последен пат.

Добивајќи слични информации од други како дел од пораките за чукање на срцето, секој координатор сам одлучува кои јазли на кластерот функционираат, а кои не функционираат, водејќи се од принципот на кворум: ако јазолот X добил информации од мнозинството јазли во кластерот за нормалното. примањето пораки од јазолот Y, потоа, Y работи. И обратно, штом мнозинството пријави дека недостасуваат пораки од јазолот Y, тогаш Y одби. Интересно е дека ако кворумот го информира јазолот X дека повеќе не прима пораки од него, тогаш самиот јазол X ќе смета дека не успеал.

Пораките за отчукување на срцето се испраќаат со висока фреквенција, околу 20 пати во секунда, со период од 50 ms. Во Java, тешко е да се гарантира одговор на апликацијата во рок од 50 ms поради споредливата должина на паузите предизвикани од собирачот на ѓубре. Можевме да го постигнеме ова време на одговор користејќи го собирачот на ѓубре G1, кој ни овозможува да одредиме цел за времетраењето на GC паузите. Меѓутоа, понекогаш, доста ретко, паузите на колекторот надминуваат 50 ms, што може да доведе до лажно откривање на дефекти. За да се спречи тоа да се случи, координаторот не известува за дефект на далечинскиот јазол кога ќе исчезне првата порака за отчукување на срцето од него, само ако неколку исчезнале по ред Госпоѓица.

Но, не е доволно брзо да се разбере кој јазол престанал да функционира. Треба да направиме нешто околу ова.

Резервација

Класичната шема вклучува, во случај на главниот неуспех, започнување на нови избори користејќи еден од модерен универзална алгоритми. Сепак, ваквите алгоритми имаат добро познати проблеми со временската конвергенција и должината на самиот изборен процес. Можевме да избегнеме такви дополнителни одложувања користејќи шема за замена на координаторот во целосно поврзана мрежа:

Да речеме дека сакаме да извршиме трансакција во групата 50. Ајде однапред да ја одредиме шемата за замена, односно кои јазли ќе ги извршуваат трансакциите во групата 50 во случај на неуспех на главниот координатор. Нашата цел е да ја одржиме функционалноста на системот во случај на дефект на центарот за податоци. Да утврдиме дека првата резерва ќе биде јазол од друг центар за податоци, а втората резерва ќе биде јазол од трет. Оваа шема се избира еднаш и не се менува додека не се промени топологијата на кластерот, односно додека не влезат нови јазли (што се случува многу ретко). Постапката за избор на нов активен господар ако стариот не успее секогаш ќе биде следна: првата резерва ќе стане активен господар, а ако престанала да функционира, втората резерва ќе стане активен господар.

Оваа шема е посигурна од универзалниот алгоритам, бидејќи за да се активира нов господар доволно е да се утврди неуспехот на стариот.

Но, како клиентите ќе разберат кој господар работи сега? Невозможно е да се испратат информации до илјадници клиенти за 50 ms. Можна е ситуација кога клиентот испраќа барање за отворање трансакција, сè уште не знаејќи дека овој господар повеќе не функционира и барањето ќе истече. За да се спречи тоа да се случи, клиентите шпекулативно испраќаат барање за отворање трансакција до групниот господар и двете негови резерви одеднаш, но само оној кој е активен господар во моментот ќе одговори на ова барање. Целата следна комуникација во рамките на трансакцијата клиентот ќе ја врши само со активниот господар.

Резервните мајстори ги ставаат примените барања за трансакции кои не се нивни во редот на неродени трансакции, каде што се чуваат некое време. Ако активниот господар умре, новиот господар ги обработува барањата за отворање трансакции од неговата редица и одговара на клиентот. Ако клиентот веќе отворил трансакција со стариот господар, тогаш вториот одговор се игнорира (и, очигледно, таквата трансакција нема да заврши и ќе се повтори од клиентот).

Како функционира трансакцијата

Да речеме, клиентот испратил барање до координаторот да отвори трансакција за таков и таков ентитет со таков и таков примарен клуч. Координаторот го заклучува овој ентитет и го става во табелата за заклучување во меморијата. Доколку е потребно, координаторот го чита овој ентитет од складиштето и ги складира добиените податоци во состојба на трансакција во меморијата на координаторот.

Кога клиентот сака да промени податоци во трансакцијата, тој испраќа барање до координаторот да го измени ентитетот, а координаторот ги става новите податоци во табелата за статус на трансакцијата во меморијата. Ова го комплетира снимањето - не се прави снимање во складиштето.

Кога клиентот бара свои променети податоци како дел од активна трансакција, координаторот постапува на следниов начин:

• ако ID е веќе во трансакцијата, тогаш податоците се земаат од меморијата;
• ако нема ID во меморијата, тогаш податоците што недостасуваат се читаат од јазлите за складирање, комбинирани со оние кои се веќе во меморијата и резултатот се дава на клиентот.

Така, клиентот може да ги чита сопствените промени, но другите клиенти не ги гледаат овие промени, бидејќи тие се зачувани само во меморијата на координаторот, тие сè уште не се во јазлите на Касандра.

Кога клиентот испраќа commit, состојбата што била во меморијата на услугата ја зачувува координаторот во најавена серија и се испраќа како евидентирана серија во складиштето на Касандра. Продавниците прават се што е потребно за да се осигураат дека овој пакет е атомски (целосно) применет и враќаат одговор до координаторот, кој ги ослободува бравите и му ја потврдува успешноста на трансакцијата на клиентот.

И за да се врати назад, координаторот треба само да ја ослободи меморијата окупирана од состојбата на трансакцијата.

Како резултат на горенаведените подобрувања, ги имплементиравме ACID принципите:

• Атомичност. Ова е гаранција дека ниту една трансакција нема да биде делумно евидентирана во системот или ќе бидат завршени сите негови подоперации, или ниту една нема да биде завршена. Ние се придржуваме до овој принцип преку најавена серија во Касандра.
• Конзистентност. Секоја успешна трансакција, по дефиниција, евидентира само валидни резултати. Доколку по отворањето на трансакцијата и извршувањето на дел од операциите се открие дека резултатот е неважечки, се врши враќање назад.
• Изолација. Кога трансакцијата се извршува, истовремените трансакции не треба да влијаат на нејзиниот исход. Конкурентните трансакции се изолирани користејќи песимистички брави на координаторот. За читања надвор од трансакција, принципот на изолација се почитува на ниво на Read Committed.
• Стабилност. Без оглед на проблемите на пониските нивоа - затемнување на системот, дефект на хардверот - промените направени од успешно завршената трансакција треба да останат зачувани кога ќе продолжат операциите.

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

Да земеме едноставна табела:

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

Има ID (примарен клуч), сопственик и датум на измена. Треба да направите многу едноставно барање - изберете податоци за сопственикот со датумот на промена „за последниот ден“.

SELECT *
WHERE owner=?
AND modified>?

За да може брзо да се обработи таквото барање, во класичен SQL DBMS треба да изградите индекс по колони (сопственик, изменет). Ова можеме да го направиме многу лесно, бидејќи сега имаме гаранции за КИСИД!

Индекси во C*One

Постои изворна табела со фотографии во кои ID на записот е примарен клуч.

За индекс, C*One создава нова табела која е копија од оригиналот. Клучот е ист како изразот на индексот, а го вклучува и примарниот клуч на записот од изворната табела:

Сега барањето за „сопственик за последниот ден“ може да се препише како избор од друга табела:

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

Конзистентноста на податоците во фотографиите од изворната табела и индексната табела 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 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