Преглед на CockroachDB: Увеличена SQL база данни, създадена за оцеляване

До съвсем наскоро, когато пазарувахте за база данни, трябваше да изберете: Мащабируемост или последователност? Базите данни на SQL като MySQL гарантират силна последователност, но не се мащабират добре хоризонтално. (Ръчното оцветяване за мащабируемост не е ничия идея за забавление.) Базите данни NoSQL като MongoDB се мащабират красиво, но предлагат само евентуална последователност. („Изчакайте достатъчно дълго и можете да прочетете верния отговор“ - което не е начин за извършване на финансови транзакции.)

Google Cloud Spanner, напълно управлявана услуга за релационни бази данни, работеща на Google Compute Engine (GCE), пусната през февруари 2017 г., има мащабируемост на базите данни NoSQL, като същевременно запазва съвместимостта на SQL, релационни схеми, ACID транзакции и силна външна последователност Spanner е изострена, глобално разпределена и репликирана релационна база данни, която използва алгоритъм на Paxos за постигане на консенсус между своите възли.

Една алтернатива на Spanner и предмет на този преглед е CockroachDB, хоризонтално мащабируема разпределена SQL база данни с отворен код, разработена от бивши служители на Google, които са били запознати със Spanner. CockroachDB взема назаем от Google Spanner за дизайна на своята система за съхранение на данни и използва алгоритъм Raft за постигане на консенсус между своите възли.

Подобно на Cloud Spanner, CockroachDB е разпределена SQL база данни, изградена върху транзакционно и последователно хранилище ключ-стойност, в случая на CockroachDB на RocksDB. Основните цели за проектиране на CockroachDB са поддръжка на ACID транзакции, хоризонтална мащабируемост и (най-вече) оцеляване, откъдето идва и името.

CockroachDB е проектиран да преживява откази на дискове, машини, стелажи и дори центрове за данни с минимално прекъсване на латентността и без ръчна намеса. Разбира се, за да постигнете това, трябва да стартирате клъстер от много екземпляри на симетричните възли на CockroachDB, като използвате множество дискове, машини, стелажи и центрове за данни.

За разлика от Cloud Spanner, който използва TrueTime API, наличен за синхронизиране на времето в центровете за данни на Google, CockroachDB не може да разчита на наличието на атомни часовници и GPS сателитни часовници, за да синхронизира точно времето между възлите и центровете за данни. Това има редица последици. Като начало Google TrueTime дава горна граница за отмествания на часовника между възлите в клъстер от седем милисекунди. Това е достатъчно малко, че възелът на Spanner просто изчаква седем милисекунди след запис, преди да докладва, че транзакцията е извършила, за да гарантира външна последователност.

Без TrueTime или подобно съоръжение CockroachDB трябва да се върне към NTP, което дава горни граници на синхронизацията на часовника между 100 милисекунди и 250 милисекунди. Като се има предвид по-големият времеви прозорец, CockroachDB не чака след записване. Вместо това понякога изчаква преди четене, като основно рестартира транзакция, ако чете стойност с времеви клеймо, по-голямо от началото на транзакцията, отново, за да гарантира последователност.

Когато всички възли в клъстера CockroachDB имат малките горни граници за отмествания на часовника, които можете да получите от GPS или атомни часовници, което е нещо, което току-що става достъпно за големите публични облаци, може да има смисъл да ги стартирате с --linearizable флага. Това ги кара да чакат максималното отместване на часовника, преди да върнат успешен ангажимент, точно както Spanner.

Как работи CockroachDB

Всеки възел CockroachDB се състои от пет слоя:

  • SQL, който превежда клиентските SQL заявки в операции ключ-стойност
  • Транзакция, която позволява атомни промени на множество записи ключ-стойност
  • Разпределение, което представя репликирани диапазони ключ-стойност като едно цяло
  • Репликация, която последователно и синхронно репликира диапазони ключ-стойност в много възли и позволява последователно четене чрез наеми
  • Хранилище, което записва и чете данни на ключ-стойност на диска

SQL слоят анализира заявките спрямо файл Yacc и ги превръща в абстрактно синтаксисно дърво. От абстрактното дърво на синтаксиса CockroachDB генерира дърво от възлови планове, които съдържат код ключ-стойност. Тогава възлите на плана се изпълняват, комуникирайки със слоя на транзакциите.

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

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

Репликационният слой копира данни между възлите и осигурява съгласуваност между тези копия чрез внедряване на консенсусен алгоритъм на Raft. Можете да контролирате фактора на репликация на ниво клъстер, база данни и таблица, като използвате зони за репликация. Консенсусният алгоритъм се използва само за записи и изисква кворумът на репликите да се съгласи за всички промени в диапазон, преди тези промени да бъдат ангажирани.

Слоят за съхранение съхранява данни като двойки ключ-стойност на диска с помощта на RocksDB. CockroachDB разчита силно на многоверсионния контрол на паралелността (MVCC), за да обработва едновременни заявки и да гарантира последователност. Голяма част от тази работа се извършва чрез използване на клеймове за хибриден логически часовник (HLC).

Подобно на Spanner, CockroachDB поддържа заявки за пътуване във времето (разрешено от MVCC). Те могат да се върнат до най-новото събиране на боклук в базата данни, извършвано по подразбиране ежедневно.

Инсталиране и използване на CockroachDB

CockroachDB работи на операционни системи Mac, Linux и Windows, поне за разработка и тестване. Базите данни за производство на таракани обикновено се изпълняват на виртуални машини на Linux или на организирани контейнери, често хоствани на публични облаци в множество центрове за данни. Бинарният файл на Windows на CockroachDB все още е в бета фаза и не се препоръчва за производство, а Apple вече не прави сървърния хардуер.

Хлебарски лаборатории

Както можете да видите на екранната снимка по-горе, има четири опции за инсталиране на CockroachDB на Mac. Избрах Homebrew като вероятно най-лесният от четирите.

Между другото, Cockroach Labs публикува предупреждение на сайта, в което се казва, че стартирането на приложение с състояние като CockroachDB в Docker е сложно, не се препоръчва за производствени внедрявания и вместо това да се използва инструмент за оркестрация като Kubernetes или Docker Swarm. Ще обсъдя възможностите за оркестрация на контейнери в следващия раздел.

Инсталирането на Mac е толкова лесно, колкото brew install cockroachе показано по-горе. В моя случай автоматичната актуализация на Homebrew отне много повече време (достатъчно време за приготвяне на чай), отколкото действителната инсталация на CockroachDB, която отне само няколко секунди.

След като инсталирате CockroachDB, е доста лесно да завъртите локален клъстер, въпреки че има допълнителна стъпка за генериране на сертификати за сигурност с cockroach certкомандата, ако искате клъстерът да бъде защитен. След като стартирате клъстер (използвайки cockroach startкомандата веднъж за всеки възел, с последващи възли, настроени да се присъединят към клъстера на първия възел), можете да се свържете със страницата за уеб администриране на всеки възел с браузър и да използвате вградения cockroach sqlклиент за изпращане на SQL заявки към всеки възел. Повечето браузъри ще се оплакват от сайтове с генерирани от CockroachDB сертификати, но трябва да можете да кликнете върху това ужасно предупреждение и да продължите към сайта.

Препоръчителните производствени настройки на CockroachDB са различни от настройките по подразбиране, които са настроени за екземпляри за разработка и тестване. Можете да се развиете на клъстер с един възел, ако желаете. За производството трябва да имате минимум три възела, да изпълните всеки възел на отделна машина, VM или контейнер и да дадете на всеки екземпляр допълнителна кеш памет и SQL памет. Настройките по подразбиране са по 128 MB за кеш и SQL памет; препоръчителните производствени настройки са да се даде на всеки 25 процента RAM:

cockroach start --cache=25% --max-sql-memory=25%

Колкото повече възли изпълнявате, толкова по-добра е устойчивостта. Колкото по-големи и по-бързи са възлите, толкова по-добра е производителността. Ако искате да имате възли с производителност, приблизително сравнима с възлите на Google Cloud Spanner, които доставят 2000 записи в секунда и 10 000 четения в секунда, тогава бихте искали нещо като GCE n1-highcpu-8 екземпляри, които имат осем процесора и 8 GB RAM , с локални SSD дискове (а не въртящи се дискове).

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

Cockroach Labs предоставя подробни инструкции за внедряване на AWS, Digital Ocean, GCE и Azure. Препоръчаните конфигурации използват балансьори на натоварването, или родни управлявани услуги за балансиране на натоварването, или балансиращи натоварвания с отворен код като HAProxy.

Оркестрацията може да намали оперативните режийни разходи на клъстер CockroachDB до почти нищо. Cockroach Labs документира как се прави това за производство с Kubernetes и Docker Swarm. Хранилището CockroachDB-CloudFormation на GitHub показва как да използвате AWS CloudFormation и Kubernetes в една зона за достъпност за разработка и тест. Адаптирането на това за производство ще включва промяна на шаблона CloudFormation, за да се използват множество зони за наличност.

Програмиране и тестване на CockroachDB

CockroachDB поддържа проводния протокол PostgreSQL, така че пишете кода си така, сякаш програмирате срещу Postgres или поне подмножество на Postgres. Тази страница изброява тестваните драйвери за различни обвързващи езици за програмиране, включително най-популярните езици от страна на сървъра. Тази страница съдържа извадки на 10 езика за програмиране и пет ORM. Не срещнах големи изненади, когато прочетох кода, въпреки че забелязах няколко вероятни дребни грешки в списъците в документацията. Можете също така да стартирате своя SQL, като използвате интерактивния клиент, вграден в cockroachизпълнимия файл.

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

Друг факт, който трябва да се вземе предвид, е, че повечето конвенционални бази данни на SQL по подразбиране не се изпълняват в режим на СЕРИАЛИЗИРАНО изолиране; вместо това те използват по-малко строг режим с по-добра производителност. CockroachDB използва сериализуем режим на изолация по подразбиране. Освен това би било малко несправедливо да се тества производителността на SQL CockroachDB за присъединяване, която все още е в процес на разработка, с пакета TPC-C.

И все пак лесно можете да видите оперативната мощ на CockroachDB. Например, много бази данни трябва да бъдат спрени и рестартирани, за да ги мащабират. Добавянето на възли под товар в CockroachDB е бриз, особено ако използвате инструмент за оркестрация. Например екранната снимка по-горе показва командите за промяна и показване на възлите в клъстер Kubernetes, а екранната снимка по-долу показва наблюдавания клъстер при добавяне на възлите. Инструмент за генериране на натоварване работи непрекъснато през целия процес.

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

SQL CockroachDB 

SQL в CockroachDB е повече или по-малко стандартен, за разлика от SQL в Cloud Spanner, който използва нестандартен синтаксис за манипулиране на данни. В CockroachDB SQL обаче все още липсват много функции.

Например, V1.1 липсва JSON поддръжка, която е планирана за V1.2. Липсва и синтактичен анализ на XML, който не е в пътната карта. Липсват каскади на ниво ред, планирани за V1.2, и липсват курсори и тригери, които не са в пътната карта. Геопространствените индекси са „потенциални“ допълнения, които могат да стигнат до пътната карта в бъдеще.

Най-забележителното е, че първоначалното внедряване на SQL присъединявания на CockroachDB през 2016 г. е умишлено опростено и показва квадратично мащабиране, което го прави безполезно за заявки за големи масиви от данни. Версията във V1.0, направена от студент-кооператор, реализира хеш съединения, което прави много операции за присъединяване мащабно линейно; което доведе CockroachDB до нивото на SQLite. Някъде през 2018 г., предвид неотдавнашен кръг на финансиране, CockroachDB трябва да има производителност на присъединяване, която мащабира по-скоро като присъединяване на PostgreSQL, както и обработка на присъединяване към SQL, разпределена в клъстера.