|
|
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
Добрый день! Подскажите, пожалуйста, есть ли готовое решение, подходящее для моего случая: есть N баз данных на удаленных серверах, есть центральная БД. Необходимо из всех удаленных БД сливать данные из одной таблицы в центральную БД. Структура таблиц одинакова, никакой логики, кроме переноса данных (select * from table@remotedb / insert selected into rootdb / delete selected from remotedb) нет. Чтобы не говорить огород из dblink'ов. Благодарю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 21:12:16 |
|
||
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
fabler, Londiste говорят умеет. Я городил огород, только файлами гонял, специфика приложения больше подходила к такой реализации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 21:28:41 |
|
||
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
fabler, londiste умеет режим merge, если у вас есть пк на таблице и пк разделены по нодам (не перекрываются) но не умеет это дело корректно и быстро восстанавливать после сбоя только одной ноды. Поскольку это пк-репликация, изначально не предусматривающая хранения id ноды, то выяснить, какое подмножество отреплицированных ранее записей нужно сравнивать с результатом снепшотного COPY (ноды) при рестарте (ресинк) репликации только одной ноды оно не может. но можно над ним надстроить что-хотите (используя его ивент-репликацию и встроенный pgq), хоть свою "трансформирующую репликацию" -- в таблицу даже другой структуры (при том же наличии пк в таблицах на нодах). PS: просто собирать данные с нод (даже не раскладывая в центре в таблицы) можно посредством plproxy. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 12:10:52 |
|
||
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
Нужно только определиться, нужна репликация (ноды посылают данные в центральную базу по мере возникновения) или таки нужен сбор данных (центральная база сама инициализирует сбор данных). И уточнить условие, обязательно ли удалять данные с нод после копирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 13:49:32 |
|
||
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
удалять из локальных баз нужно, PK в таблице нет в принципе (он там не нужен в принципе) кто инициирует - не особо важно. похоже, что сращу ничего на ум не пришло из имеющегося инструментария? надо пилить свой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 22:41:53 |
|
||
|
агрегация данных из таблиц нескольких БД в центральной БД
|
|||
|---|---|---|---|
|
#18+
fabler удалять из локальных баз нужно , PK в таблице нет в принципе (он там не нужен в принципе) кто инициирует - не особо важно. похоже, что сращу ничего на ум не пришло из имеющегося инструментария? надо пилить свойгм. ваша задача на порядок проще. телепортация проще репликации тем, что не надо следить за состоянием исходника. его надо затереть и забыть. лондайст (к примеру) вам в руки (если нужна автономность и асинхронность близкая у синхронности). -- могу дать наводку на трюк, но воздержусь скрипач пк не нужен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 23:36:55 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38533811&tid=1998884]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
192ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 481ms |

| 0 / 0 |
