Создание удобных для разработчиков сервисов данных с помощью Apache Cassandra

Все приложения зависят от данных, но разработчики приложений не любят думать о базах данных. Изучение внутреннего устройства и языка запросов конкретной базы данных добавляет когнитивную нагрузку и требует переключения контекста, что снижает производительность. Тем не менее, успешные приложения должны быть отзывчивыми, отказоустойчивыми и масштабируемыми — все эти характеристики будут определяться выбором базы данных.

Как же тогда разработчику приложения сбалансировать эти соображения?

Что, если бы мы могли изменить баланс, предоставив службу данных на удобных для разработчиков идиомах, а не ожидая, что разработчики будут изучать идиомы, специфичные для базы данных?

В рамках проекта Stargate, шлюза данных API с открытым исходным кодом, предназначенного для работы с Apache Cassandra, мы рады начать публично говорить о предстоящем JSON API, который подходит разработчикам, ориентированным на JSON, на их условиях. Это не только отличная новость для разработчиков, ориентированных на JSON, но и техника, которой мы следовали, представляет собой новый шаблон проектирования для использования API данных и расширенного моделирования данных для создания служб данных.

В этой статье я расскажу, как предоставить удобные для разработчиков идиомы, используя Cassandra вместе со Stargate, и как мы работаем над этим для JSON.

Модели данных: интероперабельность и идиоматика

Раньше Cassandra иногда называли "машиной для создания индексов". Это было свидетельством врожденной устойчивости и гибкости Кассандры, глины, из которой можно было лепить более прочные конструкции. Кассандра сегодня — это более богатая глина с большими возможностями.

Это не только отличная база данных, но и отличная машина для создания баз данных. Здесь, в проекте Stargate, мы используем JSON API, чтобы доказать это как первый пример новой парадигмы в разработке баз данных.

Нередко одна база данных строится из другой. Даже MongoDB построен на основе WiredTiger, если копнуть достаточно глубоко. AWS известен тем, что широко использует MySQL за кулисами, включая механизм хранения MySQL для DynamoDB. Поэтому идея использования Cassandra с присущими ей масштабируемостью и производительностью в качестве строительного блока для других систем данных имеет смысл.

Однако разработчики приложений на самом деле не взаимодействуют с базами данных. Даже если ваша организация управляет собственной инфраструктурой баз данных и создает приложения для этой инфраструктуры, первым шагом, как правило, является определение и реализация моделей данных, которые требуются вашим приложениям.

Эти модели данных являются посредниками между приложением и базой данных. В некотором смысле моделирование данных ограничивает базу данных; он берет несформованную и, следовательно, универсальную глину и формирует из нее что-то, специально созданное для конкретной прикладной идиомы. Мы жертвуем функциональной совместимостью ради чего-то идиоматичного.

Это хорошая идея, чтобы обменять что-то идиоматическое и отказаться от чего-то совместимого? Если вы хотите превзойти средние показатели, то ответ будет решительным «да». Мы не особо думаем об этом при выборе баз данных, но мы давно думали об этом при выборе языков программирования.

Эта идея была хорошо выражена Полом Грэмом несколько десятилетий назад, когда он объяснил, как Viaweb выиграл раннюю гонку доткомов, создав первую широко успешная веб-платформа для электронной коммерции.

Viaweb не обязательно была самой быстрой или масштабируемой платформой электронной коммерции. По словам Грэма, это было «достаточно эффективно». Вместо этого Грэм утверждает, что для языков программирования, по шкале от машиночитаемого до удобочитаемого, более удобочитаемые (и, следовательно, более высокоуровневые) языки являются более мощными, поскольку они повышают производительность разработчиков. А во времена Viaweb Грэм считал самым мощным языком Lisp. Суть аргумента Грэма заключается в следующем:

«Наша гипотеза заключалась в том, что если мы напишем наше программное обеспечение на Лиспе, мы сможем выполнять функции быстрее, чем наши конкуренты, а также делать в нашем программном обеспечении то, что они не могут. И поскольку Lisp был настолько высокого уровня, нам не понадобилась бы большая команда разработчиков, поэтому наши затраты были бы ниже. Если бы это было так, мы могли бы предложить лучший продукт за меньшие деньги и при этом получать прибыль. В конечном итоге мы получим всех пользователей, а наши конкуренты не получат ни одного и в конечном итоге обанкротятся».

Раскрытие возможностей разработчиков

Грэм написал эти слова 20 лет назад, и производительность разработчиков остается путеводной звездой, определяющей многие технологические инновации. Там, где Грэм говорит о возможностях языков высокого уровня, мы выражаем ту же концепцию, предоставляя разработчикам инструменты, которые более идиоматичны для их опыта разработки программного обеспечения.

Грэм хвалит Lisp (правильно), и со времен доткомов мы наблюдаем распространение новых языков высокого уровня: Ruby и Rust, если назвать пару. Мы также стали свидетелями появления и распространения языков и сред разработки мобильных устройств, таких как Swift, Flutter и Dart.

Так почему же такие языки, как C и C++, по-прежнему важны? В старой шутке о C содержится важная истина: «Сочетание мощи языка ассемблера с простотой использования языка ассемблера». Если вы хотите написать компилятор, вам нужно приблизиться к идиоме машинного языка и уйти от идиомы естественного языка.

Другими словами, помимо прочих достоинств, C и C++ — это машины для создания новых языков. Что легко упустить из виду в восхвалениях Грэмом Лиспа, так это то, что Лисп также обладает некоторой характеристикой «машины для создания языков».

Лисп был первым широко используемым языком, в котором была введена концепция макросов, и часто именно концепция макросов сбивает с толку новичков в Лиспе. Как только вы поймете макросы, вы поймете, что Lisp — это скорее метаязык, чем язык, и что макросы можно использовать для создания специального языка для конкретной предметной области.

Разработка и создание начального набора макросов — тяжелая, интеллектуально сложная работа. Но как только Грэм и команда Viaweb сделали это, у них появился язык программирования для электронной коммерции, с которым они могли работать, и это открыло возможности для повышения производительности разработчиков, позволившие им опередить своих конкурентов.

Двадцать лет спустя все это кажется достаточно ясным в контексте языков программирования. Итак, что же произошло в мире баз данных? Короткий ответ: базы данных развивались медленнее.

Революция API данных

Если табличные данные — это язык ассемблера мира баз данных, то SQL — это C/C++ языков запросов. Мы разработали табличные структуры данных и концепцию нормализации данных в эпоху, когда вычисления и хранение были дорогими, и для случаев использования, которые были четко определены с относительно редкими изменениями схемы. В этом контексте для эффективной работы в любом масштабе базы данных должны точно имитировать способ, которым компьютеры хранят информацию и получают к ней доступ.

Сегодняшний мир является противоположным, и по сравнению с ним то, что было раньше, кажется архаичным: затраты на вычисления и хранение сильно коммодитизированы, но в мире данных в реальном времени в сочетании с машинным обучением и искусственным интеллектом варианты использования открыты, а изменения схемы часто.

Самой последней революцией в технологии баз данных стала революция NoSQL, прямой ответ на канон табличных, нормализованных данных, установленный первосвященниками мира реляционных баз данных. Когда мы говорим «революция NoSQL», мы имеем в виду период с 2004 года, когда Google выпустила свой белая книга MapReduce до 2007 года, когда Amazon опубликовала свой Технический документ Dynamo.

В этот период появилось семейство баз данных, которые достигли беспрецедентной скорости, масштабируемости и отказоустойчивости за счет отказа от двух заветных реляционных принципов: базы данных NoSQL отдавали предпочтение денормализованным данным, а не нормализации данных, и отдавали предпочтение согласованности в конечном итоге, а не согласованности транзакций. Cassandra, впервые выпущенная в 2008 году, стала результатом этой революции.

API данных станут следующей крупной революцией в технологии баз данных, революцией, которая только начинается. Изменения в мире баз данных, как правило, отстают от изменений в языках программирования и разработке приложений. Таким образом, хотя RESTful API существуют уже некоторое время и помогли создать архитектуру для распределенных сервис-ориентированных приложений, мы только начинаем видеть, как API данных становятся ключевой частью инфраструктуры приложений.

Чтобы понять значение этой революции и то, как спустя 20 лет после провозглашения Пола Грэма мир баз данных, наконец, обеспечивает продуктивность разработчиков, давайте посмотрим на собственную историю Stargate. Он начинается с возвращения к теме совместимости и идиоматичности.

Звездные врата: высококачественный, идиоматический опыт разработчиков

Когда мы решили, что экосистеме Cassandra нужен шлюз данных, мы срочно создали исходный набор API-интерфейсов Stargate. Это означало монолитную архитектуру; монолиты строятся быстрее, но не всегда лучше. Мы начали с API Cassandra Query Language (CQL), REST API и RESTful Document API. Мы быстро добавили GraphQL в качестве дополнительного API. На сегодняшний день Звездные врата совместимы; все из Stargate хранится с использованием собственной модели данных CQL, поэтому в принципе вы можете запрашивать любую таблицу из любого API.

Мы убедились, что на практике никто так не делает. Разработчики придерживаются своей особой идиомы. Отдавая предпочтение интероперабельности, мы добавили Cassandra-измы в опыт разработчиков, тем самым снизив производительность разработчиков. Поскольку первоначальная версия Stargate требовала от разработчиков понимания табличных структур данных Cassandra с широкими столбцами, понимания пространств ключей и разделов, мы слишком близко привязались к машинному языку и слишком далеко от человеческого языка.

Ловушка интероперабельности заключается в том, что предпочтение отдается общему назначению, а не целенаправленному дизайнерскому мышлению. Мы развернулись к мышлению с точки зрения целенаправленности, которое меняет некоторые общие возможности на более конкретный способ выражения, приближая нас к человеческому языку и дальше от машинного языка. И поэтому мы начали думать: можем ли мы предоставить высококачественный идиоматический опыт разработки, сохранив достоинства основ Cassandra NoSQL (масштаб, доступность и производительность)?

Ключ лежит в моделировании данных. Чтобы превратить Cassandra в «Lisp баз данных», нам нужна была модель данных, которая могла бы служить цели, аналогичной макросам Lisp, вместе с API Stargate, который позволил бы разработчикам идиоматически взаимодействовать с этой моделью данных. Мы начали с JSON, наиболее общего знаменателя структур данных среди разработчиков приложений, и поэтому начали создавать JSON API для Stargate. Затем нам нужно было выяснить, как лучше смоделировать JSON в Cassandra.

В Stargate уже есть Document API, но в оригинальном Document API мы использовали модель данных мы называем «уничтожение», чтобы отобразить документ JSON в виде таблицы Cassandra. Эта модель сопоставляет один документ с несколькими строками в одной таблице Cassandra и сохраняет совместимость. Если вы используете CQL для запроса результирующей таблицы, вы получите содержательные результаты.

Эта оригинальная модель измельчения данных имеет недостатки. Он не сохраняет метаданные о документе. Например, для любого документа, содержащего массивы, после того, как документ написан, мы ничего не знаем о размере массива без полной проверки документа. Что еще более важно, мы отошли от ожиданий Кассандры в отношении индексации. Cassandra индексирует строки, но теперь мы распределили наш документ по нескольким строкам, что делает невозможным собственный индекс документов Cassandra.

Чтобы сделать Cassandra подходящим механизмом хранения для JSON, нам нужна была новая модель данных, нечто большее, чем измельчение. Мы назвали это «супер измельчением». Вы можете узнать больше о супершреддинге на выступлении на саммите Cassandra Аарона Мортона в декабре. -столбцовый характер для хранения одного документа в строке, зная, что строка Cassandra может обрабатывать даже очень большие документы.

У нас также есть набор столбцов в этой строке, которые явно предназначены для хранения стандартных характеристик метаданных документа JSON. Теперь у нас есть что-то более легко индексируемое, а также средство сохранения и извлечения метаданных.

Содействие Кассандре

Да, чтобы заставить все это работать в масштабе, нам потребуются некоторые базовые изменения в Cassandra. Accord, который Apple вносит в Cassandra 5, поможет нам обрабатывать изменения данных более транзакционным способом. Индексация с подключением к хранилищу (SAI) и глобальная сортировка, которые DataStax вносят в Cassandra 5, помогут нам обрабатывать ранжированные запросы к документам JSON в более эффективным способом.

Cassandra — это не статическая программа; это динамичный и развивающийся проект с открытым исходным кодом. Таким образом, мы также продолжаем давнюю традицию Cassandra по использованию требований, возникающих на стороне клиента, для внесения изменений на стороне базы данных. Потребности пользователей вызвали предложения по Accord, SAI и Global Sort. Это не только улучшит JSON API Stargate, но и улучшит Cassandra. Это отличное напоминание о том, что инженеры по данным и разработчики приложений — это не два разных сообщества, а дополняющие друг друга когорты расширенного сообщества Cassandra.

И JSON — это только первый шаг. По сути, мы создадим базу данных документов, с которой вы взаимодействуете через JSON API, на основе Cassandra, Stargate и достаточно эффективной модели данных Cassandra. Супер измельчение — это наш макрос. Такой подход превращает Cassandra в машину для создания баз данных.

Может ли этот подход использоваться в другой базе данных, помимо Cassandra? Не легко, и вот почему. Существует своего рода аналог базы данных второго закона термодинамики, который работает в пользу Кассандры. Мы начинаем с чего-то быстрого, масштабируемого и отказоустойчивого, но не очень идиоматичного для разработчиков. В рамках ограничений разумной эффективности мы обмениваем часть этой скорости, масштаба и устойчивости на более идиоматический интерфейс, чтобы представить его разработчикам. Чего нельзя легко сделать, так это пойти в обратном направлении. Начать с чего-то очень идиоматичного, а затем попытаться выяснить, как сделать его быстрым, масштабируемым и устойчивым, — сложная задача, которая может быть даже невыполнимой.

Этот термодинамический принцип объясняет, почему API данных — это новая революция в базах данных, а Cassandra — база данных, которая приведет эту революцию в действие.

Также опубликовано здесь