Возникла следующая ситуация. Требуется оптимизировать базу данных, поскольку у заказчика очень долго строятся отчеты (несколько часов). Саму базу мне дать не могут по причине наличия в ней конфиденциальной информации, у меня же имеется база с идентичной схемой, но в ней минимальное количество данных, по которым не получается понять где узкие места в производительности.
Начал гуглить, сразу наткнулся на EMS Data Generator (генерирует рандомные данные в таблицах), но он во-первых платный, во-вторых как мне кажется проблемы производительности скорее связаны с JOINами, чем количеством записей в таблицах. Т.е. скорее всего получится, что моя база с кучей рандомных записей и база клиента будут работать с разной производительностью на одних и тех же запросах.
Вообщем вопрос в том, как хотя бы приблизительно воспроизвести структуру данных. Собрать информацию о ссылках между таблицами...
Может быть кто-то уже сталкивался с подобной проблемой, или знает полезный софт?
Здравствуйте, Luxo, Вы писали:
L>Добрый день!
L>Возникла следующая ситуация. Требуется оптимизировать базу данных, поскольку у заказчика очень долго строятся отчеты (несколько часов). Саму базу мне дать не могут по причине наличия в ней конфиденциальной информации, у меня же имеется база с идентичной схемой, но в ней минимальное количество данных, по которым не получается понять где узкие места в производительности. L>Начал гуглить, сразу наткнулся на EMS Data Generator (генерирует рандомные данные в таблицах), но он во-первых платный, во-вторых как мне кажется проблемы производительности скорее связаны с JOINами, чем количеством записей в таблицах. Т.е. скорее всего получится, что моя база с кучей рандомных записей и база клиента будут работать с разной производительностью на одних и тех же запросах.
L>Вообщем вопрос в том, как хотя бы приблизительно воспроизвести структуру данных. Собрать информацию о ссылках между таблицами... L>Может быть кто-то уже сталкивался с подобной проблемой, или знает полезный софт?
Может попросить их заменить конфиденциальные данные каким-нить мусором?
Поскольку схема есть, можно спросить, что там собственно секретно и самостоятельно написать скрипт изменяющий эти данные
(так, чтобы на производительности запросов сказалось минимально).
К сожалению, в действительности все выглядит иначе, чем на самом деле.
Luxo пишет:
> Возникла следующая ситуация. Требуется оптимизировать базу данных, > поскольку у заказчика очень долго строятся отчеты (несколько часов). > Саму базу мне дать не могут по причине наличия в ней конфиденциальной > информации, у меня же имеется база с идентичной схемой, но в ней > минимальное количество данных, по которым не получается понять где узкие > места в производительности.
БД, к сожалению, нельзя "оптимизировать" просто так. Нужно иметь
конкретные данные, и конкретные запросы. С другими данными у вас
и проблемы могут быть другие. Не, ну конечно, частично какие-то
проблемы вы отловить сможете. Но не факт, что все.
Как пример, могу привести проблемы с неравномерной селективностью
по каким-то значениям полей индексов. У вас какое-то значение поля индекса
встречается часто (скажем, 40%), какое-то — редко. С редким значением
в поле запросы будут "летать", с частым — будут проблемы. Вы, имея
другие данные, никогда эту проблему не отловите, и, зная о ней,
возможно, другими данными её никогда не смоделируете.
> Начал гуглить, сразу наткнулся на EMS Data Generator (генерирует > рандомные данные в таблицах), но он во-первых платный, во-вторых как мне
Рандомный генератор это как раз последнее дело тут использовать.
> кажется проблемы производительности скорее связаны с JOINами, чем > количеством записей в таблицах. Т.е. скорее всего получится, что моя
JOIN-ы скорее всего как раз МОЖНО отлаживать и на других данных. Главное,
чтобы кол-во записей в таблицах было примерно таким же, как и в боевой базе.
> Вообщем вопрос в том, как хотя бы приблизительно воспроизвести структуру > данных. Собрать информацию о ссылках между таблицами...
Ну, лучше всего написать некую обезличивалку данных, которая
составит для всех данных словари для замены реальных значений
их псевдонимами. Но чтобы это сделать у вас уйдёт достаточно много времени,
естественно. Думаю, лучше всего убедить просто людей, что ты -- честный
и порядочный человек и не будешь ничего плохого делать с данными.
2MasterZiv
был опыт оптимизации оракла "просто так".
по трейсу, который клиент включит, и отправит результат почтой.
потом пара писем с вопросами про размер таблиц и данных. результат — скрипт для админа, с обьяснениями, как накатывать и просьбой ответ базы выслать сразу, дабы не влететь на к-л косяк. скрипт отката так же был. во
T>Может попросить их заменить конфиденциальные данные каким-нить мусором?
T>Поскольку схема есть, можно спросить, что там собственно секретно и самостоятельно написать скрипт изменяющий эти данные T>(так, чтобы на производительности запросов сказалось минимально).
Боюсь, что сами они это делать не будут)
Пожалуй действительно что-то придется написать — скрипт или приложение.
Здравствуйте, MasterZiv, Вы писали:
MZ>БД, к сожалению, нельзя "оптимизировать" просто так. Нужно иметь MZ>конкретные данные, и конкретные запросы. С другими данными у вас MZ>и проблемы могут быть другие. Не, ну конечно, частично какие-то MZ>проблемы вы отловить сможете. Но не факт, что все.
MZ>Как пример, могу привести проблемы с неравномерной селективностью MZ>по каким-то значениям полей индексов. У вас какое-то значение поля индекса MZ>встречается часто (скажем, 40%), какое-то — редко. С редким значением MZ>в поле запросы будут "летать", с частым — будут проблемы. Вы, имея MZ>другие данные, никогда эту проблему не отловите, и, зная о ней, MZ>возможно, другими данными её никогда не смоделируете.
Собсна отсюда и проблема
MZ>Рандомный генератор это как раз последнее дело тут использовать.
Тоже пришел к такому выводу.
MZ>Ну, лучше всего написать некую обезличивалку данных, которая MZ>составит для всех данных словари для замены реальных значений MZ>их псевдонимами. Но чтобы это сделать у вас уйдёт достаточно много времени, MZ>естественно. Думаю, лучше всего убедить просто людей, что ты -- честный MZ>и порядочный человек и не будешь ничего плохого делать с данными.
К сожалению убеждение не срабатывает. Это БД корпоративного приложения и утечка инфы грозит, как я понимаю, большими проблемами для того, кто ее вынес. Так что вряд ли найдется камикадзе.
По поводу обезличивалки уже были мысли, похоже придется заняться... но это действительно долгий процесс.
Кстати тут еще может проблема возникнуть) надо будет убедить товарищей, что шифрование идет необратимое
В текущей версии (у клиента) используется MySQL 4.1
Работаем над переходом на PostgreSQL 8.3, возможно это само по себе увеличит производительность. Плюс в PostgreSQL есть возможность соорудить Materialized Views, но без живых данных будет туго.
B>2MasterZiv B>был опыт оптимизации оракла "просто так". B>по трейсу, который клиент включит, и отправит результат почтой. B>потом пара писем с вопросами про размер таблиц и данных. результат — скрипт для админа, с обьяснениями, как накатывать и просьбой ответ базы выслать сразу, дабы не влететь на к-л косяк. скрипт отката так же был. во
Надо обдумать и такой вариант, спасибо) Правда есть сложность, поскольку я имею связь с инженером, который периодически выезжает на предприятие заказчика... Прямого доступа к админу нет
Здравствуйте, Tigor, Вы писали:
T>Может попросить их заменить конфиденциальные данные каким-нить мусором?
Было уже... Все ФИо в БД заменили на привычное "Иванов Иван Иванович", персоналки, телефоны... В общем, сгенерировали стандатрный мусор. Отдали нам базу. Тестим — летает все! Причем даже на более слабой машине, чем у заказчика. В общем, пришлось ехать туда, смотреть все на месте. Ну и трейсы предварительные сильно помогли вплотную подобраться к слабым местам.
Здравствуйте, LuciferArh, Вы писали:
LA>Здравствуйте, Tigor, Вы писали:
T>>Может попросить их заменить конфиденциальные данные каким-нить мусором?
LA>Было уже... Все ФИо в БД заменили на привычное "Иванов Иван Иванович", персоналки, телефоны... В общем, сгенерировали стандатрный мусор. Отдали нам базу. Тестим — летает все! Причем даже на более слабой машине, чем у заказчика. В общем, пришлось ехать туда, смотреть все на месте. Ну и трейсы предварительные сильно помогли вплотную подобраться к слабым местам.
Ну так не надо было ВСЕ ФИО менять на Иванов Иван Иванович
Каждое ФИО надо было менять на другое уникальное
К сожалению, в действительности все выглядит иначе, чем на самом деле.
Luxo пишет:
> MZ>Рандомный генератор это как раз последнее дело тут использовать. > > Тоже пришел к такому выводу.
Ой, я тут прочитал свой пост, хочу скорректировать могущее сложиться
ложное впечатление от него. Я ни в коем случае не хочу сказать, что
подобные тулзы для генерации тестовых данных для баз данных абсолютно
безполезны. Нет, конечно. Они очень даже полезны, и для отладки,
и для первичного выявления проблем производительности после разработки.
НО не для разбирательств с конкретными проблемами производительности
конкретной БД.
Luxo пишет:
> По поводу обезличивалки уже были мысли, похоже придется заняться... но > это действительно долгий процесс.
Ну как же, обратимое, если иметь обратный ключ. Вам нужно однозначное
отображение одного множества на другое, а оно обратимо.
Ну я не знаю, как они сами-то с этим работают ? Неужели отстреливают,
как только от монитора отходит ? Ну, в крайнем случае, пошлите их
подальше, пусть сами тогда мучаются.
Здравствуйте, Tigor, Вы писали:
T>Ну так не надо было ВСЕ ФИО менять на Иванов Иван Иванович T>Каждое ФИО надо было менять на другое уникальное
я обычно тестовые данные циклом генерю там можно любое количество ноликов в размере цикла поставить.
у меня имена стандартно name1,name2,name3... если надо уж совсем разные, то можно 1_name_1...23456_name_23456. bo
