LINUX.ORG.RU

MySQL агрегация результатов запроса из двух баз.


0

0

Есть 2 совершенно идентичные по структуре базы: текущая и архивная. В текущей базе находятся наиболее последня информация, в архивной - то, что уже используется редко. Данные обеих баз - не пересекаются. То есть во врема переноса в архив - в текущей безе соотвествующие записи удаляются.

Есть запросы (для репортов) которым необходимо данные из обеих баз. Если сделать простое оъединение (напр. для запросов содержащих COUNT, GROUP), то могут получиться дублированные строки. Как их объединить - пока хз...

Есть мысль - предопределить запросы которые могут идти к обеим базам, и описать правила аггрегирования результатов. Возможно придётся использовать временные таблицы... Но этот вариант не очень прозрачен, т.к. все возможные запросы нужно определять.

Возможно кто-то сталкивался с подобной проблемой, и существуют ли решения для аггрегирования результатов из 2-х идентичных баз?

Заране спасибо.

★★

union?

Если данные не пересекаются - как дублированные строки получаются? Тока не вздумай использовать view - индексы не будут использоваться! (кто щас скажет, что mysql быстрее postgresql ?) Сам на такое нарвался - прижлось вручную view городить.

anonymous
()
Ответ на: комментарий от anonymous

Да нет. Прямой Union тут не подойдёт, так как запросы к разным базам.
Тут нужно внешний инструмент, что-то типа DBI:Multiplex (правда он не
умеет собирать результаты запросов к разным таблицам)

Немного на пальцах:

Есть таблица test (name char, trans_dat date).
В текущей базе:
name_1  01-01-2007
name_2  01-02-2007

В архиве
name_1  01-01-2006
name_1  01-02-2006
name_2  01-02-2006

Если мы рассплитуем оба сервера запрос типа
SELECT COUNT(*), name FROM test GROUP BY name
и объединим результат - получим:

1   name_1   ; из текущей базы
1   name_2   ;
2   name_1   ; из архива
1   name_2   ;

А дожно быть:

3   name_1
2   name_2

Вот и репу чешу, что делать :)

qqqq ★★
() автор топика
Ответ на: комментарий от qqqq

На самом деле вопрос не столько MySQL-ный, он подойдёт вообще для агрегации данных из серверов любых типов. (В Т.ч. и для Postgres) важна суть: есть текущая база и есть архивна. И нужно получить из друх данных ракой результат, как если бы эти базы били единой...

qqqq ★★
() автор топика
Ответ на: комментарий от mv

>Храни архив в той же базе в другой таблице нафига тогда вообще разделение на архив и нормальную базу. В том то и всё фишка, что архив не то что бы в другой базе, но вообще на другом серваке. Тем самым облегчается текущая. )

qqqq ★★
() автор топика
Ответ на: комментарий от qqqq

А есть ли смысл на другом серваке?
Чем ты "облегчаещ" текущую базу - ну будет еще Хгигов забито архивом. А на другом сервере храни резервную копию.
Храни в другой схеме - backup_mybase, тогда и union поможет.

А если только другой сервак, то нужен второй коннект и объединять придется на клинте, например запросив из архива и результат запроса запихнуть во временную таблицу и потом объеденить с первой )
Ну это как то неправильно )

спроси на sql.ru

anonymous
()
Ответ на: комментарий от anonymous

База облегчается сет, что текущая содержит около 5% записей, а архивная 95% :) Тем не менее спасибо. попробую на sql.ru спросить.

qqqq ★★
() автор топика
Ответ на: комментарий от qqqq

вобщем на sql.ru тоже ни к чему не пришли.

В действительность пришёл к выводу, что нужно просто чаще перекладывать данные в архив. Тогда он будет содержать полную инфомацию из обеих баз - минус период перекладывания. То есть архив и текущая база могут содержать пересекающиеся данные.

Затем текущая база просто подчищается от старых записей.

Тогда будет всё хорошо: сводные данные - в наиболее полной архивной базе, а активные - в текущей.

qqqq ★★
() автор топика
Ответ на: комментарий от Dramokl

>а DBLINKов в MySQL нет, в оракле бы сделал через них

В постгресе есть. Он может к мускулю зацепиться через dbi-link. Может быть им попробовать... Правда там есть проблемы с join-ами и типами при импорте.

qqqq ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.