История такая. Взял у фирмы Ardas тестовое для выполнения:

автор
Есть таблица contacts в SQL базе. В ней миллионы строк.

Поле Тип
id 64 bit integer
name varchar

Написать REST сервис hello с ресурсом
/hello/contacts?nameFilter=val

Запрос к contacts должен возвращать контакты из таблицы БД contacts. Параметр nameFilter обязателен. В него передаётся регулярное выражение. В возвращаемых данных не должно быть записей, в которых contacts.name совпадает с регулярным выражением.

Массив контактов возвращается в json формате

авторcontacts: [ Contact, ... ]

Contact
{
“id”: integer,
“name”: string
}

Пример запросов
/hello/contacts?nameFilter=^A.*$ - возвращает контакты, которые НЕ начинаются с A
/hello/contacts?nameFilter=^.*[aei].*$ - возвращает контакты, которые НЕ содержат букв a, e, i

Замечания и пожелания к реализации
Фильтр обязательно применять в java коде, не использовать возможности SQL.

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

Учитывать, что сервис должен быть готов одновременно обрабатывать множество запросов.

SQL БД можно использовать любую, предпочтительно PostgreSQL.

Сервис хотелось бы увидеть на Spring Boot, но не обязательно.

Коды ошибок HTTP использовать типичные для REST сервисов.

Сборка maven

Наличие тестов

К результату приложить объяснение, как развернуть БД, запустить приложение. Было бы здорово, если бы окружение поднималось с помощью Vagrant, виртуализация VirtualBox.




Собственно я выполнил задачу так https://github.com/Tsyklop/MillionContacts

Но человек который смотрел высказал некие недочеты:

авторТребует доработки:
1. Использование String.matches для каждого контакта - неэффективно. // Я переделал на Pattern/Matcher
2. Вычитывать все записи из базы на каждый запрос от каждого пользователя неэффективно
3. Захардкодженый pageSize // В условиях задания об этом ничего не говориться
4. Поиск в базе из миллионна записей занимает 5 минут
5. Отсутствуют тесты. // Тесты более менее написал. Хоть что-то. Ибо сути их все равно понять не могу И что именно тестить тоже.


Тут есть опытные люди. подскажите что можно было сделать иначе? спасибо.

Андрей ПанфиловTsyklop,

вот явные косяки ваши:
lombok в проект включен, а вы продолжаете писать геттеры и сеттеры

зависимости optional=true - они про отключение транзитивных зависимостей при использовании модулей - не про ваш проект

в задании параметр nameFilter обязателен, а у вас - нет

ORM - это очевидно не про производительность и ваш stream/parallel здесь не в кассу

тестов фактически нет

я так понял что основная претензия про производительность, но чет какая-то херня со стороны проверяющего: кешировать выхлоп нельзя - здесь пользовательский ввод, поэтому это будет DoS (вообще учитывая что матчинг регулярных выражений это NP задача, то само по себе ТЗ - это DoS) - получается нужно в памяти держать, а объемы не известны (или миллионы - значит меньше лярда?), есть ли уверенность что проблема не в ORM?


1. Не настолько большой класс что бы юзать lombok. Не считаю это чем-то важным. Или то за что можно придраться.
2. спорить не буду. Но сомневаюсь что эта опция глобально что-то изменит.
4. ну стримом я обрабатываю результат. Так быстрее если без него. Что-то да быстрее.
5. а зачем над ними заморачиваться? я вообще понять не могу их сути. Тратишь кучу времени на написание этого. На счет тестов как-то не особо переживаю. В большинстве компаниях есть отдел тестеров которые тестят.

ну я не понимаю претензию:

автор2. Вычитывать все записи из базы на каждый запрос от каждого пользователя неэффективно


А как иначе то? я уже к кеширование добавил.

А вот я не знаю в чем именно проблема. В ответе сказали что эти пункты не выполнены, а что куда и как хз вообще. Ну просто реально если уже делать что бы клиент получал результат не ждя обработки всех записей то это надо юзать WebFlux (или что-то подобное), но условия об этом не говорят.


Просто хочется понять может я тупой или что-то другое...

fixxerЗа счет того, что за один проход по данным отвечаешь на несколько запросов.
А можно увидеть пример такого решения, пожалуйста? уж очень интересно.

andreykaT1) далее, по сервису. ты как то странно создаешь инициальные тестовые данные )) это лишнее ) мог бы просто утиль написать или там скуэль скрипт какой. вообще это имхо лишнее в задании. ты еще и дто в конструктор сервиса передаешь (шта?)


пример?

andreykaT2) ты файндолл делаешь с пагинацией по 200 )) а потом из полученной паги тащишь стримом переборку на совпадение. это лишнее от тебя ждали или там джейпиэй типа repository.findByNameLike("whateverString") - это вообще ОДНА строчка на ВЕСЬ МЕТОД вместо твоей требухи,
либо же простым жпкл запросом типа "select entity e where e.name like :param" либо вообще простым скл нативным запросом (как Вадя любит). - всё-равно одна строка.


1. Я использую не Spring Data JPA, а Hibernate. У него нет repository.findByNameLike , тут все писать ручками надо.
2. Вы наверно не читали условия. Фильтровать только в Java, в SQL нельзя.

andreykaT3) нейминг в целом. но это может я придираюсь. я бы сделал стандартную структуру папок контроллер, сервис, репозиторий, домейн. ну или как то так.


а сейчас разве не так? controller, dao, service, entity. что не так? dao для хибера, для Spring Data JPA пишут repository.

andreykaT3.1) я не думаю что отдавать ентити как есть клиенту это хорошая идея - я бы заюзал маппер и перекатывал бы ее поля на дтоху которую бы и отдавал. но это наверное и не требовалось.


тут согласен, не учел.

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


Какого такого опыта? в чем именно опыта нет? пытаюсь понять это.