Зачем кластер, если 100 млн записей влезают на SSD?
21 октября вышла DuckDB 2.0. У меня она стоит в рабочем проекте, так что релиз читал внимательно.
Смешное там вот что. DuckDB делали как базу без сервера, а в 2.0 добавили сервер. Один из создателей так и сказал: мы сделали базу без сервера, а люди продолжили просить сервер.
Ещё CLI сам понимает, что его запустил агент, и отвечает компактным Markdown. Токенов на выводе на 59% меньше. При этом общая стоимость работы агента заметно не снизилась. Читает меньше, тратит столько же, очень жизненно.
Но меня зацепила их старая статья. Медианный запрос в Redshift и Snowflake сканирует около 100 МБ. Сто мегабайт, и под это поднимают облачные хранилища.
А MacBook за $700 с 8 ГБ памяти на холодном прогоне ClickBench выдал медиану 0,57 секунды. Облачная машина на 192 vCPU показала 1,54. На горячем прогоне облако, правда, обогнало ноутбук на порядок.
У меня аналитическая платформа по госзакупкам, больше 100 млн записей: контракты из ЕИС и отчёты ФНС. Всё лежит в DuckDB и ClickHouse поверх Parquet и занимает 20–22 ГБ на одном SSD. Запросы отвечают за 1–15 мс.
Обновляться пока не спешу. Файлы 2.0 старые версии не читают, откатиться будет сложно.
Сколько у вас данных на самом деле? Влезли бы на один SSD, или без кластера правда никак?
· вчера
Кластер нужен для другого. Если сдохнет ваш ноутбук - пострадаете только вы. Если сдохнет сервер (в единственном экземпляре) - пострадают все пользователи на этом сервере. Поэтому и собирают кластера, чтобы в случае сбоя (или выхода из строя одного из серверов) другие узлы кластера распределили между собой нагрузку и вся система продолжила работу.
Кстати, можете проверить, сколько времени вы будете восстанавливать свою работу после выхода из строя вашего ноутбука: закройте его крышку, отключите электропитание, начинайте считать его вышедшим из строя и приступайте к восстановлению работы. Начать можно с приобретения нового ноутбука
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён