DuckDB 2.0 читает данные с S3 в три раза быстрее
Why DuckDB 2.0 is faster
DuckDB 2.0, альфа-версия которого уже вышла, ускоряет чтение с S3 в 2–3 раза без изменения запросов: отдельный пул потоков загружает row groups наперёд, пока воркеры декодируют. Рекурсивные CTE переписаны — обход 20 000 коммитов ускорился с 1,8 с до 0,10 с. Новый тип VARIANT с «шредингом» полей занимает в 2,7 раза меньше места, чем JSON-строка, а фильтры по нему работают в 6 раз быстрее парсинга JSON. Автор делится замерами на ноутбуке M5 и скрытыми находками из коммитов.
Network and CPU are busy at the same time.
- scythmic_waves
Мне тоже нравятся визуализации, но от текста сильно отдаёт LLM:
> Одна настройка управляет этим,...
> Стоимость теперь зависит от строк, к которым вы реально обращаетесь, а не от количества раундов, умноженного на размер таблицы.
И т.д.
У меня мозг закипает [1], когда я пытаюсь разобрать этот стиль письма на работе, так что мне неприятно видеть его где-то ещё. Извиняюсь, если ошибаюсь. Но если нет, то OP, не используй LLM для написания текстов. Это вредно для здоровья твоих читателей [2].
[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q
[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...
- stacktraceyo
Отличная визуализация. Кстати, их новый C++ API для расширений также станет быстрее с точки зрения разработки и распространения этих расширений.
- robertclaus
Я нормально относился к тексту, написанному ИИ, пока не дошёл до того, что в 2.0 добавили триггеры, а статья решила, что это ерунда по сравнению с оптимизацией воркеров для доступа к файлам на S3 при медленном соединении. Нет уж. Я сам прочитаю release notes.
- rumbledownunda
Попробую в следующем jupyter notebook.
- jiggawatts
Хотел бы я, чтобы больше движков баз данных использовали дизайн на основе задач, как Umbra / CedarDB.
Большинство существующих СУБД, похоже, всё ещё используют параллелизм в стиле «n-потоков» с операциями обмена и плохим управлением асинхронным вводом-выводом.
DuckDB улучшается в этом направлении, но в некотором смысле догоняет R&D (и реализацию!), которым уже десятилетия.
«Риторический вызов», который я люблю бросать разработчикам, работающим над подобными системами, звучит так: если бы я дал вам компьютер с 1024 ядрами и соответствующей пропускной способностью сети и хранилища — но со значительной задержкой — смогли бы вы поддерживать такую систему загруженной на 100% с помощью одного запроса?
Ответ для почти любого ПО — «нет».
Например, SQL Server упирается в 64 аппаратных потока для любого одного запроса: https://learn.microsoft.com/en-us/sql/database-engine/config...
GPU-код начинает к этому приближаться, но CPU-код сильно отстаёт на этом фронте информатики.
И это не только базы данных! Можете ли вы (де)компрессировать файл параллельно? Проверить его хеш параллельно? Загрузить/выгрузить из хранилища с параллелизмом задач CPU и ввода-вывода? Можете ли вы перекрыть все эти операции так, чтобы ничто никогда не ждало чего-то другого без необходимости?
Это важно! Я провёл несколько тестов с биоинформатическими программами и обнаружил, что большинство застревают в смоляных ямах. Многие не могли масштабироваться под современные SSD с миллионами IOPS или современные сети с сотнями гигабит пропускной способности, сколько бы ядер CPU им ни давали.
PS: процессоры AMD EPYC 9006 эпохи Zen 6 будут иметь 51 […]