По поводу таблиц и CSV, кстати. Может это будет выглядеть как самопиар, но хотелось бы узнать ваше мнение. Есть у меня вот такой прототип https://github.com/waralex/DataFrameDBs.jl Я его сваял за несколько недель год назад, доказал себе что подобная штука на Джулии реализуется без особых пробем, а потом накатилась куча других дел. Сейчас вот появилось чутка времени и желание развивать это направление. Но у меня так и нет понимания - вообще такая штука будет востребована или нет. Как думаете?

А чем отличается от аналогов?
Есть JDF - специально для DataFrames.
Еще есть довольно распространенный HDF5, на его основе сделали JLD, потом переписали на джулии в JLD2. Формата DataFrames на основе HDF5 пока не встречал, но это сделать очень просто - там и блочное сжатие, папки и атрибуты есть.

Еще можно спросить у авторов DataFrames (Bogumił Kamiński и ко), возможно у них есть какие-то планы по добавлению таких штук.

Ну прежде всего вот этим "Enable disk-based data manipulation (not yet achieved; from v0.4.0)" - у меня именно эти манипуляции и были целью.Т.е. мысль была не написать формат для сохранения DataFrames, а написать ClickHouse на Джулии с возможностью проводить максимум операций на диске без загрузки всех данных в память

Не понял, что значит операции на диске? Вроде бы, чтобы провести какие-то операции, надо что-то загружать в оперативную память?

Т.е. БД для того, чтобы гонять джулевский код по данным в несколько террабайт

полезная штука, особенно если получится этот пункт из планов:
Adding NamedTuples, Vectors, Nested Vectors (i.e. Vector{Vector{Vector}}), Vectors of Strings and Tuples of Strings to stored types

без чтения всей колонки полностью в память

То есть это какой-то блочный кэш для ленивого чтения больших таблиц?

>без чтения всей колонки полностью в память
Именно так

А чем JuliaDB не устроил?

Не будет ли подход DataFrames слишком медленным на данных такого размера? Кажется, что на террабайтах время компиляции уже не будет так заметно

Работает оно сейчас так - таблица храниться в виде колонок. По файлу на колонку. Каждая колонка пишется блоками с форматом типа "кол-во строк в блоке, кол-ва байт в сжатом блоке", а далее сжатый lz блок в бинарном виде. По умолчанию блок - 2^16 строк

Выражение типа sum(t[t.name .== "A" .& t.price .> 10., :price])  выполняется следующим образом. Сначала определяется что нужны колонки name и price. После этого читается в память по блоку name и price, на этом одном блоке выполняется проверка t.name .== "A" .& t.price .> 10 и то, что ее прошло скармливается через итератор в sum. После этого читается в память следующий блок

Почему тогда не написать такую штуку для JDF? А вообще есть же интерфейс AbstractDiskArray для блочных массивов - по идее с ним можно отвязаться от формата хранения

Ещё, кстати, очень удобно если эта структура будет по большей части взаимозаменяем с таблицами в виде vector{namedtuple}. Т.е. чтобы без особых изменений кода менять представление.

Т.е. любой broadcast с полями таблицы ресолвится в итератор, который будет вычитывать блоками с диска нужные колонки и прогонять этот broadcast поблочно, отдавая результат выражения

По поводу JDF возмжно профессиональная дифформация - я просто хорошо знаю код кликхауза, поэтому им вдохновлялся 🙂 По большому счету формат хранения не так важен, если он позволяет доставать и писать данные поблочно и если колонки в нем разделены в разные файлы

А я правильно понимаю, что в текущем варианте только для одной машины работает? То есть распределить по разным машинам нельзя?

Да. Более того, текущий вариант это прототип, на который я посмотрел через год и там многое хочется поменять 🙂