В компании Яндекс YDB используется уже больше пяти лет. На мультитенантных кластерах развёрнуты базы с очень разными нагрузками и паттернами доступа к данным. На практике мы встречаемся с многократным ростом баз данных, ростом объёмов данных с единиц гигабайт до сотен терабайт и ростом нагрузок с тысяч до миллионов RPS. При этом решение задач масштабируемости и отказоустойчивости автоматически осуществляет база, снимая их с разработчиков прикладного кода. Но YDB распространена не только в проектах с высокой нагрузкой. Команды разработки Яндекса сами определяют свой стек в зависимости от задач, аудитории и другой специфики, и многие выбирают YDB за отказоустойчивость, даже если текущие нагрузки невелики. Одна из причин в том, что в случае внезапного роста нагрузок разработчикам будет достаточно добавить ресурсы, не внося изменения в код приложения и не прикладывая усилия к ручному перешардированию базы. Проекты в YDB размещают команды Алисы, Такси, Метрики и других сервисов — сейчас в системе почти 500 проектов.
Широкое распространение YDB внутри Яндекса, популярность в качестве сервиса Яндекс Облака и запросы пользователей cтали для нас хорошим стимулом раскрыть исходный код и сделать базу доступной для свободного использования.
Немного истории или первый коммит в YDB
За два последних десятилетия непрерывно растёт использование интернета, в последние годы он начал прочно входить в бытовую сферу. Часы, очки, лампочки, пылесосы — практически все устройства подключены к интернету или подключатся в скором времени. Всё это ведёт к непрерывному росту объёмов хранимых данных и нагрузок, которые БД обрабатывают.
С начала 2000-х вместе с бурным ростом интернета выросла популярность опенсорсных СУБД для OLTP-нагрузок — например, MySQL и PostgreSQL.
Без них или их аналогов сложно представить себе нынешние темпы развития интернета. Даже небольшие стартапы получили возможность работать с возрастающими нагрузками на бесплатных БД. Конечно, существовали тяжёлые коммерческие решения, которые позволяли масштабироваться вертикально, но они были доступны только большим компаниям с соответствующими бюджетами.
К середине 2000-х стали популярны разные виды логического шардирования БД — когда базу шардируют на несколько узлов, исходя из бизнес-логики приложения и его сущностей. Промежуточный слой между приложением и базой или само приложение принимает решение, на каком из узлов БД находятся данные. Но этот распространённый подход приводит к усложнению логики пользовательского приложения и значительно усложняет поддержку множества кластеров. Дополнительные сложности возникают при необходимости выполнить запрос, результат которого выдаёт консистентный результат объединения данных из разных шардов. Эту проблему можно решить за счёт отгрузки данных в отдельную систему или дополнительного усложнения логики приложения, но каждый такой дополнительный шаг только усложняет обслуживаемость системы и делает её менее технологичной. В то же время остаются открытыми такие вопросы, как перешардирование данных при росте нагрузки на конкретный шард. Сложно развить изначально выбранный подход к шардированию при изменившихся бизнес-требованиях к приложению. Нагрузки продолжают расти, а критичность отказов возрастает.
В конце 2000-х набирают популярность NoSQL-решения. Во главе угла становятся проблемы масштабируемости и отказоустойчивовости, в жертву приносится диалект SQL и функциональность join. Приемлемой считается eventual consistency, то есть консистентность в конечном итоге: рано или поздно все реплики во всех зонах доступности или регионах получат консистентный набор данных. Растёт популярность key-value-хранилищ (Redis, AWS DynamoDB), column-family (Cassandra, Hbase) и документных БД (MongoDB, Couchbase).
Мы шли тем же путем, и история развития OLTP СУБД в Яндексе повторяет историю развития операционных БД. Предшественником YDB была СУБД NoSQL (KV), которую мы разрабатывали с 2008 года.
Отсутствие поддержки ACID-транзакций приводит к необходимости самостоятельно их эмулировать. Возрастает сложность прикладного кода, и каждый разработчик фактически вынужден дорабатывать на стороне этого кода функциональность базы — что, во-первых очень сложно, а во-вторых, на большом количестве проектов требует множества костылей и велосипедов в каждом проекте.
Проблема оставалась актуальной. В начале 2010-х появляется новый термин — NewSQL. Про него рассказывают Майкл Стоунбрейкер и Энди Павло, описывая новые требования к OLTP СУБД (точнее, ожидания от такой базы).
NewSQL-базы должны обладать масштабируемостью и отказоустойчивовостью, свойственной NoSQL-системам, но при этом предоставлять ACID-гарантии транзакций и SQL-диалект. Чуть позже термин NewSQL трансформировался — масштабируемые, отказоустойчивые БД с поддержкой SQL и строгой консистентностью стали называть Distributed SQL Databases. Вдохновившись идеей NewSQL, в 2012 году мы сделали первый коммит в YDB.