Поскольку ни один нормальный человек не в состоянии набрать "Гурбангулы Мяликгулыевич Бердымухамедов" без ошибок на слух
то скорее всего в топике речь идет о нечетком текстово поиске.

Для этого поиска мы берем просто все поля вкидываем в поисковой вектор и индексируем. Номер телефона тоже туда можно.

У меня много раз была идея попробовать нарисовать MindMap или экспертную систему по текстовому поиску.
Почему именно так? Да потому-что сам текстовый поиск - это большая и бесконечно сложная постановка.
И если один текстовый поиск работает в 1 случае, то в другом его рецепт может быть не применим
или покажет плохой перформанс. Кому-то нужно просто поискать в документах по предприятию
какое-то ключевое слово. Код проекта например. А кому-то другому в логах лежащих в биг-дата поискать
физлицо. Эти обе постановки суть - текстовый поиск. Но реализации скорее всего будут очень разные.

У Оракла самая невыгодная стоимость владения данными. Если он складывает свои текстовые
индексы в табличные пространства - то нет варианта класть их в большие и дешевые хранилища
Google/AWS/Azure.

Если как то по другому хранит - то я не знаю тогда. Может и выгоднее. Но я-бы при любых
раскладах сначала пробовал Sphinx/ElasticSearch как бесплатные варианты где у меня будет
1000 способов куда ложить индексы. И только в самую последнюю очередь смотрел бы в Оракл.

Если взять две аналогичные системы текстового поиска ElasticSearch и Oracle и дать им один объем данных
и одну задачу - то Oracle будет вам дороже стоить по TCO.

Я не согласен с тем что ElasticSearch сравнивается с Жигулями.

Хорошо. Пускай погрузчик.

Я не согласен с такой постановкой вопроса. Вы посылаете меня читать про SES для чего?
Что-бы я сам искал какое-то доказательство для чего-то. Так не делается в форумах.

Доказательство - это задача утверждающего. Вот вы и доказывайте. Мяч на вашей стороне вобщемто.

Я отвечу так. Я использовал ElasticSearch для поиска в логах сведений об ошибках.
Разумеется логи - англоязычные. Поддерживает ли конкретно ElasticSearch русский я не знаю.
Но по стеку технологий. Эластик использует Apache Lucene а тот в свою очередь имеет модули
поддержки русского языка. Есть алгоритмы стемминга.

По поводу как "обстоят дела" - я не могу ответить. Это слишком размытый вопрос. Это
вопрос требующий глубокого погружения в область. У меня нет столько времени.

Если у вас есть сведенья о дефекте ElasticSearch - то прошу вас эти сведенья предоставить.

Подача намёков на дефект, согласитесь выглядит как легкий троллинг.

Нет. Это так не работает. Обычно текстовый поиск индексирует токены. Это ключи которые
покрывают отражают документ и по которым впоследствии строится формула рейта. Тоесть
насколько близок документ к искомому поисковому выражению.

Токены для разных языков получаются по разному. Для русского языка обычно используется
алгоритм 1) отбрасывания стоп-слов. 2) Стемминга, тоесть свёртки всех падежей и склонений
к основе. Apache Lucene (engine для Elastic) под капотом использует алгоритм SnowBall для стеммингования русских
слов. SnowBall последовательно отсекают суффиксы и окончания от слова до тех пор пока оно не достигнет
некого устойчивого состояния. И эта основа - идет в индекс как ключ.

Отдельно также идет алгоритм лемматизации. Правда я не знаю используется ли лемматизация в Elastic.
Также нет точной информации подключается ли модуль русского языка в Elastic. Это надо смотреть в настройках
Elastic.

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

Все прочие алгоритмы упрощения текстового поиска - идут обычно от незнания. Люди которые не разбираются
в текстовом поиске часто представляют себе задачу по другому. Или представляют себе что текстовый поиск
это просто очередная разновидность grep или не дай бох B+Tree индекса в БД.

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

Я-же говорю - селективность упадет. Как ты будешь различать русское "море" и английское "more" ?