После шести лет разработки представлен выпуск СУБД DuckDB 1.0, позиционируемой как вариант SQLite для аналитических запросов. DuckDB сочетает такие свойства SQLite, как компактность, возможность подключения в форме встраиваемой библиотеки, хранение БД в одном файле и удобный CLI-интерфейс, со средствами и оптимизациями для выполнения аналитических запросов, охватывающих значительную часть хранимых данных, например, выполняющих агрегирование всего содержимого таблиц или слияние нескольких больших таблиц. Код проекта написан на языке C++ и распространяется под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61309
Когда переменные начинают крякать это я понимаю. Но когда начинают крякать целые базы данных это уже явная девиация.
Пробовал несколько месяцев назад, надо было подмёрживать небольшую таблицу к большой (несколько сотен ГБ), которая лежит в паркетах на HDFS. Т.е. простой мёрж, никаких там группировок на всех данных. Так вот, если искусственно скармливать этой утке небольшие чанки от большой таблицы - то вывозит. А если сразу всё, то падает с ошибкой выделения памяти, хотя свободной памяти на серваке ещё. Интересно, пофиксили ли.
Может ты просто не правильно делаешь булк инсерт?
Причём тут булк инсерк? У меня есть несколько сотен ГБ в паркетах, к ним нужно примёржить пару МБ и получить результат (тоже пару МБ). Всё это из питона.
Так и говорите терминами хотя-бы свойственных базам данных, делаете джоин - так делайте меньшее в большее т.к. базе в ином случае нужно хранить в памяти все ключи первой таблицы и она пошлет вас на три буквы если датасет окажется слишком большим
Так разрабы этой субд как раз хвалились, что она у них для больших данных и типа умеет не тащить всё в память, а при необходимость работать с большими таблицами даже если в память всё не влезает. А в моём случае ещё и памяти свободной на серваке было завались. А по факту оказалось, что ей надо на чанки все равно бить. Ну и нафига оно тога нужно?
Без кода гадать по комментам что где и почему упало бессмысленно. Может у тебя там в цикле все паркеты в память читаются.
> Так разрабы этой субд как раз хвалились, что она у них для
> больших данных и типа умеет не тащить всё в память, а
> при необходимость работать с большими таблицами даже если в память всё
> не влезает. А в моём случае ещё и памяти свободной на
> серваке было завались. А по факту оказалось, что ей надо на
> чанки все равно бить. Ну и нафига оно тога нужно?кликхаус тоже хвалится что может в большие данные, но большее в меньшее точно так-же вызовет повышенный расход памяти, то что оно может - эт не значит что головой думать не надо
> Так и говорите терминами хотя-бы свойственных базам данных, делаете джоинюнион что такое?
>> Так и говорите терминами хотя-бы свойственных базам данных, делаете джоин
> юнион что такое?Юнион не даст результат в пару мегабайт при подаче на вход множества гигабайт
> Юнион не даст результат в пару мегабайт при подаче на вход множества
> гигабайт"""
Т.е. простой мёрж, никаких там группировок на всех данных.
"""что такое "простой мОрж" двух множест?
так join вроде не фишка этих баз, она columnar?ну 200 гигов нормальная реляционка без проблемы вывезет на join
вопрос там только в том сколько из этих 200 гигов тебе надо отдать и сколько там будет index scan
Она умеет в join, но при неоптимальном запросе spillover может быть неприлично большим.
https://duckdb.org/docs/configuration/pragmas#temp-directory...
Не 32-битная версия СУБД и/или клиента, случаем?
А зачем в таком встраиваемом формате хранят такие объёмы? Не знал, тут же полноценную RDBMS уже можно.
RDBMS медленнее и намного. Колоночное хранение рулит. Большинство сравнений бессмысленны без понимания специфики данных. Например, большинство SQL-запросов к БД у экономистов читают 10% строк и многоуровнево группируют с множ. отборами. С такими данными и запросами DuckDB очень быстр. Та же SQLite примерно в 2,5 раза тормознее (но все же быстрее сетевых БД).
Результат EXPLAIN ANALYZE в студию. А там посмотрим.
Может, утку неправильно приготовили.
Знаю вопрос глупый, но нафига очередная база данных? Имеющихся мало? Какое уникальное торговое предложение (УТП) сабжа?
Вот допустим ищу я вакансию Девопса, в вакансиях в разделе знания БД у всех разные названия. Я думал что в ИТ принято перенимать лучшие практики? Нафига этот зоопарк?
Потому что если ты знаешь допустим мускуль ты уточнишь в выдаче среди конкурентов. А когда ты знаешь какую то мутную фигню, которая почему то понадобилась эйчеру ты будешь возможно даже на первой странице.А зачем кто-то стал это искать сотрудников для работы с фигнёй? Например потому что повелся на маркетинговый буль-щит.
>А когда ты знаешь какую то мутную фигню, которая почему то понадобилась эйчеру ты будешь возможно даже на первой странице.Ну и вакансий будем меньше и не факт что ЗП будет больше.
Описание читал? Если да, то какие аналоги?
А ты читал?
>позиционируемой как вариант SQLite для аналитических запросов.
Какие аналоги?
> Знаю вопрос глупый, но нафига очередная база данных? ... Нафига этот зоопарк?...
> А ты читал?
>>позиционируемой как вариант SQLite для аналитических запросов.Ну так сам и ответил - из приведенной тобой цитаты следует, что сабж лучше подходит для аналитических запросов, чем SQLite. Потому и зоопарк, что единственной серебряной пули для всех типов задач нет. Подбираешь БД под задачу.
Хотя бы простой примерчик аналитического запроса. А то одни общие слова
Бог подаст. Типа, на слабо решил взять? Но "мопед не мой, я просто разместил..." А, стоп. И объява не моя, я только цитировал цитированное.А вообще - учись уиться, если не троллишь. Для начала просто почитай в интернетах как обычно организованы традиционные реляционные БД (все эти таблицы, индексы и т.д.), что такое транзакции в БД и их уровни изоляции. Обязательно почитай про колоночные СУБД, чем они отличаются от традиционных реляционных построчных. Почитай про OLTP и OLAP. Потом желательно бы поработать с тем и другим на крупных базах, хотя бы с десятками и сотнями миллионами строк. Чтобы с одной стороны начальник тебя дрюкал за то, что документы медленно проводятся в системе и постоянно блокировки всплывают и ты бы с этим разбирался и прокачивался (тут больше OLTP), а потом дрюкал за то, что отчеты в налоговую или накопительные с начала года итоги по десяткам показателей для начальства по пол дня формируются (а это уже больше OLAP). Вот в процессе и изучил бы что такое Data Warehouses для аналитики, все эти построчные и колоночные БД и все эти агрегатные функции, включая разные ROLLUP и CUBE в GROUP BY, GROUPING и GROUPING SETS и оконные функции, все эти (если взять в пример ораклю) ... OVER(), которые тоже аналитика.
как там с регистронезавимым кириллическим поиском?
Приложили бы в описании хотя бы простой пример аналитического запроса. А то одни общие слова.