Пройдіть і поставте тестування продуктивності на Google BigTables (та інших інтегрованих БД)

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

Наприклад, у Google App Engine цілі завантаження сторінок оцінюються як одна операція, яка може включати конкретні операції з базою даних. Ця проблема також, ймовірно, присутня в SQLite та інших інтегрованих БД. Оскільки важко повністю абстрагувати (еквівалент) вибору та вставок, які потрібно перевірити, чи є рекомендовані інструменти бази даних для проведення більш ретельної діагностики за цими видами запитів?

— Брайан Балсун-Стентон
джерело

Чи маєте прямий доступ до відповідної бази даних?

— Stingervz

Так, я написав додаток. І хоч ефективність додатків - це інше питання, я отримую кілька суворих результатів у неприємному запиті, який я написав.

— Брайан Балсун-Стентон

Іноді десяток пар очей - це краща діагностика, ніж аналізатор запитів ... (добре, не так часто)

— jcolebrand

@Brian Я думаю, що ви краще зробите для Stackoverflow такий тип запитань, оскільки це більше питання програмування, ніж питання DBA.

— IamIC

@IanC Drat. Я намагаюся потрапити на великий табір, а не на виставу в цілому. Але я видалю, якщо люди не вважають це питання підходящим. (Я також намагаюся впевнитись, що сайт весь час не є oracle / sql-server / mysql)

— Брайан Ballsun-Stanton

Відповіді:

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

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

Однак бенчмаркінг db дуже важко зробити осмисленим за найкращих обставин, і коли ви порівнюєте різні системи, неможливо узагальнити.

— Кріс Траверс
джерело

Appstats - ключовий інструмент для вимірювання продуктивності в App Engine. Він покаже час, що використовується для кожного RPC, включаючи сховище даних, пам’яті, urlfetch та запити пошти у графічній діаграмі. Зазвичай запити відображаються як "сходи", де кожен запит починається з того моменту, коли закінчився попередній запит, у наступному рядку вниз.

Якщо ви використовуєте розширені асинхронні запити в ndb, ви насправді можете бачити, що запити відбуваються паралельно.

Цей інструмент був для мене величезною допомогою дізнатися, де витрачається час і як оптимізувати запити.

— Brent Washburne
джерело