Получите и разместите тестирование производительности в Google BigTables (и других интегрированных БД)


17

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

Например, в Google App Engine все загрузки страниц оцениваются как одна операция, которая может включать определенные операции с базой данных. Эта проблема также, вероятно, присутствует в SQLite и других интегрированных БД. Поскольку трудно полностью абстрагировать (эквивалентно) выборки и вставки, которые необходимо протестировать, существуют ли какие-либо рекомендуемые инструменты базы данных для более тщательной диагностики таких запросов?


У вас есть прямой доступ к рассматриваемой базе данных?
Стингервз

Да, я тот, кто пишет приложение. И хотя производительность приложения - это другой вопрос, я получаю довольно серьезные потери производительности в написанном мной противном запросе.
Брайан Баллсун-Стентон

Иногда дюжина пар глаз является лучшей диагностикой, чем анализатор запросов ... (хорошо, не так часто)
jcolebrand

@ Брайан, я думаю, вы бы лучше справились с Stackoverflow с этим типом вопросов, поскольку это скорее вопрос программирования, чем вопрос DBA.
IamIC

@IanC Drat. Я пытаюсь получить представление о Bigtable, а не о производительности в целом. Но я удалю, если люди не считают этот вопрос подходящим. (Я также пытаюсь убедиться, что сайт не является oracle / sql-server / mysql все время)
Брайан Баллсун-Стэнтон

Ответы:


1

Мне кажется, ваша проблема в том, что вы пытаетесь протестировать показатели производительности, которые плохо поддерживаются в базовом БД. Это очень затрудняет сравнение производительности в разных системах, поскольку базовые подходы очень разные. Я не думаю, что можно сравнивать яблоки с яблоками так же, как я не думаю, что можно сравнить яблоки с яблоками подходов типа ORDBMS к подходам типа RDBMS. Проблемы производительности просто слишком разные, и если Stonebraker прав, что оптимизация ORDBMS для тестов TPC-C упускает смысл, то для систем, которые находятся еще дальше друг от друга, это будет невозможно. (Я думаю, что он здесь, однако, только тогда, когда функциональность ORDBMS вступает в игру.)

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

Однако сравнительный анализ БД очень сложно сделать осмысленным в лучших обстоятельствах, и когда вы сравниваете разнородные системы, становится невозможным обобщение.


0

Appstats является ключевым инструментом для измерения производительности в App Engine. Он покажет время, используемое для каждого RPC, включая хранилище данных, memcache, urlfetch и почтовые запросы в графической диаграмме. Обычно запросы отображаются в виде «лестницы», где каждый запрос начинается с точки, в которой завершился предыдущий запрос, на следующей строке вниз.

Если вы используете расширенные асинхронные запросы в ndb, вы можете увидеть, что запросы выполняются параллельно.

Этот инструмент очень помог мне понять, на что тратится время и как оптимизировать запросы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.