LINUX.ORG.RU

Работа со столбцами базы данных (Apache Arrow?)

 apache arrow, , работа со столбцами бд


0

2

Исходные данные: есть база данных - небольшая, около 3 миллионов записей, но в перспективе быстрорастущая. Весьма часто приходится обрабатывать столбцы. Поэтому возник вопрос об инструменте, облегчающем работу именно со столбцами.

При поиске чаще всего встречалось название Apache Arrow. Пробежался по докам - вроде бы то, что надо: работает в Линуксе, венде и макоси, поддерживает много ЯП (C++, Python, Go, Java и др.), понимает CSV-формат и другие (JSON, ORC, Parquet), интересно работает с оперативной памятью (очень экономно) и даже поддерживает memory-map, поддерживает обработку потоковых данных (сейчас для меня это не актуально, но кто знает, как дальше дело пойдёт), поддерживает извлечение данных из нескольких файлов (а вот это важно). Там есть ещё вагон «плюшек» и «батареек», но я пока ограничился просмотром наиболее актуальных.

Вопрос: кто-то работал с этим фреймворком? Какие плюсы и минусы? Есть ли «подводные грабли» при быстром росте объема БД? Насколько удобен API? В общем, всё о личном опыте работы с Apache Arrow.

А может у кого-то найдутся и другие варианты? Welcome.

Это, скорее, фреймворк хранения данных. Жутко неудобно, если нужно обрабатывать их, а у тебя нет кластера с хадупом. Удобно переносить большие таблицы, но ещё лучше паркет. Так что просто используй clickhouse.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Так что просто используй clickhouse.

Посмотрел их QuickStart и статейку в Википедии. Да, пожалуй, это больше подходит, чем возня с Arrow.

Но я немного подожду, прежде чем закрывать тему - вдруг ещё какие варианты подъедут :)

DeVliegendeHollander ★★
() автор топика

Тоже голосую за clickhouse, хорошая вещь.

Сам я остановился на классическом постгресе и самописных скриптах. Но у меня сильно развесистая структура и самолично написанные скрипты которые паряст цсв хмл и джейсон и кладут как надо в базу.

Смотрел airflow и python dlt, но не зашло, сильно ограничивают своей логикой.

skyman ★★★★
()
Последнее исправление: skyman (всего исправлений: 1)
Ответ на: комментарий от Shadow

Для 3 млн записей кликхаус как-то из пушки по воробьям. Он для другого создан

Оп, ты посмотри системные требования сначала. К тому же хз что ты понимаешь под «обрабатывать столбцы». Апдейты и удаления в кх тяжелы и относятся скорее к maintenance операциям, чем к нормальному использованию

cobold ★★★★★
()

Простой вопрос, а что не так с обычными субд, вроде PostgreSQL? Оно очень производительное и 3 ляма записей для него это как бы фигня полная. Если очень хочется колонок, то там вроде Citus есть, но я им не пользовался по причине того что мне не надо было таким заниматься, так что сказать насколько оно норм не могу, просто знаю что есть.

но в перспективе быстрорастущая

Насколько быстрорастущая и как быстро надо обрабатывать записи? Я понимаю когда хайлоад переходить на clickhouse, а так может игра не стоит свеч?

peregrine ★★★★★
()
Ответ на: комментарий от cobold

Для 3 млн записей кликхаус как-то из пушки по воробьям.

«в перспективе быстрорастущая» - ни о чем не говорит? Я пока точно не могу оценить, но вдруг через месяц будет 6 млн, а через 2 - 12. А к концу года 100 млн. Это тоже «из пушки по воробьям»?

Апдейты и удаления в кх тяжелы и относятся скорее к maintenance операциям, чем к нормальному использованию

Как раз апдейтов и удалений будет не слишком много. В основном арифметика и агрегации.

DeVliegendeHollander ★★
() автор топика
Ответ на: комментарий от peregrine

Если очень хочется колонок, то там вроде Citus есть

Ok, thanks - взято на заметку - посмотрю.

Насколько быстрорастущая и как быстро надо обрабатывать записи?

Выше сказал:

Я пока точно не могу оценить, но вдруг через месяц будет 6 млн, а через 2 - 12. А к концу года 100 млн.

Скорость пока не критична (можно подзадержаться с результатами на пару-тройку часов). Но, возможно (но это не точно), требования ужесточатся.

DeVliegendeHollander ★★
() автор топика
Ответ на: комментарий от peregrine

Простой вопрос, а что не так с обычными субд, вроде PostgreSQL?

Вот здесь виноват - как-то не подумал про PostgreSQL. Сразу кинулся искать columns-oriented.

«Будем посмотреть» :)

DeVliegendeHollander ★★
() автор топика
Ответ на: комментарий от DeVliegendeHollander

100 млн ну такое. Я бы не парился. Вот если базу разнесёт больше чем на десяток терабайт, то есть смысл со всякими апачами связываться и то только из-за диска пожалуй. Жесткое ограничение 32 терабайта на 1 таблицу вроде. Но важна отзывчивость да. Если надо очень быстро запросы обрабатывать, то может что-то более производительное есть.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от DeVliegendeHollander

«в перспективе быстрорастущая» - ни о чем не говорит?

С учётом

Я пока точно не могу оценить, но вдруг через месяц будет 6 млн…

вообще ни о чем не говорит. А вдруг завтра автобус собьёт? Прикупил ли участок на кладбище?

cobold ★★★★★
()
Ответ на: комментарий от Shadow

Ну, удобнее наверное. Про проще как посмотреть. Ждём поста опа вида «Запросов от приложения к кх нет, а он сожрал весь cpu и активно молотит дисками! Что происходит? Меня взломали?»

cobold ★★★★★
()

Весьма часто приходится обрабатывать столбцы. Поэтому возник вопрос об инструменте, облегчающем работу именно со столбцами.

У нас на работе (и на прошлой работе тоже) посоны для таких задач используют Clickhouse.

theNamelessOne ★★★★★
()

А может у кого-то найдутся и другие варианты?

Groonga 14.1.3

https://groonga.org/docs/characteristic.html#groonga-overview

Groonga is a fast and accurate full text search engine based on inverted index. One of the characteristics of Groonga is that a newly registered document instantly appears in search results. Also, Groonga allows updates without read locks. These characteristics result in superior performance on real-time applications.

Groonga is also a column-oriented database management system (DBMS). Compared with well-known row-oriented systems, such as MySQL and PostgreSQL, column-oriented systems are more suited for aggregate queries. Due to this advantage, Groonga can cover weakness of row-oriented systems.

The basic functions of Groonga are provided in a C library. Also, libraries for using Groonga in other languages, such as Ruby, are provided by related projects. In addition, groonga-based storage engines are provided for MySQL and PostgreSQL. These libraries and storage engines allow any application to use Groonga. See usage examples.

dataman ★★★★★
()

Apache Arrow это формат для колоночного хранения Он достаточно низкоуровневый и гибкий. В YDB мы его использовали для работы с внешними данными. При росте БД у тебя скорее всего проблемы возникнут где-то в другом месте.

Reset ★★★★★
()

ClickHouse попробуй. В качестве UI для работы с ней - свежий Metabase, на неделе рассылка по новому релизу была - писали, что полную поддержку завезли.

Norgat ★★★★★
()

Вот тут советуют ClickHouse. CH - это одна из самых быстрых колоночных баз данных со множеством оптимизаций, предназначенная для использования OLAP, Time Series, Machine Learning.

Но

  1. CH Не любит delete и update (и хотя сейчас в CH несколько их вариантов, а не только мутации, но все равно они не сильно родные из-за особенностей хранения данных в CH)
  2. CH Не любит «мелких» (меньше 10-20_000 строк) INSERT.
  3. CH Постоянно «шуршит» процессами на фоне делая Merge частей INSERT-ов и оптимизируя другие фишки, причем «шуршит» достаточно сильно нагружая процессор и CH в обещем-то нужен будет отдельный сервер или кластер.
  4. CH не любит JOIN, особенно 2-х больших таблиц друг с другом (хотя JOIN постоянно улучшаются, но им еще далеко в этом отношении до Oracle, MsSQL, Postgre - да и JOIN не вписывается в парадигму «быстрая аналитическая БД»).
  5. CH любит, чтобы в таблице уже при вставке было много денормализованных столбцов, примерно как в табличках Excel. Тогда CH проявляет себя во всей красе - на одной такой большой таблице можно построить штук 10+ аналитических отчетов, использую в каждом из отчетов свой ограниченный поднабор столбцов. То есть, до CH должна стоять база, где формируются большими кусками для вставки части многоколоночной денормализованной таблицы (ETL,DQ,Join,Delete,Update).

У CH есть достаточно много особенностей, которые не совсем совпадают с привычными реляционными БД типа PostggreSQL, Oracle, MsSQL Server и их надо сначала изучить (можно и по ходу дела, если приложение не так критично и допускает более поздние модификации).

Кроме того CH для пет-проекта с количеством пользователей 1-2 не совсем удачный выбор. CH - выбор для большого (громадного) количества данных и большого количества пользователей, для чего он умеет в кластера.

PostgreSQL (и даже его расширение Citus) в сценарии таблиц с большим количеством колонок и строк подойдет, по-уму, только для прототипизации, обкатки идей, но не пром эксплуатации.

Для пет-проекта, наверное подойдет больше DuckDB - он достаточно много может тянуть в однопользовательском режиме.

BrIg
()
Ответ на: комментарий от BrIg

Аффтырь не знает какие у него требования, но сразу выбирает нишевые решения под них лол.

Даже порядок кол-ва строк / объема данных не знает. Но сразу в кликхауз! ТехноХаус йоу.

anonymous
()
Ответ на: комментарий от anonymous

Наверное, поэтому, действительно ему лучше взять PostgreSQL или DuckDB - отработать что надо, а когда это, возможно, взлетит, искать что-то более подходящее под разработанный прототип.

BrIg
()
Ответ на: комментарий от BrIg

Естественно.

То ли 10 лямов, то ли 100 лол. Уже не говоря о том, что делать надо будет с ними. На каких мощностях (кластер или нет).

Если надо просто считать что-то по 100 млн строк без секундной доступности или миллионов юзеров, то нужен просто норм сервак с реляционкой.

anonymous
()

Вышел из отпуска чел, который курирует это направление у заказчика, подключился и уточнил требования. Быстрого роста объёма данных не будет, потоковая обработка в ближайшей перспективе не рассматривается, обработка простая (как я уже говорил): арифметика, агрегации, статистика.

С учётом этих условий и рекомендаций в этом топике выбрана связка PostgreSQL + Citus.

Всем ответившим спасибо, вопрос решён тема закрыта.

DeVliegendeHollander ★★
() автор топика
Ответ на: комментарий от peregrine

Отдельная благодарность @peregrine за наводку на Citus:

Простой вопрос, а что не так с обычными субд, вроде PostgreSQL?

Если очень хочется колонок, то там вроде Citus есть

Я не знал про Citus. Разумеется, рано или поздно при поисках наткнулся бы на него, но «лучше рано», благодаря peregrine. Спасибо!

DeVliegendeHollander ★★
() автор топика
Ответ на: комментарий от BrIg

Поддержу и чуть дополню: В CH не гарантируется выполнение запроса. Например, если правая сторона JOIN не влезет в лимит по памяти. Т.е. он или ответит быстро или упадёт. А классическая субд будет грызть байты с диска, но ответит. Ну в крайнем случае «снимок слишком стаоый» или в самом крайнем ORA-600 :)

Paka_RD
()