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

"Но у меня так и нет понимания - вообще такая штука будет востребована или нет. Как думаете?" Как бывший маркетолог могу сказать, что здесь надо подумать над аудиторией.

В принципе те, кому это было бы интересно есть, но так же есть несколько блокеров.

1. Джулия в головах тех, кто про неё знает, но не пишет активно, позиционируется как язык для математических задач. Для таких людей, база данных - это что-то совсем другое, поэтому заведомо большинство из них уйдёт в отказ, со словами "ну, это надо на сях или го или раст писать, при чем тут Джулия".

2. Те, кто Джулию знает, будут скорее всего сопротивляться по той же самой причине, но с другой стороны. "SQL и базы данных - это всё из другой вселенной, у нас есть отличный DataFrames/Vector/что-то ещё, к чему все эти усложнения".

3. Условный бизнес, который не будет циклиться на языке (со словами, что это интересно только разработчикам) будет конечно не очень доволен тем, что это всего лишь фреймворк, в котором нету кучи фич, и поддержки которые нужны здесь и сейчас. Тот же Clickhouse вылез всё-таки за счёт бренда Яндекса.

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

Для распределенных вычислений нужна сетевая часть. По большому счету это не видится проблемой. Т.е. если реализовать возможность выборки с диска в несколько потоков (а это точно есть в планах, если я вообще буду это дальше развивать), то параллелить по машинам после этого вообще не проблема -

>но надо думать кто они и как до них достучаться.
Угу. Либо делать какой-нибудь более попсовый проект, используя этот сторадж как составную часть, только тяжело это в одиночку к сожалению

Нужно искать единомышленников

Для того, чтобы появились единомышленники сначала нужен прототип, который уже кому-то интересен. Во всяком случае в моей практике только так бывает. Да и в этом случае тоже - у Dash.jl пул реквестов от сообщества нет почти, хотя попсовее его тяжело придумать 🙂

Чтобы были единомышленники, в первую очередь нужна идея. Потом уже прототип

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

Вопрос только что. Я тут опять с точки зрения бизнеса рассуждаю, но какие требования должны быть, чтобы было желание сотворить это чудо именно в таком виде.

В случае первого веб магазина на Лиспе, большим плюсом была скорость разработки, как писали, новая фича занимала полтора два дня.

Чем решение на Джулии может быть более интересно, чем на том же кликхаусе? Вряд ли в скорости простых запросов, полагаю, что там всё-таки вылизали хорошо. Например это может быть возможность быстрого исполнения сложных запросов. То есть такой вариант кликхауса с полноценной поддержкой UDF.

Потому область пользователей Dash мало пересекается в областью разработчиков подобных инструментов.

Оно может быть интересно прежде всего единым языком обработки данных вне зависимости от их объема. Собственно наметки попсового проекта есть, пока не очень четкие. Что-то вроде комбинации airflow с zeppelin. Т.е. в очень приблизительном виде - DAG, в котором каждый узел это код на джулии, который на вход принимает либо DataFrame либо таблицу в локальном сторадже и на выход отдает их же. Плюс входные узлы, которые позволяют загонять данные из внешних источников. И возможность писать код/строить дашборды и т.д. и т.п. в этом окружении. Т.е. настраиватеся окружение с подготовленными данными. Любой процесс преобразования данных можно сохранить в ноду DAGа на будущее, попутно решив будет ли это View(т.е. будет выполняться каждый раз) или выход будет по расписанию сохраняться в локальный сторадж.

Наверно сумбурно описал, но оно и в качестве идеи пока сумбурно - только наметки

Я очень надеюсь, что это не будет восприниматься как критика, потому что идея Airflow на Julia - это моя голубая мечта 😊 Поэтому да, сделать цельное решение, с нормальной оркестровкой и собственным сверхбыстрым хранилищем - это очень и очень круто.

Но опять же, это само по себе очень сложно сделать, и это плохо продаётся, потому что это инструмент ради инструмента. Airflow всё-таки делали для обработки задач AirBnB и там были огромные объёмы данных и масса пайплайнов и то, что всё это было собрано в одну, относительно компактную систему было достижением, но достижением, которое решало реальную бизнес-задачу.

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

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

Поэтому я и не хочу писать чистый AirFlow - хочется чтобы у него был красивый выход сразу, т.е. это должен быть BI инструмент. Объем работ получается здоровый и это пугает, да

Из задач, где есть большие потоки данных, это что-нибудь связанное с финансами - биржи тонны данных генерируют. Но это область специфичная, не всем нравится.

По поводу задач - они то как раз есть. Собственно и сам DataFrameDBs как идея появился тогда, когда я понял что я тащу по 3-5GB сырых данных из клика для рассчетов и мне было бы удобнее иметь их локально вместо того, чтобы вытягивать каждый раз.

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

Так данные то наверное по работе 😊 NDA все дела.

Понятное дело что я их никому показывать не собираюсь