Интеграция таблицы из PostgreSQL в MySQL

[LeRatO]

Доброе время суток.

Дано:
Есть Таблица1 (база Mysql, сервер1 - около 9 мнл.объектов) и Таблица2 (база PostreSQL, причем на сервере2 - более 40млн.объектов). В основном движок работает с Таблицей1, отбирает записи по критериям, собственно обычный поиск.. Но есть ряд запросов, которые учитывают критерии Таблицы1 и Таблицы2, например, SELECT ... FROM... WHERE Таблица1.terr="45000" AND Таблица2.count_arb>0;
Раньше база с Таблицей2 тоже была на MySQL на сервере1, и проблем не было. Но было принято решение перенести базу с Таблице2 на postgreSQL и перестать обновлять старую (на MySQL).

Вопрос:
Как теперь сохранить работоспособность запроса, используя обновляемую базу на PostrgeSQL?

Видимые варианты решения:
1) организовывать что-то вроде псевдо-репликации с базы postgreSQL Таблицы2 в аналогичную в MySQL... но это придется делать с периодичностью раз в 2 недели (частота обновления базы) + частичное обновления не получится, т.к. в новой базе нет никакого признака новизны записей типа даты загрузки... и тащить каждый раз придется все более 40млн.записей...
2) организовать (если такое вообще возможно) подключение таблицы из базы postgreSQL в базу MySql, именно так а не наоборот - база в MySQL главнее.

Может кто-то сталкивался с подобной проблемой и знает как ее решить?

 

[fixxxer]

3) Делать два отдельных запроса, заменить join на ручное формирование in() для второго.

 

[fixxxer]

Но было принято решение перенести базу с Таблице2 на postgreSQL

с какой целью?

 

[LeRatO]

с какой целью?

Сложно сказать, видимо посчитали, что смена СУБД резко сократить время ответа на запрос. Но реальный исполнитель не просто перенес базу, а поменял структуру... бог с ней со структурой, это решаемо, но отсутствие поля с признаком новизны записей - кошмарное решение...

 

[LeRatO]

3) Делать два отдельных запроса, заменить join на ручное формирование in() для второго.

нереально делать два запроса отдельно. по первому критерию записей может быть до 2млн..... представляете себе размер списка в IN(). + общее время выполнения запроса будет непреемлемым

 

[AnrDaemon]

Простите, вы сами вообще соображаете, чего просите?…

 

[LeRatO]

Простите, вы сами вообще соображаете, чего просите?…

Нужно решение... либо ответ что это нереально.

Хотя уверена, что решение есть, пусть даже через "одно место"... Например, тот же вариант с экспортом в обменный формат из Таблицы2 postgreSQL с загрузкой в аналог-Таблица2 на MySQL - это решение... не оптимальное и дурацкой, но решение...

Весь вопрос именно в том, есть ли еще варианты

 

[AnrDaemon]

А какие существуют варианты закручивания метрического болта в дюймовую гайку?…

 

[fixxxer]

нереально делать два запроса отдельно. по первому критерию записей может быть до 2млн..... представляете себе размер списка в IN(). + общее время выполнения запроса будет непреемлемым

А если сделать ваш п.2, думаете, там какой-то черной магией будет работать иначе? Точно то же самое будет, только на уровне foreign database-плагина.

Если делать п.1, то непонятно зачем уносили.

 

[LeRatO]

А если сделать ваш п.2, думаете, там какой-то черной магией будет работать иначе? Точно то же самое будет, только на уровне foreign database-плагина.

Если делать п.1, то непонятно зачем уносили.

По п.1 - решение... ох, если бы еще спросили перед переносом, цены бы не было... и проблемы этой не было бы