Преглед на YugaByte: Касандра и Редис от планетата

По време на десетилетията си като разработчик на приложения за бази данни, никога не съм си представял в най-смелите си мечти, че някога ще имам достъп до транзакционна, планетарна, разпределена база данни, още по-малко, че ще сравнявам много от тях. Но с Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise и наскоро YugaByte DB, всички налични в производството, тази еднократна мечта за тръби вече е съвсем реална.

В най-широк смисъл Google Cloud Spanner предлага мащабируема, разпределена, силно последователна SQL база данни като услуга, която може да обработва около 2000 записи в секунда и 10 000 четения в секунда, на възел, със средна латентност от около пет милисекунди. За да ускорите четенето, което не се нуждае от абсолютно актуални данни, можете да помолите Spanner за остарели четения, тъй като поддържа заявки за пътуване във времето. Spanner използва диалект на Google на SQL и работи само на Google Cloud Platform.

CockroachDB е подобна на Spanner, SQL база данни с отворен код, която поддържа проводническия протокол PostgreSQL и диалекта на SQL PostgreSQL. CockroachDB е изграден върху RocksDB, транзакционен инструмент с отворен код и последователно съхранение на ключ-стойност. Подобно на Spanner, той поддържа заявки за пътуване във времето. CockroachDB може да работи във всеки облак, в контейнери на Docker с или без оркестрация, или на Linux сървъри или виртуални машини. Корпоративната версия на CockroachDB добавя георазделяне, базиран на роли контрол на достъпа и поддръжка.

Azure Cosmos DB е глобално разпределена, хоризонтално разделена, мултимоделна база данни като услуга. Той предлага четири модела данни (ключ-стойност, семейство колони, документ и графика) и пет регулируеми нива на съгласуваност (силна, ограничена застой, сесия, последователен префикс и евентуално). Той предлага пет набора API: SQL (диалект), MongoDB-съвместим, Azure Table-съвместим, графичен (Gremlin) и Apache Cassandra-съвместим. Той работи само в облака на Microsoft Azure.

Neo4j е мащабируема и оцеляваща база данни на графики, която използва езика за заявки на Cypher. Можете да инсталирате неговата версия с отворен код, неклъстерирана версия на Windows, MacOS и Linux, в контейнери на Docker и във виртуални машини. Neo4j Enterprise поддържа високодостъпни и причинно-следствени клъстери; причинно-следствените клъстери позволяват асинхронно актуализирани клъстери на реплики за четене, за да позволят висока производителност за географски разпределени разполагания.

Въведете Yugabyte DB

YugaByte DB, предмет на този преглед, е база данни с отворен код, транзакционна и високоефективна база данни за приложения на планета, която поддържа три API набора: YCQL, съвместим с Apache Cassandra Query Language (CQL); YEDIS, съвместим с Redis; и PostgreSQL (в момента непълна и в бета версия). YugaWare е слой за оркестрация за YugaByte DB Enterprise Edition. YugaWare извършва бърза работа за въртене и разрушаване на разпределени клъстери в Amazon Web Services, Google Cloud Platform и (до Q4 2018) Microsoft Azure. YugaByte DB прилага мултиверсионно управление на паралелността (MVCC), но все още не поддържа заявки за пътуване във времето.

YugaByte DB е изградена върху подобрена вилица на хранилището за ключ-стойност RocksDB. YugaByte DB 1.0, доставен през май 2018 г.

Две от ключовите технологии, използвани за да направят разпределените транзакционни бази данни последователни и бързи, са алгоритми за консенсус на клъстера и синхронизация на часовника на възлите. Google Cloud Spanner и Azure Cosmos DB използват алгоритъма за консенсус на Paxos, предложен от Leslie Lamport. CockroachDB и YugaByte DB използват алгоритъма за консенсус на Raft, предложен от Diego Ongaro и John Ousterhout.

Google Cloud Spanner използва собствения на Google TrueTime API, базиран на GPS и атомни часовници. DB Azure Cosmos DB, CockroachDB и YugaByte DB използват клеймове за хибриден логически часовник (HLC) и синхронизация на часовника по протокол за мрежово време (NTP).

Цели на дизайна на YugaByte

Основателите на YugaByte - Kannan Muthukkaruppan, Karthik Ranganathan и Михаил Баутин - са били привърженици на Apache HBase, ранни инженери на Apache Cassandra и строители на платформата NoSQL на Facebook (задвижвана от Apache HBase). Тяхната цел за YugaByte DB беше разпределен сървър за бази данни, философски между Azure Cosmos DB и Google Cloud Spanner; тоест, те искаха да комбинират мултимоделните и високопроизводителните атрибути на Cosmos DB с ACID транзакциите и глобалната последователност на Spanner. Друг начин за описване на целта им е, че те искаха YugaByte DB да бъде транзакционна, високопроизводителна и планетарна, наведнъж.

Те разбиха процеса на пет стъпки, за изграждането на всяка от които бяха необходими около шест месеца. Първата стъпка беше да се създаде силно последователна версия на RocksDB, високоефективно хранилище на ключ-стойност, написано на C ++, чрез добавяне на консенсусен протокол на Raft, рязкост и балансиране на натоварването и премахване на регистриране на транзакции, архивиране на точки във времето, и възстановяване, което трябваше да бъде приложено на по-висок слой.

Следващата стъпка беше да се изгради структуриран в дневника механизъм за съхранение от ключ към документ, като се добавят непримитивни и вложени типове, като редове, карти, колекции и JSON. След това те добавиха добавяем API слой, като Azure Cosmos DB, внедрявайки съвместими с Cassandra и Redis API и отлагайки SQL API, съвместим с PostgreSQL, на по-късен етап. След това се появиха разширени езици за заявки.

YugaByte Cloud Query Language (YCQL) разширява Cassandra API с поддръжка за разпределени транзакции, силно последователни вторични индекси и JSON. YugaByte Dictionary Service (YEDIS) е съвместим с Redis API с добавки на вградена устойчивост, автоматично рязкост и линейна мащабируемост. YEDIS по избор позволява последователно четене на времевата линия с ниско забавяне от най-близкия център за данни, докато силните операции на запис поддържат глобална последователност. YEDIS включва и нов тип данни от времеви редове.

И накрая, с версия 1.0, YugaByte DB Enterprise добавя слой за оркестриране, защита и наблюдение на производствени разгръщания в множество региони и множество облаци и съхранява разпределени архиви до конфигурируема крайна точка като Amazon S3. Поддръжката на PostgreSQL остава непълна и е на ниво бета-тест.

Разпределени ACID транзакции 

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

Да предположим, че изпращате YCQL заявка, съдържаща актуализации в рамките на транзакция, например сдвоен дебит и кредит, които и двата трябва да бъдат прекъснати, ако единият не успее, за да се поддържа последователността на финансовата база данни. YugaByte DB приема транзакцията в диспечер на транзакции без състояние, един от които работи на всеки възел в клъстера. След това мениджърът на транзакции се опитва да планира транзакцията на таблетния сървър, който притежава по-голямата част от данните, достъпни от транзакцията, с цел изпълнение.

Мениджърът на транзакции добавя запис на транзакция с уникален ID в таблицата на състоянието на транзакцията. След това той записва временни записи на всички таблети, отговорни за ключовете, които транзакцията се опитва да модифицира. Ако има конфликти, една от конфликтните транзакции се връща обратно.

След като всички временни записи са написани успешно, мениджърът на транзакции моли таблета за състоянието на транзакцията да замени всички временни записи с редовни записи, използвайки клеймото за време на записа „извършена транзакция“ в дневника на Raft. И накрая, таблетът за състояние на транзакцията изпраща заявки за почистване до всеки от таблетите, участвали в транзакцията.

За да подобри производителността, YugaByte агресивно кешира информация за текущи транзакции, прилага фино заключени брави и използва хибридни лизинг на времеви лидери, за да попречи на клиентите да четат остарели стойности от стари лидери. Едноредовите ACID транзакции са оптимизирани да имат ниски латентности, когато няма конфликтна операция. Разпределените ACID транзакции запазват коректността за сметка на по-високите латентности.

YCQL, YEDIS и PostgreSQL

YugaByte включва почти пълна реализация на CQL, както и някои разширения. Едно огромно подобрение спрямо Cassandra е, че YugaByte е силно последователен, докато Cassandra в крайна сметка е последователен. Другите подобрения са за разпределени транзакции, силно последователни вторични индекси и JSON. YugaByte превъзхожда Касандра за всяка операция, с изключение на сканирането на къси разстояния, поне отчасти поради силната си последователност, която позволява едно четене вместо четенето на кворума, необходимо в Касандра.

Касандра поддържа четири примитивни типа данни, които все още не се поддържат в YugaByte: дата, час, кортеж и varint. YugaByte също има някои ограничения върху изразите. 

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

Реализацията на YugaByte PostgreSQL не е много далеч. В момента в него липсват UPDATE и DELETE изрази, изрази, а в оператора SELECT липсва клауза за присъединяване.

Инсталация и тестване на YugaByte

Можете да инсталирате DB с отворен код YugaByte от изходния код, от tarballs на MacOS, Centos 7 и Ubuntu 16.04 или по-нова версия, както и от Docker изображения на Docker или Kubernetes. След това можете да създадете клъстери и да тествате трите API за заявки и някои примерни генератори на натоварване.

Избрах да инсталирам YugaByte DB Enterprise на Google Cloud Platform. Въпреки че имаше повече ръчни стъпки, които бих искал, успях да премина през инсталацията и тестовете си за един следобед, след като получих лицензния си ключ за Enterprise Edition.

След като екземпляр YugaWare се изпълняваше на екземпляр с четири CPU в Google Cloud, конфигурирах Google Cloud Platform като доставчик на облак за моя клъстер на база данни.

След това създадох клъстер от три възли от осем екземпляра на процесора в региона на САЩ и Изтока.

Изпълних тестове за натоварване, използвайки API на CQL и Redis.

Успях да потърся данни за CQL и Redis от командния ред.

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

YugaByte разходи

Цената на лиценза за YugaByte DB Enterprise Edition с три възли започва от $ 40 000 на година. В допълнение към това трябва да вземете предвид разходите за сървърите. За клъстер с три възли на Google Cloud Platform, използващ екземпляри на VM с осем процесора, тази цена е в диапазона от 800 до 900 долара на месец плюс мрежов трафик, може би 11 хиляди долара годишно.

Моите собствени разходи за един следобед на тестване бяха $ 0,38 за случаите и $ 0,01 за излизане от зоната. Изтриването на клъстери на бази данни от интерфейса на YugaByte DB Enterprise беше лесно и след като спрях екземпляра на VM, изпълняващ интерфейса за администриране и оркестрация, той вече не натрупа значителни такси.

По-бързо, по-добре, разпределено

Като цяло, YugaByte DB се представя както е рекламирано. На този етап от развитието си е полезен като по-бързи, по-добре разпределени Redis и Cassandra. В крайна сметка би трябвало да бъде и по-добър PostgreSQL, въпреки че според моя опит това отнема много време (години, а не месеци), особено когато стигнете до точката да се опитате да настроите релационни присъединения.

YugaByte DB все още не се конкурира с Google Cloud Spanner, CockroachDB или SQL интерфейса към Azure Cosmos DB поради липса на доработен SQL интерфейс. Все още не се конкурира с Neo4j или графичния интерфейс към Cosmos DB поради липса на поддръжка на база данни за графики. Той наистина се конкурира с Redis, Cassandra и съвместимия с Cassandra интерфейс за Cosmos DB.

Трябва ли да изпробвате YugaByte DB сами? Ако имате нужда от разпределена версия на Redis или Cassandra или трябва да замените MongoDB за глобално разпределен сценарий, тогава да. YugaByte DB може да се използва и за стандартизиране на една база данни за множество цели, като например комбиниране на база данни Cassandra с кеширане Redis, както направи клиентът на YugaByte Narvar. YugaByte DB също добавя високопроизводителни вторични индекси и JSON тип към Cassandra, увеличавайки полезността си като транзакционна база данни.

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