в нашей системе база данных контактов хранится в PostgreSQL. Мы храним достаточно много информации о каждом контакте, и эта информация хранится во многих таблицах.
Наши пользователи хотят иметь очень гибкие параметры поиска. Поскольку объединение всех необходимых таблиц для поиска занимает много времени, мы решили использовать Compass (это было около года назад), чтобы проиндексировать каждый контакт во время сохранения / обновления, а затем выполнить поиск в Compass.
Проблема в том, что теперь, когда у нас много пользователей, которые одновременно манипулируют контактами (обновление, импорт контактов, добавление в группы и многие другие ...), каждое сохранение / обновление конечного пользователя блокирует компас index и другие пользователи должны ждать, пока он не будет выпущен. Часто мы получаем исключение тайм-аута блокировки, хотя тайм-аут установлен на 2 минуты. В целом у нас очень низкая производительность - сохранение одного контакта в пиках может занять 50 с.
Очевидно, что индекс является узким местом для операций записи. Мы могли бы выполнять индексацию асинхронно, но тогда я боюсь, что выполнение отчетов в высоких пиках может создать противоречивые отчеты из-за длинной очереди контактов для индексации.
Есть ли у вас какие-либо предложения о том, как изменить архитектуру или как решить эту проблему?