Производительность

[ivansglazunov]

• нет новых технологий, Postgresql, hasura, gql
• почему не работают с графами, траверс, рекурсии, работа с заранее не известными структурами и моделями долго
• вместо траверса оптимизация индексов materialized path и другие
• ответы на правовые вопросы за те же 2-6 join
• поиск по дереву как по диапазону
• нагрузочное тестирование
• дополнительные оптимизации индексов и вспомогательные структуры для мета данных на усмотрение разработчиков

[zakhar-kogan]

Deepcase != замедление проекта, Deepcase == ассоциативный DDD.

• Проверенные и производительные технологии: PostgreSQL, Hasura, GQL
• Используем оптимизацию индексов materialized path вместо traversing'а
• Запросы по правам - не более 6 JOINов для любой глубины и сложности
• Дерево данных как диапазон (массив?): работают быстрые алгоритмы поиска
• Лёгкое проведение нагрузочного тестирования

[ivansglazunov]

• Проверенные и производительные технологии: PostgreSQL, Hasura, GQL
• Используем оптимизацию индексов materialized path вместо traversing'а
• Запросы по правам - не более 6 JOINов для любой глубины и сложности
  • нет, может быть и более, это средние значения, быть может по началу далее 10
• Дерево данных как диапазон (массив?): работают быстрые алгоритмы поиска
  • Да, не описывая правила переходов траверса или дерево возвратов и не описывая соединения результатов джойнов все равно получается плоский массив из которого можно восстановить граф на получающей стороне. В базу передается только селектор как написано: от связи Х по связям типов Y и Z но не далее связей R и W.
• Лёгкое проведение нагрузочного тестирования
  • Я имел в виду что мы проводим его для наших методы работы с графом. Пока каких то особо удобных "наших" способов нет. Но при желании все обычные для постгри или хасуры или gql инструменты доступны.