Таблетка однопоточна. Для масштабируемости throughput мы партицируем таблицу на таблетки. Есть возможность настроить автоматический сплит по размеру или по нагрузке.
В кластере один мастер и несколько slave? При этом все запросы идут через мастер и проксируются на рабочие ноды(Tablet), потом результат собирается на мастере и отдается клиенту?
У вас смешаны термины. Мастер есть у каждой таблетки. Мастер у таблетки один. Возможно наличие у таблетки мастера — фолловеров, то есть реплик на чтение. Таблетка очень легковесная сущность — отвечает за хранение не более чем 1-2 GB. Таблеток в кластере может быть очень много. Что вы имеете в виду под нодой? Обычно мы употребляем этот термин в значении сервер.
Сейчас настройки пользователем параметров партицирования доступны только для таблицы. Для партицирования вторичного индекса применяются специальные эвристики и автоматическое партицирование по нагрузке. В будущем мы планируем дать пользователям возможность изменять эти настройки аналогично настройкам основной таблицы.
Это только узкое подмножество задач, которое можно решить с помощью YDB. Именно поэтому мы реализовали поддержку совместимости с DynamoDB API в бессерверном режиме в Yandex Cloud.
Например, когда планируется рост нагрузки или объема данных. Даже если на текущий момент проект небольшой — дешевле спроектировать решение с учетом планируемых нагрузок. На практике у нас есть много проектов, которые росли с единиц RPS до сотен тысяч RPS и с мегабайт до десятков терабайт без рефакторинга кода.
Пока не готовы точно сказать про версию стандарта, но безусловно будем учитывать и уже поддержанную в YDB функцинальность, такую как поддержка JSON (поддержка синтаксиса появилась в ANSI SQL 2016) и планы по будущей функциональности.
На единицах RPS можно воспользоваться managed сервисом в serverless режиме.
Блокировка берется на диапазоны ключей затронутых запросом.
Спасибо за поправку, когда писал на автомате добавил ANSI.
Шард (таблетка) однопоточен, изменения будут выполнены последовательно
Таблетка однопоточна. Для масштабируемости throughput мы партицируем таблицу на таблетки. Есть возможность настроить автоматический сплит по размеру или по нагрузке.
Это первое название YDB.
У нас в родмапе есть сравнительный анализ с различными конкурентами. Постепенно будем готовить статьи.
Вместо стандартного хостинга вам вероятно лучше подойдёт YDB как managed service.
У вас смешаны термины. Мастер есть у каждой таблетки. Мастер у таблетки один. Возможно наличие у таблетки мастера — фолловеров, то есть реплик на чтение. Таблетка очень легковесная сущность — отвечает за хранение не более чем 1-2 GB. Таблеток в кластере может быть очень много. Что вы имеете в виду под нодой? Обычно мы употребляем этот термин в значении сервер.
Сейчас настройки пользователем параметров партицирования доступны только для таблицы. Для партицирования вторичного индекса применяются специальные эвристики и автоматическое партицирование по нагрузке. В будущем мы планируем дать пользователям возможность изменять эти настройки аналогично настройкам основной таблицы.
Это только узкое подмножество задач, которое можно решить с помощью YDB. Именно поэтому мы реализовали поддержку совместимости с DynamoDB API в бессерверном режиме в Yandex Cloud.
Например, когда планируется рост нагрузки или объема данных. Даже если на текущий момент проект небольшой — дешевле спроектировать решение с учетом планируемых нагрузок. На практике у нас есть много проектов, которые росли с единиц RPS до сотен тысяч RPS и с мегабайт до десятков терабайт без рефакторинга кода.
Думаем про это, учитываем при формировании планов на будущее. Пока используем свою систему тестирования.
Пока не готовы точно сказать про версию стандарта, но безусловно будем учитывать и уже поддержанную в YDB функцинальность, такую как поддержка JSON (поддержка синтаксиса появилась в ANSI SQL 2016) и планы по будущей функциональности.
Можно посмотреть доклад про Distributed Storage и про распределенные транзакции. Больше выступлений и публичных материалов можно посмотреть по ссылке https://cloud.yandex.ru/docs/ydb/public_talks
У нас своя система тестирования
да
тоже да
Про причины появления достаточно подробно написал мой коллега в статье про YQL. Мы в целом стремимся к максимальному сближению с ANSI SQL.
Ничего сложного, синтаксис YQL очень близок к ANSI SQL.
Это вопрос скорей к авторам userver @antoshkka