Миллионы баз данных не должны ходить в один центр за каждым запросом
В Cloudflare D1 каждая база опирается на отдельный SQLite Durable Object. Баз можно создать миллионы — но центральный каталог их расположения легко превратить в узкое место.
В разборе архитектуры D1 показано разделение работы. Создание, удаление и другие управляющие операции используют центральный PostgreSQL. Для выполнения SQL маршрутизационные метаданные читаются через распределённый Workers KV и кеши.
Запросу к базе обычно не требуется обращаться к центральному каталогу. А фоновые heartbeat-сообщения сверяют состояние объектов с PostgreSQL и помогают исправлять последствия частично выполненных операций.
Например, объект создали, но запись в каталог не удалась. Следующая сверка обнаружит, что такой базы нет, и позволит убрать оставшийся объект.
В Cloudflare D1 каждая база опирается на отдельный SQLite Durable Object. Баз можно создать миллионы — но центральный каталог их расположения легко превратить в узкое место.
В разборе архитектуры D1 показано разделение работы. Создание, удаление и другие управляющие операции используют центральный PostgreSQL. Для выполнения SQL маршрутизационные метаданные читаются через распределённый Workers KV и кеши.
Запросу к базе обычно не требуется обращаться к центральному каталогу. А фоновые heartbeat-сообщения сверяют состояние объектов с PostgreSQL и помогают исправлять последствия частично выполненных операций.
Например, объект создали, но запись в каталог не удалась. Следующая сверка обнаружит, что такой базы нет, и позволит убрать оставшийся объект.
👍7🔥2👏2🙊2❤1😢1🎉1🍌1💋1🗿1😎1
Два ядра CPU на одном сервере могут стоить трёх на другом
В платформе Odin у Uber есть разные поколения x86 и ARM. Производительность одного ядра между крайними вариантами отличается почти вдвое. Одинаковый лимит CPU даёт разный запас мощности.
Для сервисов с данными это особенно неприятно: при смене лидера нагрузка может переехать на более медленный сервер.
В Uber ввели нормализованные вычислительные единицы. Потребление переводят в общую шкалу с коэффициентом производительности хоста. По ней рассчитывают нужную мощность, затем переводят её обратно в число ядер конкретной машины.
Одних синтетических тестов не хватило. Коэффициенты уточняют по продакшену отдельно для разных технологий: Cassandra и Kafka по-разному используют одно железо. Универсальная оценка «этот сервер быстрее на 30%» здесь теряет точность.
В платформе Odin у Uber есть разные поколения x86 и ARM. Производительность одного ядра между крайними вариантами отличается почти вдвое. Одинаковый лимит CPU даёт разный запас мощности.
Для сервисов с данными это особенно неприятно: при смене лидера нагрузка может переехать на более медленный сервер.
В Uber ввели нормализованные вычислительные единицы. Потребление переводят в общую шкалу с коэффициентом производительности хоста. По ней рассчитывают нужную мощность, затем переводят её обратно в число ядер конкретной машины.
Одних синтетических тестов не хватило. Коэффициенты уточняют по продакшену отдельно для разных технологий: Cassandra и Kafka по-разному используют одно железо. Универсальная оценка «этот сервер быстрее на 30%» здесь теряет точность.
😐8👍4💘2⚡1🔥1😁1🌚1💋1🙈1🙉1😘1
Старый токен Docker Hub получал права нового владельца
При превращении личного аккаунта в организацию Docker Hub переносил его PAT-токены указанному владельцу. Сам секрет токена оставался прежним, а согласия нового владельца не требовалось.
Поэтому известный создателю аккаунта токен мог начать работать в реестре от имени другого пользователя. В пределах разрешений он позволял обращаться к образам, включая их публикацию или удаление.
Docker опубликовал разбор CVE-2026-105445. Ошибку исправили 30 сентября: перенос PAT убрали. Проверка примерно 304 тысяч публикаций образов с перенесёнными токенами не выявила признаков эксплуатации.
Доступ к веб-интерфейсу и смене пароля ошибка не давала. Урок для проектирования доступа: смена владельца объекта требует отдельной проверки того, что происходит с уже выданными учётными данными.
При превращении личного аккаунта в организацию Docker Hub переносил его PAT-токены указанному владельцу. Сам секрет токена оставался прежним, а согласия нового владельца не требовалось.
Поэтому известный создателю аккаунта токен мог начать работать в реестре от имени другого пользователя. В пределах разрешений он позволял обращаться к образам, включая их публикацию или удаление.
Docker опубликовал разбор CVE-2026-105445. Ошибку исправили 30 сентября: перенос PAT убрали. Проверка примерно 304 тысяч публикаций образов с перенесёнными токенами не выявила признаков эксплуатации.
Доступ к веб-интерфейсу и смене пароля ошибка не давала. Урок для проектирования доступа: смена владельца объекта требует отдельной проверки того, что происходит с уже выданными учётными данными.
❤2⚡1🤓1