Вообще, это делается как-то так:
1. Формулируются ожидания с т.з. бизнеса. В данном случае понятие "дико медлено" нужно выразить как-то объективно. Например. Имеем: поиск по ключевой фразе А при объеме данных Х заниманет N секунд. Поиск по ключевым фразам типа Б вообще невозможен. Требуется: поиск по фразе А и Б должен занимать не более N/10 секунд для объема данных до Х*1000.
Формулируются внятные тесткейсы и пишутся тесты производительности, позволяющие позже проверить, достигнуты ли эти ожидания.
2. Анализируется архитектура на предмет возможности / трудозатрат для введения новой технологии. Если архитектура типа Новогодней елки (тронул в одном месте - посыпалось все), то на этом введение может и закончиться, т.к. окажется, что для этого понадобится 90% переписать заново. Если же архитектура это позволяет, то проблему сначала нужно изолировать (абстрагировать поиск каким-то интерфейсом / фасадом). Для этого (если их еще нет) пишутся тесты, закрепляющие функционал, потом рефакторится код.
3. Параллельно с 2 на основании 1 ищется адекватная технология. Для этого выбираются минимум 2~3 альтернативы, изучаются (возможно, на них пишутся прототипы) и для них составляется таблица, в которой учитываются не только ожидаемый прирост производительности, но и вещи типа запросов к ресурсам, сложность обучения, вопросы лицензирования и т.д. По результатам обоснованно выбирается подходящая технология и... вперед и с песней :)
4. Пишется альтернативная имплементация, которой на стенде заменяется "старая", прогоняются тесты (по функционалу и производительности). Если все прошло удачно - архитектору премию и выкатываем на продакшн. Если облом - архитектору выговор, и все сначала :)
Простой
Простой
Простой
