Комментарии 28
Структура ваших данных как-то совершенно не ясна. Что такое Entity и почему оно наследуется от BaseEntity? Это учреждение образования??? Если их у вас 1300, то это не "большой список". Что такое "вложенная сущность" и зачем она? В целом, сложилось впечатление, что вы попытались "забивать гвозди микроскопом", а теперь удивляетесь, что плохо получается.
Да, это учреждение образования. BaseEntity хранит общие поля для всех сущностей приложения - айди, даты создания и внутренний статус сущнсоти (удалена, заблокирована, активна и т.п.)
Вложенная сущность - поле с сущностью Spring Data JPA.
Вероятно графовые базы работают хорошо при других видах данных и других настройках спринга, однако в моем варианте при замене репозитория на neo4j, один и тот же запрос в базу выполянется на порядок дольше
Расскажите подробнее где и как тормозят запросы?
17 таблиц, 1300 poi на странице, 50K записей в хранилище... боюсь гадать на кофейной гуще, но кажется нагрузка не в объёме данных и проблема не в типе хранилища.
Я бы посмотрел:
где именно проблема: в бд или в прослойке, так как если браузер показывает pending - это ещё не значит что проблема в бд.
на суммарное количество запросов в бд, возможно не решена n+1.
на структуру запросов, возможно join`ы оптимальнее разбить на отдельные запросы с lazy-load.
банальные индексы не там и не те, лишние сортировки или limit/offset.
на математику внутри запросов, для расчёта попадания координат в область есть стандартные методы.
возможно грузить стоит отдельно координаты для отображения на карте, а отдельно - детальную информацию для просмотра.
Согласен. Не знаю, насколько оптимально spring делает запросы к БД (случай с postgres) , но помониторить запросы со стороны БД было бы очень полезно. Ну и если автор строит карту с 50К объектами, то это в корне неверно.
И что это за join-таблицы? Результаты запросов? Полная инфа обо всех объектах в системе? А оно прям вот нужно сразу все обо всех? "Что-то в консерватории поправить надо", мне кажется.
Ну и если автор строит карту с 50К объектами, то это в корне неверно.
Конечно. Хотя в принципе я показывал карту с десятками тысяч объектов одновременно (на хилом ноутбуке) — просто тут очевидно напрашивается кластеризация, потому что ни в каком масштабе их все равно все сразу не видно. Тем более на карте объекты все равно группируются вокруг населенных пунктов, так что даже естественная кластеризация по их названию (до определенного масштаба) вполне решает большую часть проблем. Даже без работы с координатами.
Хотя я показывал карту с тысячами объектов еще на компе с 286 процом и 1 MB RAM под Windows 3.0 (если уж меряться).
И кстати, что автор имеет ввиду под ROM?
Я верю (у меня был AMD A10 и 4 гига), но про другое. У автора должно хватать ресурсов, у него есть 6 гигов — но это не значит, что на экране обычного размера на карте нужно показывать 50 тыс объектов. Не будет видно ничего, будет месиво из маркеров.
Объем volume, занимаемый докер образом Neo4j. Он превышает гигабайт, когда в то же время у постгреса он в разы меньше при одинаковом объеме данных
Данный вариант работает с момента, когда объектов было несколько десятков. А так действительно надо пересмотреть логику с кластеризацией
Я займусь этим в ближайшее время, благодарю за наводку! Сейчас я использую стандартные репозитории с парочкой индексов, поэтому думаю, что еще спринг может подтягивать внутренности объектов целиком, что задерживает ответ
в пику предыдущим комментаторам:
поздравляю, вы молодец, вы попробовали и у вас не получилось. отрицательный результат тоже результат.
С чем поздравлять-то? С тем, что человек несколько недель впустую потерял? Так можно проект туда-сюда мигрировать еще много раз в надежде "а вдруг получится".
С позиции личного развития как разработчика путь вида 1. Что-то сделать 2. Что-то переделать. 3 написать статью и узнать из комментов что делал вообще всё неправильно - это очень даже неплохой вариант превращения себя в полноценного разраба, всё зависит от выводов, которые сделает автор. В комментах обозначили что копать всегда надо глубже, знания для построения проекта нужны чуть более фундаментальные, чем есть, обозначили ключевые слова, по которым гуглить. Но, естественно, эта статья скорее больше для автора, либо для тех, кто находится примерно на таком же пути. Поэтому не считаю, что зря.
Ничего не ясно, судя по описанию данных мало + всё как-то на уровне Spring Data.
Я подозреваю, что просто необходимо несколько нативных SQL запросов с временем выполнения несколько мс. Не может 50к записей 2 секунды тащиться. Скорее всего orm делает какую-то ерунду, вытягивает вложенные объекты вложенных объектов десятками запросов.
По поводу графовых бд - на них ноды Etherium работают, и много чего. Там тоже не может 20сек 50к записей тянуться, spring наверняка творит дичь
Именно это я имел ввиду в своём комментарии выше. Только не десятками, а сотнями или тысячами запросов.
Я согласен с вами, думаю, что постгрес более оптимизирован под работу из коробки чем neo4j в спринге. Конечно, если все написать на нативные запросы, то можно много времени выиграть, я думаю, что так и поступлю
Сорян, ноды ефира работают обычно поверх самых простых (утрирую) key-value хранилищ, две самые распространенные - поверх rocksdb и mdbx
Старая статья про Entity и Lombok
https://habr.com/ru/amp/publications/564682/
Там проблемы не только с этим.
аналог для @Formula аннотации из Spring Data JPA
Начнём с того, что это аннотация hibernate, а не spring-data. И придумана она совсем не для того, для чего её использует автор. У него же на ровном месте N+6 запросов, даже если сущность по идентификатору запрашивать.
Статья - хороший пример того, что получится, если делать, не понимая что и как.
Публикации
Почему я пожалел о миграции на Neo4j