Комментарии 6
Получилась какая-то странная рекламная статья, из которой ничего не понятно, хотя тема сложная и интересная.
Во-первых, можно рассказать, кто такой Кальвин – на русском языке информации практически нет. А если сдобрить рассказ лирическими отступлениями из переписки на форумах между Cockroach и Yugabyte (читай Google Spanner vs. YandexDB) – получилось бы ещё интереснее.
Во-вторых, механизм детерминированных транзакций рассчитан исключительно на модель «ключ/значение», а адаптация этого механизма под реляционную модель как минимум не очевидна и составляет ноу-хау Яндекса. Тоже есть о чём рассказать.
В-третьих, так и непонятно, при чём тут serverless – ведь биллингу можно научить любую СУБД. Вот если бы вы нарисовали архитектурную диаграмму чуть по-другому, чтобы сразу было видно, что бОльшая часть компонентов – без состояния, а состояние появляется только в самом низу, это было бы намного интереснее.
В-четвёртых, крайне интересно было бы увидеть результаты нагрузочных тестов. Как минимум, чтобы чётко понимать, для каких задач эта система точно неприменима.
В-пятых, вопросы безопасности не затронуты вообще никак. Хотя, насколько мне известно, этой теме и сами разработчики не уделяют должного внимания.
И, наконец, совершенно непонятен механизм резервного копирования. Последнее, что я слышал на эту тему, «оно не может совсем умереть, т. к. сильно распределённое». Подход хороший, но для бизнес-приложений абсолютно неприменимый.
Во-первых, можно рассказать, кто такой Кальвин – на русском языке информации практически нет. А если сдобрить рассказ лирическими отступлениями из переписки на форумах между Cockroach и Yugabyte (читай Google Spanner vs. YandexDB) – получилось бы ещё интереснее.
Во-вторых, механизм детерминированных транзакций рассчитан исключительно на модель «ключ/значение», а адаптация этого механизма под реляционную модель как минимум не очевидна и составляет ноу-хау Яндекса. Тоже есть о чём рассказать.
В-третьих, так и непонятно, при чём тут serverless – ведь биллингу можно научить любую СУБД. Вот если бы вы нарисовали архитектурную диаграмму чуть по-другому, чтобы сразу было видно, что бОльшая часть компонентов – без состояния, а состояние появляется только в самом низу, это было бы намного интереснее.
В-четвёртых, крайне интересно было бы увидеть результаты нагрузочных тестов. Как минимум, чтобы чётко понимать, для каких задач эта система точно неприменима.
В-пятых, вопросы безопасности не затронуты вообще никак. Хотя, насколько мне известно, этой теме и сами разработчики не уделяют должного внимания.
И, наконец, совершенно непонятен механизм резервного копирования. Последнее, что я слышал на эту тему, «оно не может совсем умереть, т. к. сильно распределённое». Подход хороший, но для бизнес-приложений абсолютно неприменимый.
Спасибо за перечень интересующих вас тем, учтем при написании серии статей про YDB. Что касается механизма резервного копирования — есть механизм автоматических резервных копий (Yandex Database автоматические создает и бесплатно хранит 2 полные резервные копии ваших баз за два последних дня) и механизм резервных копий по требованию, запуском и конфигурацией которых управляет пользователь. Описание механизмов резервного копироования доступно в документации.
следующий шаг в направлении дальнейшего снижения налога на инфраструктуру
Я уже хочу матюкаться от этой непрерывной лжи.
Нет снижения. Есть совершенно конские ценники для пользователей.
Выиграть в цене можно только в двух вариантах.
В случае наличия своего персонального большого облака (а не кусочка в амазон, ажур, гугле, яндексе или ещё где). Где вы оптимизируете загрузку железа.
Или же при очень специфическом профиле нагрузки, который дай бог у 0.1% пользователей встречается...
Мы планируем серию статей про внутреннее устройство Yandex Database, пишите в комментариях, какие темы наиболее интересны.
Мы это кто?
ACID это хорошо. Насколько сильно уменьшает производительность поддержка Durability?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бессерверная альтернатива традиционным базам данных