Дэниел Гвак и Айви Нгуен, Point72 Ventures, искусственный интеллект

Облачные вычисления кажутся повсеместными, но их полное внедрение на предприятиях по-прежнему сдерживается реальной физической проблемой: скорости света недостаточно. Это ограничение вызывает всевозможные проблемы с надежностью и точностью, что не позволяет крупным предприятиям использовать распределенные базы данных облачных вычислений для всей своей деятельности. Поскольку все, с чем мы взаимодействуем в цифровой вселенной, поддерживается базой данных, создание системы, способной превзойти скорость света, является новаторским техническим достижением, которое может высвободить 100 миллиардов долларов корпоративных расходов на базы данных и связанные с ними услуги. Мы считаем, что команда Fauna добилась именно этого с FaunaDB, базой данных OLTP, созданной для облака. Вот почему наша команда в Point72 Ventures возглавила раунд серии A Fauna стоимостью 25 миллионов долларов — крупнейшую серию A для стартапа базы данных.

Дорогая и масштабная проблема

Для поддержки критически важных бизнес-операций эти базы данных должны быть верными на 100 % в течение 100 % времени. Например, если ваш банк создает мобильное приложение, лучше не ошибаться, когда оно показывает вам банковский баланс. Когда ваш банковский баланс имеет тенденцию к снижению, это почти никогда не связано с ошибкой базы данных — более вероятным виновником является ваша склонность к кустарным тостам с авокадо. Но демонстрация того, что баланс счета в вашем мобильном банковском приложении требует правильности базы данных во многих отношениях: она никогда не должна терять записи, она никогда не должна читать и записывать записи не по порядку, она должна быстро реагировать на запросы, она никогда не должна спускаться и так далее. Когда что-то идет не так — как это недавно произошло в Wells Fargo, — клиенты теряют доступ к своим банковским счетам, исчезают зарплаты, и сразу же возникает возмущение.

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

Вот почему сегодня более 70% рынка баз данных стоимостью 50 миллиардов долларов принадлежит только трем компаниям: Oracle, IBM и Microsoft. Предприятия продолжают использовать эти базы данных (часто работающие на дорогостоящем специализированном оборудовании в системах мэйнфреймов), потому что они предлагают более надежные гарантии правильности данных, чем большинство систем.

Почему это плохо для облачных вычислений

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

Следовательно, этим облачным приложениям нужны базы данных, которые также предназначены для работы в распределенном режиме. А обеспечение точности и надежности данных класса мэйнфреймов в распределенной среде — это действительно сложная техническая проблема, которую часто считают священным Граалем в области компьютерных наук.

С точки зрения принципов проектирования баз данных проблема заключается в компромиссах. При распределении данных по множеству сайтов вы можете выбрать либо скорость доступа, либо правильность, но не то и другое одновременно. Например, если у вас есть база данных с репликами в Нью-Йорке и Токио, каждая из которых поддерживает десятки тысяч транзакций в секунду, установление строгого порядка, в котором происходили транзакции, является реальной проблемой, если учесть, что даже скорость света заняла бы 72 секунды. миллисекунд, чтобы пройти туда и обратно — на самом деле, сетевой трафик (который страдает от различных строп и стрел по пути) занимает более 200 миллисекунд между двумя точками. Чтобы обойти это ограничение, вы можете заблокировать базу данных на время задержки, чтобы избежать путаницы (отдавая приоритет правильности), или вы можете позволить каждой базе данных выполнять транзакции на полной скорости, но соглашаетесь не соглашаться с порядком, в котором совершено транзакций (приоритет скорости).

Выбор распределенной базы данных, обеспечивающей скорость или точность, зависит от типа рабочей нагрузки вашего приложения. Процессоры кредитных карт предпочитают точность скорости, потому что пользователи не заметят дополнительных долей секунды, но обязательно заметят, если их транзакции будут записаны неточно. В других приложениях отдавать приоритет скорости и отказываться от корректности — это нормально. Например, базы данных Facebook должны обрабатывать более 1,6 миллиарда чтений в секунду в часы пик, а их базы данных широко рассредоточены географически, поэтому они отказываются от строгой корректности. Хотя вы можете этого не осознавать, то, что вы видите, может отличаться от того, что видит другой пользователь в это время. К сожалению, многие приложения, такие как фондовые биржи, где вам нужно с предельной уверенностью знать, какой трейдер продал акцию, в какое время и по какой цене, не могут пойти на такой компромисс.

Устранение узкого места корпоративной облачной базы данных

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

В Кальвине Абади описал алгоритм консенсуса, в котором несколько машин предварительно обрабатывают транзакции, чтобы согласовать их порядок, перед выполнением их до завершения. Таким образом, будет достигнута строгая сериализуемость транзакций без необходимости точного знания времени, в которое они произошли. Еще одно место, где вы, возможно, слышали о протоколах консенсуса, — это блокчейны, с которыми Fauna имеет некоторые фундаментальные сходства (без всей схематичности предложений монет, разрекламированных влиятельными лицами).

Без такой системы, как FaunaDB, компании преодолевали эту проблему с помощью экзотических (и дорогостоящих) разработок или жертвуя бизнесом. Например, многие игры требуют, чтобы пользователи выбрали географическую «зону», в которой будут соревноваться — это обычно обусловлено компромиссом базы данных между скоростью (уменьшение задержки в игровом процессе) и правильностью (определение того, кто первым нажал на курок). Подобные ограничения могут ограничить географический охват предприятия и затормозить его рост.

Другие решения в классе Fauna могут быть непомерно дорогими или лишь частично решить проблему. Google Spanner использует атомные часы, быстрые сети и GPS, чтобы точно определить, когда (и, следовательно, в каком порядке) происходят транзакции в любой точке мира. Работают только атомные часы, потому что традиционные часы имеют тенденцию со временем расходиться из-за крошечных физических различий в кристаллах кварца, которые часы используют для отсчета времени. Этот подход хорошо сработал для Google, потому что у них есть собственная облачная платформа. Spanner нельзя развернуть в сторонних облаках или мультиоблачных средах, поэтому он ограничен рынком только Google. Некоторые компании, такие как Cockroach Labs, основывали свою базу данных на протоколе Spanner, но страдают от отсутствия доступа к атомным часам и быстрым сетям и поэтому не могут предоставить такие же гарантии, как Spanner или FaunaDB.

Команда Фауна под руководством Эвана Уивера и Мэтта Фрилза поняла, что на самом деле нужно предприятиям в базе данных, оптимизированной для облачных вычислений, благодаря их опыту создания инфраструктуры Twitter, когда он превратился в одну из крупнейших распределенных систем веб-масштаба в мире. Для того чтобы поддерживать больше корпоративных приложений в облаке, в базах данных следующего поколения пришлось резко минимизировать эти компромиссы между скоростью и правильностью. Что еще более важно, это должно быть сделано таким образом, чтобы это было доступно для всех предприятий, а не только для небольшой горстки крупных и технических компаний, способных нанять лучших в мире инженеров по базам данных.

Предприятия тратят 50 миллиардов долларов каждый год только на устаревшие технологии баз данных и даже больше на логику приложений, необходимую для компенсации функциональности, которая должна быть основной в облачной базе данных. Создание базы данных, которая решает эти проблемы, — это огромная рыночная возможность, потому что базы данных — это часть стека, которую клиенты не могут построить самостоятельно (это чертовски сложно). Это фактически направляет весь спрос к нескольким игрокам, которые могут надежно создать продукт, и редко бывает так, что так мало игроков надежно конкурируют за такой большой рынок. Мы рады видеть, как развивается этот рынок. Войны облачных баз данных только начались.