Комментарии 135
а userver тоже в этом году выйдет в опенсорс?
Это вопрос скорей к авторам userver @antoshkka
а userver тоже в этом году выйдет в опенсорс?
Да, если не случится непредвиденного. Выложим в opensource вместе с:
Шаблоном для создания своих сервисов. CI, сборка, тестовое окружение уже настроены из коробки
Сервисом динамических конфигов. Можно менять параметры вашего работающего сервиса без его рестарта
Документацией, примерами и чатами поддержки (куда же без этого!)
Готово! Мы выложили userver в опенсорс: https://habr.com/ru/company/yandex/blog/674902/
Хороший шаг. Спасибо, что делитесь с сообществом наработками. Достаточно давно используем в проде ClickHouse. Довольны. Теперь попробуем и YDB.
Было бы еще интересно получить интеграцию c qemu для дисков виртуалок...
Она же не поверх YDB?
NBS в Яндекс-Облаке реализован поверх YDB, в 2018 рассказывали про это:
https://www.youtube.com/watch?v=Kr6WIYPts8I&t=12861s
https://cloud.yandex.ru/docs/ydb/public_talks#about-cloud
Было бы интересно сравнить с tidb
Конкурент, скорее, Yugabyte.
Таракан построен по другому принципу, больше похоже на Google Spanner.
Поищите в интернетах эпические битвы между Cockroach и Yugabyte и попробуйте решить, какой подход лучше :))
Там не просто acid, а с уровнем по умолчанию serializable. По описаниям из доки, она под oltp, если с таким уровнем производительна, то считаю это очень приятным.
Сейчас вот сижу читаю доку в разделе концепции, сайт у них очень приятный кстати.
поддержиывется ли ACID?
да
а интерактивные транзакции?
тоже да
на скольео YQL соответствует ANSI SQL, в чем причина для нового языка?
Про причины появления достаточно подробно написал мой коллега в статье про YQL. Мы в целом стремимся к максимальному сближению с ANSI SQL.
Исходный код, документация, SDK и все инструменты для работы с базой опубликованы на GitHub под лицензией Apache 2.0.
Не планирует ли Яндекс выпустить свой гитхаб, с рекламой и Алисой? Нынче становится актуально.
У них в облаке есть Gitlab - https://cloud.yandex.com/en/services/managed-gitlab
Очень круто, молодцы!
@olalala
У вас в документации сказано, что "YQL (YDB Query Language) is a universal declarative query language for YDB, a dialect of SQL. YQL has been natively designed for large distributed databases, and therefore has a number of differences from the SQL standard".
Если YQL это диалект, то с каким именно стандартом SQL вы себя здесь сравниваете и в чем конкретно эти отличия состоят? Где найти список того, что из SQL не поддерживается и того, что вами было в него привнесено?
Походу - привнесены всякие ключевые слова и параметры, связанные с масштабированием.
Увидел выше ответ "Мы в целом стремимся к максимальному сближению с ANSI SQL". Т.е. здесь имеется в виду самый первый стандарт SQL, принятый в 1986 году.
Пока не готовы точно сказать про версию стандарта, но безусловно будем учитывать и уже поддержанную в YDB функцинальность, такую как поддержка JSON (поддержка синтаксиса появилась в ANSI SQL 2016) и планы по будущей функциональности.
Я бы советовал не упоминать ANSI SQL в качестве целевого стандарта и даже не потому что ANSI – это Американский национальный институт стандартов, который представляет интересы США.
Просто в отношении стандарта SQL есть очень распространенное
заблуждение – думать, что ANSI создает стандарт SQL. На самом деле сейчас в
США просто берут очередную ревизию международного стандарта ISO/IEC 9075 и утверждают его в качестве национального. Например, говоря "ANSI SQL 2016" вы, скорее всего, имели в виду "ISO/IEC 9075:2016". Но у этого заблуждения есть корни – первый стандарт SQL (ANSI X3.135-1986) действительно был создан структурами, аккредитованными ANSI.
Будете тесты Jepsen заказывать? А то бенчмарки производительности хорошо, но надёжность для данных важнее :)
Фантастика!!!
А будет ли тяжело освоится в YDB мне как новичку, который только научился разрабатывать отчеты с использованием ETL-процессов? Я учился на Oracle PL/SQL , если что.
GitHub банит Россию, а главная ИТ-компания выкладывает туда свой проект. При чем тут политика?
Ну поднимут потом свою "локальную" репу. А пока не забанили - hello world!
Честно говоря, - я не понял вопрос, - вроде же чисто техническая статья?
Вы считаете, что не надо ничего выкладывать на гитхаб, поскольку он повёл себя недружественно? Или вы считаете, что не надо выкладывать на гитхаб поскольку высок риск, что репозиторий заблочат? Или надо демонстративно не выкладывать на гитхаб, чтобы обозначить перед всеми позицию в данном конфликте?
Естественно! Яндексу нужно было показательно выложить репозиторий на ftp.yandex.ru, а коммиты по E-mail принимать будет лично Платон Щукин.
Можно к ftp прикрутить соцсеть с рекламой и будет Яндекс.Интернет!:)
А технически статья хорошая, мне понравилась.
высок риск, что репозиторий заблочат. причём вместе с форками, т.е. работой сторонних контрибюторов.
сам git-репозиторий не сложно восстановить из локального, но тикеты и пуллреквесты пропадут навсегда
Уже писал)) Когда Яндекс стал иметь отношение к России? Да, он ведет бизнес в России, но главное юридическое лицо зарегистрировано не здесь. Он также еще много где ведет бизнес) Основатель из России? Сергей Брин тоже из России) Но мы же не называем гугл российским )
@olalala
У вас в документации сказано, что "На затронутые в ходе транзакции сущности ставятся оптимистичные блокировки, при завершении транзакции проверяется, что блокировки не были инвалидированы".
Под "сущностями" здесь что подразумевается – таблицы, строки, поля, что-то другое?
Строки. Оптимистические блокировки работают на уровне строк.
Ниже Олег olalala ответил, что "Шард (таблетка) однопоточен, изменения будут выполнены последовательно". Поэтому координатор транзакций, вероятно, при планировании транзакций оперирует не строками, а шардами. И поэтому квантом данных для блокировки здесь, вероятно, является не строка, а шард.
сейчас база визитов содержит больше 100 терабайт данных
А с точки зрения позиционирования вашего продукта есть какая-то хотя бы размытая грань, где уже стоит выбрать YDB или по-прежнему использовать старые добрые MySQL/PostgreSQL итд? Спасибо.
Да как обычно. Пока обычные БД тянут нагрузку без особых костылей - используем их. Как перестали начинаем смотреть А что ещё есть?
О нагрузке стоит думать до написания кода. Чтобы потом срочно не переделывать все.
Например, когда планируется рост нагрузки или объема данных. Даже если на текущий момент проект небольшой — дешевле спроектировать решение с учетом планируемых нагрузок. На практике у нас есть много проектов, которые росли с единиц RPS до сотен тысяч RPS и с мегабайт до десятков терабайт без рефакторинга кода.
По возможностям выглядит как амазоновская DynamoDB с натянутым поверх парсером SQL
я бы сравнил с многострадальной greenplum и сбоку бантик(автоматическое шардирование)
очень сомнительно выглядит, как попытка снизить доступный к разработке уровень квалификации команд.
@olalalaа а есть планы по внесению в реестр Российского ПО?
Это только узкое подмножество задач, которое можно решить с помощью YDB. Именно поэтому мы реализовали поддержку совместимости с DynamoDB API в бессерверном режиме в Yandex Cloud.
А как вы победили CAP-теорему? Что, в итоге, стало слабым звеном?
Раз транзакции оптимистические, то наверное за счёт буквы A.
При обсуждении YDB и теоремы CAP, мне сегодня намекнули, что лучше ей не пользоваться, так как не всё так однозначно (перевод на хабре)
P.S. Моё мнение было, что это CP система, в жертву A
Воу воу воу! Круть!
@olalala
У вас в документации сказано, что "Каждый индекс обслуживается своим набором шардов, и решения о разделении или объединении его партиций принимаются независимо на основании настроек по умолчанию. В будущем эти настройки могут быть сделаны доступными пользователям, аналогично настройкам основной таблицы".
Означает ли это, что сейчас отсутствует возможность управлять шардированием индекса для конкретной таблицы?
Сейчас настройки пользователем параметров партицирования доступны только для таблицы. Для партицирования вторичного индекса применяются специальные эвристики и автоматическое партицирование по нагрузке. В будущем мы планируем дать пользователям возможность изменять эти настройки аналогично настройкам основной таблицы.
@olalala
У вас в документации про шардирование сказано, что "Характерное время операции разделения или объединения — порядка 500 мс. На это время вовлеченные в операцию данные становятся кратковременно недоступны для чтения и записи… Стоит отметить, что если система по каким-то причинам перегружена (например, из-за общей нехватки CPU или пропускной способности выделенных базе дисковых ресурсов) то операции разделения и объединения могут длиться дольше ".
А вот это "характерное время" в 500 мс. откуда взялось? Судя по тексту, оно не зависит от размера самих шардов, а зависит только от загрузки ресурсов CPU/IO – это так надо понимать?
Это действительно "характерное" время в несколько сотен мс. Связано с набором операций, которые нужно выполнить — заблокировать шард на запись, дождаться разбора и выполнения всех операций в очереди шарда, выполнить компакшн, ... (это не весь пайплайн, целиком пайплайн достаточно большой). Системная таблетка SchemeShard, которая отвечает за всю работу со схемой данных, ждёт оповещения о завершении всех этих работ, завершает схемную операцию, публикует изменения.
А где можно почитать про общую архитектуру? из статьи и из оф. документации так до конца и не понял как она устроена.
В кластере один мастер и несколько slave? При этом все запросы идут через мастер и проксируются на рабочие ноды(Tablet), потом результат собирается на мастере и отдается клиенту?
и я так понял под капотам там key->value хранилище?
Можно посмотреть доклад про Distributed Storage и про распределенные транзакции. Больше выступлений и публичных материалов можно посмотреть по ссылке https://cloud.yandex.ru/docs/ydb/public_talks
В кластере один мастер и несколько slave? При этом все запросы идут через мастер и проксируются на рабочие ноды(Tablet), потом результат собирается на мастере и отдается клиенту?
У вас смешаны термины. Мастер есть у каждой таблетки. Мастер у таблетки один. Возможно наличие у таблетки мастера — фолловеров, то есть реплик на чтение. Таблетка очень легковесная сущность — отвечает за хранение не более чем 1-2 GB. Таблеток в кластере может быть очень много. Что вы имеете в виду под нодой? Обычно мы употребляем этот термин в значении сервер.
Насколько легковесна "таблетка"? Может ли она одновременно выполнять более одной читающей операции, или надо множить таблетки для поддержания высокого throughoutput?
Спасибо за ссылки.
Видимо я пока плохо разобрался, попробую перефразировать вопрос.
Точкой подключения для клиента (приложения) что является? какой-то конкретный мастер сервер? Или у вас умный клиент и он сам определяет куда подключится?
У нас клиентская балансировка, первый запрос который выполняет SDK — это ListEndpoints. То есть сначала выполняется Discovery, далее клиент устанавливает соединения с доступными для базы ендпойнтами.
Уточню: в инсталляциях YDB у нас есть нечто похожее на "конкретный мастер", точнее это либо L3-балансер, либо DNS-балансер. Это (начальный endpoint) надо задавать явно. Поэтому первый запрос Discovery/ListEndpoints действительно "выясняет" конфигурацию кластера и дальше работает клиентская балансировка в SDK уже с конкретными нодами YDB.Или у вас умный клиент и он сам определяет куда подключится?
Как будто бы умный клиент получается
Выложить под свободной лицензией код это хорошее дело, спасибо.
Наверное самый интересный вопрос - как вы тестировали ACID в YDB?
Разрабатывали тесты для Jepsen или что-то своё использовали?
@olalala
У вас в документации сказано, что "При выполнении запросов в YDB фактическое выполнение запроса к каждому шарду осуществляется в единой точке, обслуживающей протокол распределенных транзакций. ... данные уже хранятся реплицированно и возможно обслуживание более одного читателя (но писатель при этом все еще в каждый момент строго один)".
Поясните фразу "писатель при этом все еще в каждый момент строго один". Означает ли это, что два непересекающихся множества строк в одном шарде не могут параллельно изменяться двумя разными приложениями при том, что каждое приложение изменяет только "свое" множество строк?
Платежи через использование YDB идут?, или (пока?) мимо,- через другие механизмы?
PS Вопрос скорее о доверии разработанному механизму ACID ...
Большое спасибо. А есть ли минимальные требования? Т.е. если сравнить ydb использование с postgee будет ли выигрыш по деньгам, скажем на представленном тестовом магазине? Т.е. есть ли смысл её использовать в небольших проектах в надежде обойтись 'стандартным' хостингом? Я понимаю, как это звучит, но всё же?
Вместо стандартного хостинга вам вероятно лучше подойдёт YDB как managed service.
Я бы даже рекомендовал посмотреть в сторону serverless YDB в Yandex.Cloud. Пока ваш магазин маленький - плата ничтожная. Если начнет лавинообразно расти нагрузка (например в случае успеха продвижения товаров/бренда/магазина) - произойдет автомасштабирование, соответственно пропорционально вырастут расходы на сервис. О железе/хостинге думать вообще не надо
Спасибо!
If you know what i mean https://github.com/ydb-platform/ydb/search?q=kikimr
Континуес квери поддерживает как в RAVENDB ?
В документации не вижу как сделать авторизацию, к примеру через Access Token. Сейчас в self-hosted это не поддерживается?
Путь к популярности лежит через реализацию интеграций. Например реализацию spring data commons :)
Правильно ли я понял правила работы Serverless YDB: если я использую меньше гигабайта данных, и до миллиона RU в месяц (и до 100 RPS), то сервис будет для меня бесплатным.
Мой телеграм бот делает примерно 200-300 запросов в сутки, и я его могу подключить просто нахаляву, а когда он наберет гигабайт данных - начнут списывать по 20 рублей в месяц. Все верно? Или есть тарификация чего-то еще, чего я не заметил?
На бессерверный режим YDB действуют специальные тарифы, в рамках которых определенный объем услуг не тарифицируется.
Каждый месяц не тарифицируются первые:
1 000 000 операций (в единицах Request Unit);
1 ГБ/месяц хранения данных.
Хранение данных, свыше 1 ГБ в месяц стоит 21,3800 ₽ за 1 ГБ в месяц.
То есть до определенного уровня потребления действительно можно пользоваться "нахаляву". Без скрытых списаний.
Планируется ли добавление поддержки диалекта в продукты jetbrains?
Спасибо огромное. На майских буду тестить и если понравится - насаждать добро среди наших датаинженеров.
А как YDB позиционирует себя относительно ClickHouse? Это "более современная" замена ему? Или у них принципиально разные сферы применимости?
Полагаю, разные хранилища и для разных целей.
ClickHouse нацелен на огромные объемы операций записи (натурально каждый клик), и редкие запросы на чтение, которые по этим данным собирают агрегированную статистику.
Классические базы данных (и YDB) подразумевают большие объемы чтения и малые записи: мы показываем магазин чаще, чем покупаем в нем, или меняем цены.
Ну и, исходя из задач, появляются разные особенности использования, функционал, синтаксис, гарантии и т.п.
Поправьте, если я не прав.
Это не так. Вы приводите только один из множества примеров типов нагрузки, они могут быть совершенно различными. Соотношения чтение/запись также могут быть очень разными.
Например базовый набор нагрузок для теста KV СУБД YCSB содержит несколько типов соотношений чтение/запись: 50/50, 95/5, 100/0.
Они разные.
Кликхаус это аналитическая БД. Посчитать агрегат по сотням миллионов строк.
YDB это ближе к kv. Читать и писать по ключу небольшие объемы за раз, но с огромным rps.
ClickHouse это аналитическая СУБД. YDB - база данных для операционной (OLTP) нагрузки. То есть обеспечивает большой и легко масштабируемый поток транзакций, каждая из которых читает/пишет/изменяет небольшой объём данных, при этом каждая из транзакций выполняется за относительно небольшое время, так как запросы часто интерактивны.
При попытке создать симулятор скалад интернет-магазина выдает:
ydb -e grpc://localhost:2136 -d /local workload stock init -p 100 -q 1000 -o 1000
Query execution failed: <main>: Error: Execution, code: 1060
<main>:1:150: Error: Operation aborted due to constraint violation: insert_pk, code: 2012
Query:
--!syntax_v1
DECLARE $stocks AS List<Struct<product:Utf8,quantity:Int64>>;
INSERT INTO `stock`(product, quantity) SELECT product, quantity from AS_TABLE( $stocks );в чем может быть проблема?
Планируется ли выпуск JDBC драйвера?
Да, экспериментальная версия уже доступна https://github.com/yandex-cloud/ydb-java-sdk/tree/master/jdbc
почему в отличии от катбуста в сборке не ymake ?
Спасибо за продукт! Но, хочется продукт со встроенными функциями как в oracle, типа регулярок и пр. , таким etl-инструментом как в mssql, типа SSDT, чтобы можно было мигрировать данные из одной бд в другую ssis пакетами и такую же скорость чтения данных, как в greenplum. Вот тогда ваш продукт с руками оторвут все банки :). Будете ли вы развивать ваш проект до вышеуказанных сущностей? Потому что просто бд не особо интересна для крупняков.
Извините за сарказм, но "если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому ещё дородности Ивана Павловича — я бы тогда тотчас же решилась".
Понятно что хочется взять лучшее от всех продуктов на рынке СУБД, которые были произведены за последние 50 лет и воплотить их в одном. Но это не так просто сделать. Безусловно мы будем развивать наш проект, будем пристально следить за наиболее востребованными фичами, смотреть на запросы пользователей.
Ну, я вам подсказываю, что сейчас интересно в банковской сфере :). И это не просто хотелки, а основные наши каждодневные задачи!!! И мы плачем, потому что уже нас заблокировали по обслуживанию и обновлениям и продлениям лицензий mssql, oracle, а замены пока нет. И нам нужна бд с etl инструментами срочно...
Вообще, я думаю, что нам такое пригодится!
А есть ссылка на описание механизма блокировок?
Можно посмотреть доклад "Распределенные транзакции в YDB".
Network Block Store, который поверх YDB ожидать в OpenSource? Или губу раскатал?
Круто, молодцы!
Спасибо за такой интересный инструмент!
А что с хранимыми процедурами? Есть возможность добавить и использовать? Не нашел ни в доке, ни в онлайн консоли
А где лучше искать специалиста YDB?
Яндекс выложил в опенсорс YDB