Каморка

Есть проблема не знаю как ее решить. Пробема вышлядит следуюшим образом.
Есть база данных в которую пишется телеметрия. Пишется быстро и помногу. По сути внутри одна таблица без индексов и ключей, в которую десяток сереверов пишет данные. Никто ее он лайн не читает. Есть пара опез (изв ) сотрудников которые хотят ету информацию обрабатывать, ето не совсем он лайн потому как они генерят репорты делают сложные свои queries и прочий бред. База телеметрии очень быстро растет. Хочется следующего: Периодически снимать с базы снапшоты и убивать в ней все записи, снапшоты я потом могу передавать на обработку двум опез(изв)сотрудникам. И при етом никак не задевать (замедлять лочить) процесс добавления новых записей в ету базу данных (таблицу)

Есть идеи? В МайСиквеле мы ето рещали с помощью black hole replication когда новые записи копились только в бинарном логе, который затем реплецировался. Ничего подобного найти в сиквел серевере не могу.

(Пиво легко)

А OLAP попробовать? Там интегрированный Микрософтовский анализис сервис - обещают эффективное обновление данных...

я наверное неправильно изложил что надо (Как обычно). Нужнотипа такого
1. From Base1.Table1 select all records (without locking last using page all almost all)
2. Bulk insert all records from request 1 to Base2.Table1
3. Delete all records from request 1.

ну и все ето в джоб какой-то.

Вопроса собственно два (1) Я не полный бред говорю? (2) ак при организации такой задачи не завалить производительности базы данных 1 (ето я про лок таблицы) Ну и собственно (3)-й бонусный вопрос как ето реализовать аккуратно?

я естественно не dba а так программер который знает как использовать group by и отличает кластерные индексы от обычных=)

aissp писал(а):я наверное неправильно изложил что надо (Как обычно). Нужно типа такого
1. From Base1.Table1 select all records (without locking last using page all almost all)
2. Bulk insert all records from request 1 to Base2.Table1
3. Delete all records from request 1.
ну и все ето в джоб какой-то.
Вопроса собственно два (1) Я не полный бред говорю? (2) ак при организации такой задачи не завалить производительности базы данных 1 (ето я про лок таблицы) Ну и собственно (3)-й бонусный вопрос как ето реализовать аккуратно?
я естественно не dba а так программер который знает как использовать group by и отличает кластерные индексы от обычных=)

Почему же, я все понял, что надо и предложил другой путь решения.

aissp писал(а): Вопроса собственно два (1) Я не полный бред говорю? (2) ак при организации такой задачи не завалить производительности базы данных 1 (ето я про лок таблицы) Ну и собственно (3)-й бонусный вопрос как ето реализовать аккуратно?

1. Нет, не полный. 2. А селект будет лочить таблицу? ИМХО производительность снизится - из-за дополнительной задачи, но не из-за локов. 3. Маленькими порциями?

Ну значит я не понял ответа В силу дремучести

3. Что есть маленькие порции? Делать селект по таймстампу? Мне кажется не выгодно. Хотелось типа взять все страницы кроме последней текущей рабочей, и только их откопировать а затем и прибить.

aissp писал(а):Ну значит я не понял ответа В силу дремучести

Наверное я его неправильно изложил... (с) aissp

сделать триггер ON INSERT и енейбл его когда надо
копирнуть тейбл
стереть тейбл
дисейбл триггер

aissp писал(а): 3. Что есть маленькие порции? Делать селект по таймстампу? Мне кажется не выгодно. Хотелось типа взять все страницы кроме последней текущей рабочей, и только их откопировать а затем и прибить.

У вас специфическая ситуация - таблица только пишется, можно просто тупо ставить ЛИМИТ столько то записей от начала.
Если лог пишется - миллион записей в час, то маленькими порциами будет по 20 тыс. в мин, или по 100 тыс. в 5 минут - зависит от того насколько просадит производительность селект 100 тыс. записей.
По моим наблюдениям, селект около 50000 не очень хитро сделанных записей в MySQL - занимает несколько секунд на не самом новом сервере.

Наверное, можно совсем просто - забабахать транзакцию, переименовать таблицу, создать новую таблицу, закончить транзакцию.

помрут сервера. bcp видимо буду использовать.... (пока не найду лучшего рещения)

я что-то не врубился, а репликэйшн не спасет отца русской демократии? Ну обычная такая паблишер-сабскрайбер (мастер-слэйв)?
10 лет назад вполне работала на 6.5 - дык с тех лет сколько воды утекло. Должна работать еще лучше! Наверное уже куча всяких режимов. Ведь репликация идет отдельным тредом и не лочит таблицы. По-моему.

вот тут как раз о разделении олтп и дата уорхауз с помощью репликации:

http://msdn.microsoft.com/en-us/library ... .100).aspx

или тебе что-то другое надо?

Не подходит к сож аж два раза. В таблице телеметри нету ключевых полей, без них реплицировать отказывается. (ну ето бог с ним не сташно можно добавить) а вот второе мастер таблица то растет... И растет она сейчас примерно на 200 мегов в сутки, мне она в таком объеме нафиг не нужна. Поетому хочеться не copy&paste делать а cut&paste/

Тьфу на меня неужели опять плохо объяснил.

С благодарностью восприму идеи.

aissp писал(а):Не подходит к сож аж два раза. В таблице телеметри нету ключевых полей, без них реплицировать отказывается. (ну ето бог с ним не сташно можно добавить) а вот второе мастер таблица то растет... И растет она сейчас примерно на 200 мегов в сутки, мне она в таком объеме нафиг не нужна. Поетому хочеться не copy&paste делать а cut&paste/

Тьфу на меня неужели опять плохо объяснил.

С благодарностью восприму идеи.

все нормально объяснил. можно было-бы удалять суточный прирост, но надо как-то защитить сабскрайбера. фильтр на операции можно ставить на репликацию (типа insert, update реплицируем, а delete ни-ни)? Еще лучше переводить таблицу у сабскрайбера в рид-онли если это возможно у мелкомягких, и просто транкейтить оригинал, периодически, по самое ля-ля. О, кстати, а почему-бы не сделать две таблицы у слэйва? Одна прямая реплика, другая уже хранилище. периодически сливать с реплики в основную и транкейтить на мастере?