Итак, 2 января 2017го. Декабрьская поездка в Прагу и Новосибирск поломала только начинавшеюся практику ежедневного программирования, суета конца года в бизнесе усугубила, но пару дней в конце года я уделил для кода.

Что я имею: какой то жалкий прототип dom diff – это даже нельзя назвать virtual dom, поскольку DOM как таковой у меня отсутствует (даже виртуальный). Чтобы двинуться дальше надо увидеть всю картину, поэтому я зайду с другой стороны - со стороны модели.

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

Несколько лет назад Никита Прокопов сделал довольно известное в некоторых кругах архитектурное подобие Datomic под названием DataScript, а буквально месяц назад кто-то твитнул о том что Mozilla тоже делает нечно похожее. Вот оно: Datomish.

В каком направлении идет Mozilla я не смотрел, но пару лет назад встречался с Никитой и говорил что для платформы моей мечты я хочу сделать полноценный datomic на стороне браузера. Тогда Никита сказал что это пиздец и на такое не готов сам Rich Hickey (не знаю поменял Никита свою точку зрения к этому моменту или нет), но тогда он подкинул мне интересных ребят, и хоть я на них уже натыкался, ребят стоит читать и внимательно смотреть - они очень интересные, спасибо Никите. Вот ребята: Eve: Programming designed for humans… Нашел письмо от Никиты, встречались мы в октябре 2014го.

В общем я не буду ждать ни Никиту ни Mozilla, а просто попытаюсь сделать для себя полноценный Datomic-alike database, с клиентом (peer, в терминологии datomic) на стороне браузера. Задача эта интересна еще и тем, что с 2000-х годов в мире возникло столько структур данных и алгоритмов, что прям крышу сносит. Это в основном succint и cache-oblivious data structures, который интересно было бы с большой пользой применить в БД.

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

Прототип

В моем прототипе основная часть – это выполнение запросов. В своей прошлой жизни я никогда до этого момента не доходил (выполнение любого запроса от пользователя). Ибо, если ты делаешь какое то свое хранилище вместо БД общего назначения – то оно специализированное под конкретную задачу. Это имеет смысл, поскольку в этом случае ты имеешь шанс уделать любую базу данных общего назначения (по памяти, производительности и т.д.). Это предполагает и выполнение конкретных запросов супротив оптимизированной структуры.

Но жизнь показывает, что большинство программистов мыслят стереотипом: если есть данные и есть запросы к данным надо взять БД. Вы не поверите насколько много программистов так мыслят, и даже очень хороших. Работал у нас один мужчина - очень неплохой, и в какой-то момент он занимался эксклюзивно DLTK. DLTK это грубо говоря средство разработки, а в средстве разработке задача поиска разнообразной информации - вещь необходимая. Так вот: этот программист всандалил туда H2 Database, чем вызвал мое полное недоумение и неприязнь.

Ладно бы он засунул какую-нить BerkeleyDB, но полнценную, реляционную БД с SQL фронт-эндом – это полный пиздец. А больший пиздец в том, что это мало кого удивило за исключением реально думащих чуваков, как, например известный в мире PHP Seva (Wsevolod) Lapsha, который буквально снял мои слова с языка:

As I already mentioned, you would probably like to try the Berkeley DB. I assume you do not use non-trivial table joints and filtering, in the queries, so seemless Map interface provided by Berkeley would be easier to use. Also the statement parsing, compilation and optimization is told to be a certain overhead.
Anyway, it would be interesting to perform a clean performance comparison between H2 and B., since I did not found an existing one over the Internets.

Я не знаю выпилили ли они H2 из DLTK на данный момент (хоть я вроде и оставался формальным Project Lead этого проекта долгое время), но беглый поиск по сети говорит что еблись ребята долго.

Но мы не ищем легких путей (сарказм), хотя можно было бы сейчас скомпилячить sqllite emscripten-ом и подрачить на то, что у меня уже есть БД в браузере, рассазать вам что у меня есть реляционная “альтернатива” datomic, настроить хуеты вокруг и жидко обосраться в конце.

Что есть на данный момент

Практически нихуя. Как я писал выше, моя первая задача - выполнить запрос. В архитектуре datomic любой запрос - это большое количество джойнов, про архитектуру, если не хотите рыться в сети можно почитать выжимку у Никиты: Unofficial guide to Datomic internals.

Поскольку я интересуюсь БД давно то есть у меня в загашнике знание об одном замечательном алгоритме, который называется Leapfrog Triejoin. Его я и попользую, поскольку 1) реализация алгоритма тривиальна 2) есть подозрение что он будет работать быстрее чем у Никиты, а у него в DataScript, как я понимаю из A shallow dive into DataScript internals Hash Join.

Новый репозиторий

Самое время во второй день нового года сделать новую репу, и залить туда всю гавнину. Тем более что старая faxma уже неактуальна ни своим названием ни сутью (объясняю почему я - дебил). Встречаем свежак: https://github.com/platoff/wafer. Web Application Framework (Elegant and Reactive).

leapfrog.nim реализация Leapfrog Triejoin. rel.nim простое хранилище отношений. Отношение это набор tuples вида [a b c ...], и я предполгаю что все переменные в тупле фиксированной длинны, за исключением одной, которая может быть переменной длинны (этого допущения мне явно не хватит, но пусть пока так).

db.nim – не законченная реализация запросов (из данных, лежащих в rel с помощью leapfrog). Поскольку leapfrog все за меня делает, мне остается лишь построить какой-то план выполнения запроса, итераторы соответствующие этому плану и отдать все это дело в leapfrog. План запроса - не что иное как порядок вычисления переменных участвующих в запросе. Я мог бы сейчас взять их в любом порядке, но хочется посмотреть как согласуются части программы, поэтому я все же делаю какой-то алгоритм выбора эффективного плана (который, в силу своей примитивности, легко сможет “выбрать” хуевый план).

Хуярю

Надо доделать сам join, сейчас у меня есть только план выполнения запроса. Но перед этим надо навести порядок с ебучей матрицей, которая у меня вдруг возникла. Последний раз я матрицу пользовал в школе, когда программировал пиксельную графику (и не для аффинных преобразований – я про них не знал ни тогда ни сейчас), а для того чтобы хранить пиксели. А из университета меня выгнали, так что матрицы я не программировал, и всегда считал что для программиста достаточно одномерного массива. Но все же в данном месте мне очень хочется ее засунуть.

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

Назад, к записям