Comments 17
И в чем могут быть преимущества от использования DuckDB вместо классической MySQL 8 на простом VDS-хостинге?
Автор здесь не описывает, однако DuckDB поставляется в виде библиотек и cli. И вот cli - штука крутая, анализировал ей наборы данных в миллионы записей.
Задачи по типу "собрать айдишки из csv/экселя и выявить дубликаты" спокойно решается прямо из DuckDB: SELECT * FROM 'data.csv' WHERE id IN (SELECT id FROM 'data.csv' GROUP BY id HAVING COUNT(*) > 1). Или другими запросами, у вас по-сути на руках sqlite с фичами pg и не только. При работе с экселем потребуется расширение, которое входит в состав duckdb из коробки.
Добрый день.
Разные инструменты под разные задачи.
MySQL про OLTP нагрузку, а DuckDB про OLAP нагрузку.
Также DuckDB позиционируется как инструмент для Data Lake/ Data LakeHouse, потому что он позволяет вынести compute за рамки storage.
DuckDB – это просто лучший инструмент для взаимодействия с данными.
Как-то желание отпадает читать статью, которая начинается с таких громких заявлений. Даже если вдруг написанное впоследствии оказывается близким к правде.
Технари так не делают, это стиль рекламщиков
Очередная суперхренорезка, которая умеется все сразу и ничего по настоящему в отдельности?
В чем польза от продукта, ну кроме как лабораторных опытов для гиков в стиле "ой, а еще оно в гамаке и стоя умеет"?
И Android не поддерживается, если я не ошибаюсь ?
Для начала возьмём ранее использовавшийся файлик с поездками такси и создадим из него таблицу:
CREATE TABLE yellow_tripdata_2024_01
SELECT * FROM read_parquet('https://d37ci6vzurychx.cloudfront.net/trip-data/yellow_tripdata_2024-01.parquet'Так и не понял, как данный код сохраняет данные parquet файла в локальной базе
А что именно не понятно?
Вот к примеру в официальной документации PostgreSQL описан механизм создания таблицы.
Что-то сложнее COUNT(*) пробовали запускать? У меня вот как-то не сложилось. Натравил на директорию с parquet-файлами. Нужно было воспроизвести логику с DENSE_RANK и GROUP BY, запрос все время вылетал по памяти. Один из вариантов запросов для решения той же проблемы наоборот стал вечно крутиться. Пришлось обрабатывать все файлы в цикле и склеивать каждый новый файл с результатами обработки всех предыдущих. Особо деталей не приведу, так как было давно, но суть в том, что была надежда просто написать SQL и получить результат, но магии не случилось, поэтому пришлось писать код.
На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить .parquet файлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.
Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл .csv в котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.
На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить .parquet файлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.
Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл .csv в котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.
Всё что нужно знать про DuckDB