Запускаем файрбаг, жмем на динамическую кнопку, смотрим куда уходит запрос и с какими параметрами. Эмулируем подобные запросы напрямую с нужными параметрами... 100 раз уже преодоленные грабли )))
MSAFT: 1 минуты? Ужас какой.... Мы на ТИ боролись (уверен они и сейчас это делают) за каждые 100мс, а уж как это сделать выбирайте сами, есть множество способов. Если скорость загрузки хоть немного падает, то в фидбек сразу падают жалобы, что поиск стал очень долгим.
Думаю вы понимаете, что под каждого контрагента должен быть свой парсер, в том числе если у них AJAX загрузка результатов поиска. И если у одного контрагента разметка поменяется, то у вас не должно все упасть и завалить юзера нотисами, варнингами т.д.
В тур как правило входит отель, у которого куча параметров (румсайзы, вид из номера, питание и т.д.) и вот у некоторых контрагентов одна и та же аббревиатура может подразумевать слегка различные понятия, либо называться такой же аббревиатурой, но уже с какой-то приставкой. Вам придется их как-то группировать по смыслу.
Если у вас есть фильтры (а они должны быть), то скорость их загрузки тоже должна быть очень высока и они должны быть связаны. т.е. если юзер выбрал турцию, то должны показывать только турецкие отели, а румсайзы должны показываться только тех отелей, что есть в списке. Питание должно быть только то, которое предоставляют отели из списка и т.д. выбираете какой-то отель, соответственно фильтры перерисовываются под этот отель (румсайзы, питание и т.д.). Это одна из серьезных задач, которую придется решать, поскольку в базе только для фильтров будет множество данные и разумеется выборка с кучей джойнов будет очень долгой, так что придется делать различные кеши т.д.
MSAFT:
На ТИ например реализовано несколько способов получения актуальной цены:
1. Туры выводятся из кеша и в каждом туре есть кнопка для получения актуальной цены.
2. В фильтре есть галка 100% актуальность. Если она стоит, то туры будут парситься сразу с контрагентов.
Если вы хотите парсить при каждом поиске, то вам стоит учесть то, что контрагент может долго не отвечать (10 - 20 - 30 сек), или вообще не ответить. Естественно пользователь столько ждать не захочет. Вам уже через максимум 5-7 сек надо ему что-то показать. А как быть в таком случае, если у запоздалого контрагента цена самая низкая? Поставите его самым последним? Это лишь 1 из тех подводных камней которые ожидают вас на этом пути) А их там огого сколько)
20кк - это я так, чисто условно написал. Естественно, если учесть что допустим имеется 10к компаний. Каждая заводит в среднем 10 сделок в день. Получается в год уже 36кк. Не говоря уже про различные реляционные таблички для MANY_MANY связей. Допустимая скорость ответа не более 0.7 сек. По поводу что чаще, тут нет однозначного ответа. К примеру для таблицы с клиентами чаще чтение, для сделок 50\50. Про репликации я знаю, но это получится куча дублей БД. Проще было бы действительно разделить базы между собой)
По поводу SQL injection тут: stackoverflow.com/a/60496