админ vs кодер

[grigori]

админ: расказывай что побудило тебя дропнуть базу
кодер: неправильно заполнил конфиг для юниттестов

 

[флоппик]

косяк админа ж, кто ж кодерам дает доступ с правом на дроп

 

[Girakon]

Жизненно, мораль: не будь мудаком, сделай отдельный сервер для тестов

 

[Redjik]

случай из реальной жизни?

 

[MiksIr]

косяк админа ж, кто ж кодерам дает доступ с правом на дроп

Ну это может и не дроп быть, а просто транкейт =)

Жизненно, мораль: не будь мудаком, сделай отдельный сервер для тестов

Порой мораль такую выдадут... смешнее самой истории.

 

[AmdY]

делай бэкапы?

 

[weregod]

а что, перед запуском юниттестов никогда БД не восстанавливают? %)

 

[grigori]

реальный диалог, все под стол со смеху попадали
база dev проблемы как таковой нет, просто размер базы 100 гиг, и админу ее восстанавливать

на drop базы пермиссии нет, а на таблицы-то есть

 

[weregod]

значит одмин и кодер нашли друг друга

 

[Girakon]

реальный диалог, все под стол со смеху попадали
база dev проблемы как таковой нет, просто размер базы 100 гиг, и админу ее восстанавливать

на drop базы пермиссии нет, а на таблицы-то есть

dev база 100 Гигов - это проблема. Зачем столько данных в dev базе?

 

[Gas]

например, быть уверенным что новые фичи работающие со 100 записями, не положат продакшн в 100 гиг

 

[Girakon]

например, быть уверенным что новые фичи работающие со 100 записями, не положат продакшн в 100 гиг

Мое мнение что это не лучший подход, т.к. все равно 1 к 1 нагрузку не с имитируешь, да и затратно мне это кажется по ресурсам держать клон продакшена. Лучше использовать базу гораздо меньшего объема и опираться на данные бенчмарков, если фича с дефектом, то бенчмарк покажет увеличение времени исполнения запросов, экстраполируя эти данные, можно судить о том насколько это плохо отразится на базе в 200 гигов. Но повторю, это только мое мнение.

 

[Yoskaldyr]

Лучше использовать базу гораздо меньшего объема и опираться на данные бенчмарков, если фича с дефектом, то бенчмарк покажет увеличение времени исполнения запросов

на небольшой базе если таблица полностью постоянно находится в пуле скорость выполнения запроса будет практически идентична (в пределах погрешности измерения) и не будет зависеть от того был это фулскан таблицы или выборка по индексу. Но любой фулскан сразу вылезет на реальных данных >100К записей

 

[Girakon]

на небольшой базе если таблица полностью постоянно находится в пуле скорость выполнения запроса будет практически идентична (в пределах погрешности измерения) и не будет зависеть от того был это фулскан таблицы или выборка по индексу. Но любой фулскан сразу вылезет на реальных данных >100К записей

Но разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?

 

[Yoskaldyr]

Но разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?

Конечно можно, но речь то была о другом - о замене реальных данных большого объема, тестовыми данными значительно меньшего объема и о бенчмарках, так бенчмарки на миниданных не помогут.
А вопрос правильного проектирования уже выходит за рамки данного топика

 

[Redjik]

Но разве нельзя выявить фулскан через EXPLAIN еще на этапе проектирования?

Нет, самый тупой пример - создай 3 записи и сделай Explain выборку по индексу

 

[Girakon]

Конечно можно, но речь то была о другом - о замене реальных данных большого объема, тестовыми данными значительно меньшего объема и о бенчмарках, так бенчмарки на миниданных не помогут.
А вопрос правильного проектирования уже выходит за рамки данного топика

Я не видел 100Гб базы, поменьше видел, гигов 10, но на вскидку я думаю в той базе есть таблицы по несколько милионов записей, так вот для таких таблиц, мини данные это думаю как раз 50к-100к записей, следовательно если dev сервер слабже по железу prod сервера на порядок и более, и вы пропустили в сложном запросе несколько фулсканов то думаю все же бенчмарки весьма ожидаемо покажут разницу.

 

[Girakon]

Нет, самый тупой пример - создай 3 записи и сделай Explain выборку по индексу

Не совсем понял к чему вы, к тому что MySQL на небольших таблицах предпочитает фул скан вместо индекса?

 

[grigori]

Girakon если ты знаешь что нам делать и хочешь рассказать - присылай резюме, и если ты реально в теме - с удовольствием послушаем конкретные предложения относительно базы и доработки IT-инфраструктуры

Не совсем понял к чему вы, к тому что MySQL на небольших таблицах предпочитает фул скан вместо индекса?

хм, похоже, ты не в теме, ладно, просто кончай флудить тогда
да, на разных размерах таблиц базы строят разные планы исполнения запроса

 

[Girakon]

Girakon если ты знаешь что нам делать и хочешь рассказать - присылай резюме, и если ты реально в теме - с удовольствием послушаем конкретные предложения относительно базы и доработки IT-инфраструктуры




хм, похоже, ты не в теме, ладно, просто кончай флудить тогда
да, на разных размерах таблиц базы строят разные планы исполнения запроса

Мне просто было интересно почему так, а не иначе. Про зависимости влияющие на построение плана я в курсе.