Комментарии 10
У меня есть претензия к сводной табличке с производительностью: для перцентилей времени исполнения запросов не указаны единицы времени, в которых они указаны. Ну и хотелось бы увидеть характеристики машины, на которых производилось сравнение.
Тогда мы стали искать, каким компилируемым языком можно заменить С, чтобы сохранить производительность, но написать меньше кода. Выбрали Rust, на нём хранимые процедуры получились меньше где-то в пять раз.
За счёт чего удалось столь кардинально снизить размер исходного кода? Ну и хотелось бы побольше подробностей, слабо верится, что вы по пути ни на какие препятствия не наткнулись.
Хуже всех себя показал Lua <...>
Извините, я плохо знаком с Tarantool, но есть там возможность подключить LuaJIT?
В результате для хранения графов мы выбрали Tarantool. Одно из его главных преимуществ: мы умеем с ним работать
На этом можно было остановиться и не фантазировать формальные проблемы другого софта.
…Два шага пути нами сделано, осталось найти только связку между этими двумя множествами…
Действительно, на много проще join-ов :-D и на SQL, конечно, так сделать нельзя.
Интересно было бы сравнить на аналогичном железе в Greenplum, который умеет параллельно делать joins на сегментах, при этом он так же поддерживает шардирование и сегментирование.
Простите, а какая религия не позволяет использовать графовые СУБД, либо графовые расширения традиционных РСУБД?
Импортозамещение (графовые БД), а реляционные БД - медленные
У православного PostgreSQL Pro есть графовое расширение Apache AGE - A Graph Extension for PostgreSQL . Работает не так уж и медленно.
Вот еще один вариант: PostgreSQL Graph Search Practices - 10 Billion-Scale Graph with Millisecond Response - Alibaba Cloud Community если и это - медленно, то видимо, дело не в СУБД.
Хранение графов в Tarantool: реальность или миф