чтение из БД минуты, инициализация - тоже минуты, всякие доп дозагрузки которые обязательно поверх того что получилось нужно делать - еще несколько минут. вобщем тут есть уверенность что ничего значительно не ускорить - все что можно уже распараллелили. если еще извратиться может быть в два-несколько раз ускоримся а хочется в сотню раз за счет предварительной загрузки и инициализации всех структур.

не понятно почему инициализация минуты занимает. вы инициализируете по мере чтения из базы или после того как все прочитали?

то что можно - по мере чтения из базы. просто данных МНОГО. по сути у нас своя графовая БД в памяти

Понимаю к чему клоните. Быть самым классным для ЦА и не париться.

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

А выявлять чтобы что? Если позиция одна - не останавливать поиск, пока человек окончательно не вышел

можно объяснить почему долго читают из базы, но почему инициализация занимает минуты это сложно. может структуры данных неподходящие?

Кто-то предложил лучше условия. Это не значит что кандидат не уверен, просто условия решают

лучше считать что структуры подходящие - они оптимизировы под бизнес нужды. там несколько графов строится, поверх всякие дополнения потом загружатся. просто данных много и будет еще больше. може быть можно что-то еще предварительно рассчитать - то что сейчас на старте рассчитывается. ну может быть это раз в 10 нас ускорит.  это будет полумера. хочется попробовать сразу прийти в финальную точку - когда всё предрассчитали включая все связи между всеми объектами и целиком их сдампили и целиком их загружаем - вот это уже точно самое оптимальное будет

звучит как будто вам нужно что-то вроде OLAP

вы сфокусированы на “данных много”, но это не метрика. у амазона тоже много данных и нормально работает

дампить в диск состояние памяти так себе идея, если вы не разрабатываете виртуальные машины

на диске нужно хранить данные, а не state

Когда-то, когда я занимался маршрутизацией в Я.Картах, мы данные из базы в оффлайн- процессе дампили в бинарные файлы, а потом в рантайме делали mmap. Не знаю насколько вам релевантно, но вот и так бывает.

это было бы идеально - только как быть со ссылками между объектами - все на всех ссылаются. ссылки либо надо заменять каким-то суррогатом типа index, либо обновлять после загрузки, либо как-то это делегировать ОС (в своп файл же сохраняется все как-то и загружается оттуда / или hibernate функция / или перенос работающих подов между нонами)

может можно объекты хранить отдельно от связей/графа?

можно - это идея #1  - заменить все ссылки индексами - но тогда это будет не идеально по скорости в ходе работы с графом (а если совсем отдельно хранить то все еще менее оптимально будет).

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

я скорее о другом - скинуть объекты в условных protobuf на диск, а ссылки восставновить после чтения файла где хранятся связи. Объекты в памяти по прежнему ссылаются друг на друга, но на диске это хранится раздельно

логика такая - читаем с диска пул объектов, затем читаем как они должны быть связаны между собой и восстанавливаем связи

да. спасибо это интереная идея. это в сторону пункта #2 только без unsafe кода - все будет safe. и мне это больше нравится чем писать unsafe подмены ссылок на лету