Если упростить, то Liquibase выполняет в порядке очереди то, что вы указали. Соответственно если у вас есть данные и не стоит никаких ограничений, то данные удалятся. А иначе нет.
А по факту, такие операции надо тестировать в вашей БД, возможно понадобится добавить больше ALTER конструкций.
На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить .parquet файлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.
Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл .csv в котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.
На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить .parquet файлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.
Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл .csv в котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.
minio – нужен для общения с Minio pandas – для чтения удаленного .csv и удобной работы с ним fsspec – необходимый пакет для записи в S3 s3fs – необходимый пакет для записи в S3
Не слышал о такой проблеме. Вообще, объём WAL для того же PostgreSQL можно настроить и время хранения данных в топиках Kafka тоже настраивается, но по дефолту семь дней.
Ну и кажется по логике, что влияние топика/продюсера не должны повлиять, что где-то что-то сломается, потому что они все независимы.
Я же могу писать в топик, но не читать оттуда (нет продюсера)
На момент реализации данного решения нас это устраивало и сейчас устраивает, так как основной оркестратор в компании – это Airflow
Да, возможно, и изврат, но об этом также написано, что это решение моего бизнес-кейса. Возможно в дальнейшем он покажет свою несостоятельность и мы его изменим, когда увеличится список компетенций и/или технологий.
У меня не было задачи "продавать" данное решение. Оно не идеальное, но оно отвечает нашему запросу. Оно работает и приносит пользу – для нас это главное.
Возможно в будущем я сделаю часть "два", в которой раскритикую своё предложение и покажу что-то другое. На текущий момент – это описание моего опыта и бизнес-кейса.
uv просто набирает популярность, как и Ruff от тех же разработчиков.
uv просто интересный проект, который позволяет многое ускорить, как и ruff
Будет то, что вы пропишите.
Если упростить, то Liquibase выполняет в порядке очереди то, что вы указали. Соответственно если у вас есть данные и не стоит никаких ограничений, то данные удалятся. А иначе нет.
А по факту, такие операции надо тестировать в вашей БД, возможно понадобится добавить больше
ALTERконструкций.Open Source – https://github.com/dbt-labs/dbt-core
Также предлагают dbt-cloud, в которых будут сразу все коннекты, шедулер и прочие плюшки, вот с ним явно будут проблемы.
Но само ядро dbt Open Source.
Спасибо за комментарий. Такие редко вижу :)
На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить
.parquetфайлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл
.csvв котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.На практике был опыт такого кейса. Тут стоит обратить внимание на то, что вы запускали скрипт в оперативной памяти и тут действительно может не вывезти хранение файлов внутри памяти.
Как вариант – это сохранить
.parquetфайлы внутри DuckDB как таблицы и уже считать при помощи его движка. Иначе никак.Ну или просто закидать проблему оперативкой.
Я пытался как-то прочитать файл
.csvв котором было несколько миллиардов строк (дамп PG таблицы) и через простое чтение тоже хватал ошибки по памяти, но а когда загрузил в DuckDB эту информацию, то запросы работали. Не скажу что быстро, но зато работали и я смог разбить файл на нужные мне партиции.А что именно не понятно?
Вот к примеру в официальной документации PostgreSQL описан механизм создания таблицы.
Это кликбейт, прошу понять и простить 🙂
path/key – это просто терминология, которая используется внутри команды. Не проблема говорить и Key.
Всё зависит от команды, потому что некоторые могут это воспринять как key-value хранилище, которое таковым не является.
Но спасибо, что об этом упомянули, я считаю, что это важно для читателя.
Я тут и не говорил, что Minio является отцом всех отцов. Спасибо, что упомянули про AWS. Я думаю, что читателям это будет полезно.
Minio – это LikeS3, да, но это Open Source и использовался для демо, для туториала, для новичков, что отмечено в заголовке статьи.
Слышал. Но это демонстрация и не более. Если у сервиса есть своё API, то почему бы его и не использовать?
Спасибо что подметили. Да, у DuckDB удобный CLI я через него работал на VDS.
Добрый день.
Разные инструменты под разные задачи.
MySQL про OLTP нагрузку, а DuckDB про OLAP нагрузку.
Также DuckDB позиционируется как инструмент для Data Lake/ Data LakeHouse, потому что он позволяет вынести
computeза рамкиstorage.minio – нужен для общения с Minio
pandas – для чтения удаленного .csv и удобной работы с ним
fsspec – необходимый пакет для записи в S3
s3fs – необходимый пакет для записи в S3
minio==7.2.7
pandas==2.2.2
fsspec==2024.6.1
s3fs==2024.6.1
Не слышал о такой проблеме. Вообще, объём WAL для того же PostgreSQL можно настроить и время хранения данных в топиках Kafka тоже настраивается, но по дефолту семь дней.
Ну и кажется по логике, что влияние топика/продюсера не должны повлиять, что где-то что-то сломается, потому что они все независимы.
Я же могу писать в топик, но не читать оттуда (нет продюсера)
Согласен. О чем я вкратце написал в статье.
Изменил настройки. Теперь всё доступно.
Добрый день.
Спасибо за ваш комментарий.
Отвечу сразу на два комментария.
На момент реализации данного решения нас это устраивало и сейчас устраивает, так как основной оркестратор в компании – это Airflow
Да, возможно, и изврат, но об этом также написано, что это решение моего бизнес-кейса. Возможно в дальнейшем он покажет свою несостоятельность и мы его изменим, когда увеличится список компетенций и/или технологий.
У меня не было задачи "продавать" данное решение. Оно не идеальное, но оно отвечает нашему запросу. Оно работает и приносит пользу – для нас это главное.
Возможно в будущем я сделаю часть "два", в которой раскритикую своё предложение и покажу что-то другое. На текущий момент – это описание моего опыта и бизнес-кейса.
Спасибо за замечание.