Комментарии 9
Понимаю, что это перевод, но, все равно, рассуждения о базах данных звучат странно, и, как будто, привнесены лишь для ещё большего обоснования актуальности проделанной работы.
Системы баз данных предыдущего поколения, такие как PostgreSQL или MySQL, представляют собой Volcano-модели на основе строк, и предусмотреть их при проектировании было очень грамотно в ту эпоху, когда диски были намного медленнее, а оперативная память была в дефиците. Сегодня, когда у нас есть быстрые SSD-диски и большие объемы доступной памяти, а также широкие SIMD-регистры, мы видим, что колоночные базы данных, в частности, CockroachDB, DuckDB, являются одними из самых производительных СУБД.
Кажется, автор намеренно не понимает, что, как раз, колоночные базы значительно менее требовательны к диску (за счёт последовательного чтения и колоночного сжатия). Принципиальное то различие между строками и колонками в OLAP/OLTP ожиданиях. Sybase IQ неплохо делал свою работу и в эпоху медленных дисков.
Хотел попробовать покрутить Поларс на работе, но пока не буду трогать. У нас тысячи строк трансформеров на методах пандаса. Переписывать нужно вообще всё. Судя по бенчмаркам, поларс быстрее в некоторых операциях всего в 2-6 раз. Это очень мало, чтобы менять среду разработки.
Pandas с недавних пор на Apache Arrow уже стал заметно быстрее. pd.Categorical дает тоже ускорение выборки/группировки/i/o. Согласен с тем что Polars в зоне досягаемости обычной оптимизации. Плюс ждем Mojo. Для меня минус в Polars - нет мультиндексов Pandas, придется совмещать, а там и до потери скорости недалеко, с таким винегретом технологий.
Да там вроде не драматическая разница в API, как я понял. Чего бы на какой-нить пилот не прикрутить и поиграться?
У Polars есть возможность работать с массивами данных, не помещающихся в память, с pandas это прямо больно бывает, когда размер данных изредка выходит за рамки.
5.2.2 Неблокирующее хеширование
Что-то по описанию совсем непонятно, как это работает и откуда достигается ускорение. По приведённой картинке видно, что все потоки считают хэши от всех данных, затем выкидывают всё в мусорку, кроме небольшой части, а затем отдельный поток объединяет эти части опять вместе. WAT?
Ага. Тоже показалось полным бредом.
Фактически, что групбай отлично делается без блокировок во много потоков, что джойн, если делать в два этапа, между которыми потоки должны обменяться данными. Практически все аналитические движки начиная от планировщика Microsoft SQL при работе с колоночными таблицами и заканчивается спарками-хадупами так и делают
Это хорошо видно на примере СУБД. Системы баз данных предыдущего поколения, такие как PostgreSQL или MySQL
меня эта фраза очень порадовала.
Вы бы библиотек готовая с данными в памяти работает не путали с DBMS которая обеспечивает многопользовательскую работу с террабайтами данных.
Я написал одну из самых быстрых библиотек датафреймов