Не, это уже дошло

Она выборочно доходит как то

В приложении вк же ток токен хранится ?

мне нужна помощь

Ну шо говори

мой последний тезис: графы, которые ты найдешь в бизнесовой графовой бд  — это на самом деле язык. в смысле, что данные, которые записаны в них — это тупо множество пропозиций, фактов про вещи, state of the affairs. ну, там конечно есть определенный изоморфизм и может показаться что я говорю очевидные вещи, но это заблуждение (мы говорим о триолях в графе, а не о пропозициях в языке) очень дорого стоит нам в mental tax, накладных расходах на туллинг, сложность программных решений и тд

я сейчас вижу Avtivka, как виртуальную машину — интерфейс — к графовой базе. но важно понимать специфику работы такой виртуальной машины. речь идет о тысячах и тысячах транзакций, которые в большинстве будут оперировать в одинаковых диалектах и часто будут очень похожи. транзакций много, а I/O интерфейс (графовая база) один. конечно можно сказать илья ты же используешь dgraph, почему бы тебе просто не добавить инстанцов? dgraph это же distributed база! на что я отвечаю: нахуя? если можно сделать все по красоте. пусть память виртуальная машины и будет наш суперграф из базы, а операции на нем мы реализуем как ассемблер для этого графа. главная проблема тут в том, чтобы разработать такой ассемблер, который позволил бы выражать одновременно достаточно низкоуровневые вычисления (которые можно JIT–оптимизировать!) и высокоуровневые графовые операции (которые можно кэшировать!)
такой код можно было бы итеративно улучшать, применяя всякого рода оптимизации. например: представь, что ты в цикле хочешь пройти по множству каких-то ящиков и в каждом ящике сравнить вещи оттуда со своим списком вещей. в нормальной императивной (на логосе, например) логике это у тебя будет либо вложенный цикл, либо цикл + какая-то логика с множествами типа ∈

оказывается графовые базы очень эффективно умеют делать grandchildren типы запросов, т.е. вместо того чтобы делать N запросов (то, что изначально будет выплевывать компилятор) оптимизатор поймет что можно сделать один запрос и сверху на него хуянуть set intersection… и так далее

если сделать это в опенсорсе и достаточно лоу–левел “бородачей” подпишется под эту тему, то можно сделать реально очень крутой и полезный продукт

Тоесть тебе надо добится большого количества транзакций одновременно ?

да

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

Тоесть у тебя будет много операций одновременно

Или эмулировать множество лог процов

В первом случае vm тебе не нужна

а что видеокарта может делать с графами?

vm нужна

смотри

У видеокарты множество простых мат процов, в принципе он может посчитать все что угодно

бэкенд для этой виртуальной машины — ее I/O интерфейс — это распределенная графовая база dgraph

функция ее выполнять определенные вычисления из запросов и оптимизировать их “на лету”

нужно сделать свой байт-код, оптимизирующий ассемблер, это все должно как-то JIT–ускоряться… ну полный фаршмак

самое крутое это что вместо random–access памяти тут ты работает с суперграфом напрямую и у тебя должны быть инструкции для всех высокоуровневых вещей, которые можно делать в графе