|
| 1.2, Аноним (2), 16:07, 04/06/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Пробовал несколько месяцев назад, надо было подмёрживать небольшую таблицу к большой (несколько сотен ГБ), которая лежит в паркетах на HDFS. Т.е. простой мёрж, никаких там группировок на всех данных. Так вот, если искусственно скармливать этой утке небольшие чанки от большой таблицы - то вывозит. А если сразу всё, то падает с ошибкой выделения памяти, хотя свободной памяти на серваке ещё. Интересно, пофиксили ли.
| | |
| |
| |
| 3.6, Аноним (6), 17:31, 04/06/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Причём тут булк инсерк? У меня есть несколько сотен ГБ в паркетах, к ним нужно примёржить пару МБ и получить результат (тоже пару МБ). Всё это из питона.
| | |
| |
| 4.8, гага (?), 20:25, 04/06/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так и говорите терминами хотя-бы свойственных базам данных, делаете джоин - так делайте меньшее в большее т.к. базе в ином случае нужно хранить в памяти все ключи первой таблицы и она пошлет вас на три буквы если датасет окажется слишком большим
| | |
| |
| 5.10, Аноним (6), 22:08, 04/06/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так разрабы этой субд как раз хвалились, что она у них для больших данных и типа умеет не тащить всё в память, а при необходимость работать с большими таблицами даже если в память всё не влезает. А в моём случае ещё и памяти свободной на серваке было завались. А по факту оказалось, что ей надо на чанки все равно бить. Ну и нафига оно тога нужно?
| | |
| |
| 6.12, Аноним (12), 23:02, 04/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
Без кода гадать по комментам что где и почему упало бессмысленно. Может у тебя там в цикле все паркеты в память читаются.
| | |
| 6.23, гага (?), 12:57, 05/06/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Так разрабы этой субд как раз хвалились, что она у них для
> больших данных и типа умеет не тащить всё в память, а
> при необходимость работать с большими таблицами даже если в память всё
> не влезает. А в моём случае ещё и памяти свободной на
> серваке было завались. А по факту оказалось, что ей надо на
> чанки все равно бить. Ну и нафига оно тога нужно?
кликхаус тоже хвалится что может в большие данные, но большее в меньшее точно так-же вызовет повышенный расход памяти, то что оно может - эт не значит что головой думать не надо
| | |
|
| |
| 6.22, гага (?), 12:56, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> Так и говорите терминами хотя-бы свойственных базам данных, делаете джоин
> юнион что такое?
Юнион не даст результат в пару мегабайт при подаче на вход множества гигабайт
| | |
| |
| 7.24, Sw00p aka Jerom (?), 13:28, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Юнион не даст результат в пару мегабайт при подаче на вход множества
> гигабайт
"""
Т.е. простой мёрж, никаких там группировок на всех данных.
"""
что такое "простой мОрж" двух множест?
| | |
|
|
|
|
|
| 2.4, penetrator (?), 17:10, 04/06/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
так join вроде не фишка этих баз, она columnar?
ну 200 гигов нормальная реляционка без проблемы вывезет на join
вопрос там только в том сколько из этих 200 гигов тебе надо отдать и сколько там будет index scan
| | |
| 2.7, Wine is not emulator (?), 19:04, 04/06/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не 32-битная версия СУБД и/или клиента, случаем?
А зачем в таком встраиваемом формате хранят такие объёмы? Не знал, тут же полноценную RDBMS уже можно.
| | |
| |
| 3.17, economist (?), 08:32, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
RDBMS медленнее и намного. Колоночное хранение рулит. Большинство сравнений бессмысленны без понимания специфики данных. Например, большинство SQL-запросов к БД у экономистов читают 10% строк и многоуровнево группируют с множ. отборами. С такими данными и запросами DuckDB очень быстр. Та же SQLite примерно в 2,5 раза тормознее (но все же быстрее сетевых БД).
| | |
|
| 2.15, Аноним (16), 01:10, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
Результат EXPLAIN ANALYZE в студию. А там посмотрим.
Может, утку неправильно приготовили.
| | |
|
| 1.18, Аноним (18), 10:07, 05/06/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Знаю вопрос глупый, но нафига очередная база данных? Имеющихся мало? Какое уникальное торговое предложение (УТП) сабжа?
Вот допустим ищу я вакансию Девопса, в вакансиях в разделе знания БД у всех разные названия. Я думал что в ИТ принято перенимать лучшие практики? Нафига этот зоопарк?
| | |
| |
| 2.19, Аноним (3), 10:31, 05/06/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Потому что если ты знаешь допустим мускуль ты уточнишь в выдаче среди конкурентов. А когда ты знаешь какую то мутную фигню, которая почему то понадобилась эйчеру ты будешь возможно даже на первой странице.
А зачем кто-то стал это искать сотрудников для работы с фигнёй? Например потому что повелся на маркетинговый буль-щит.
| | |
| |
| 3.25, Аноним (18), 13:58, 05/06/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>А когда ты знаешь какую то мутную фигню, которая почему то понадобилась эйчеру ты будешь возможно даже на первой странице.
Ну и вакансий будем меньше и не факт что ЗП будет больше.
| | |
|
| |
| 3.26, Аноним (18), 14:04, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
А ты читал?
>позиционируемой как вариант SQLite для аналитических запросов. | | |
| |
| 4.30, Аноним (30), 21:10, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Знаю вопрос глупый, но нафига очередная база данных? ... Нафига этот зоопарк?
...
> А ты читал?
>>позиционируемой как вариант SQLite для аналитических запросов.
Ну так сам и ответил - из приведенной тобой цитаты следует, что сабж лучше подходит для аналитических запросов, чем SQLite. Потому и зоопарк, что единственной серебряной пули для всех типов задач нет. Подбираешь БД под задачу.
| | |
| |
| 5.31, Neon (??), 22:00, 05/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
Хотя бы простой примерчик аналитического запроса. А то одни общие слова
| | |
| |
| 6.33, Аноним (30), 00:23, 06/06/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Бог подаст. Типа, на слабо решил взять? Но "мопед не мой, я просто разместил..." А, стоп. И объява не моя, я только цитировал цитированное.
А вообще - учись уиться, если не троллишь. Для начала просто почитай в интернетах как обычно организованы традиционные реляционные БД (все эти таблицы, индексы и т.д.), что такое транзакции в БД и их уровни изоляции. Обязательно почитай про колоночные СУБД, чем они отличаются от традиционных реляционных построчных. Почитай про OLTP и OLAP. Потом желательно бы поработать с тем и другим на крупных базах, хотя бы с десятками и сотнями миллионами строк. Чтобы с одной стороны начальник тебя дрюкал за то, что документы медленно проводятся в системе и постоянно блокировки всплывают и ты бы с этим разбирался и прокачивался (тут больше OLTP), а потом дрюкал за то, что отчеты в налоговую или накопительные с начала года итоги по десяткам показателей для начальства по пол дня формируются (а это уже больше OLAP). Вот в процессе и изучил бы что такое Data Warehouses для аналитики, все эти построчные и колоночные БД и все эти агрегатные функции, включая разные ROLLUP и CUBE в GROUP BY, GROUPING и GROUPING SETS и оконные функции, все эти (если взять в пример ораклю) ... OVER(), которые тоже аналитика.
| | |
|
|
|
|
|
| 1.32, Neon (??), 22:01, 05/06/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Приложили бы в описании хотя бы простой пример аналитического запроса. А то одни общие слова.
| | |
|
