Просто о сложном в тестировании СУБД на примере PostgreSQL

Доклад раскрывает проблематику тестирования СУБД на примере PostgreSQL.

Видео: https://www.youtube.com/watch?v=XN8nTX35a6c
http://2016.heisenbug-moscow.ru/talks/simply-about-not-simple-in-dbms-testing-on-the-example-of-postgresql/

Transcript

1. Просто о сложном в тестировании PostgreSQL Сергей Бронников
2. Представляюсь • 11 лет в тестировании ПО: • Parallels Desktop for Mac • Virtuozzo/OpenVZ • Tesseract OCR, OpenBSD • дериватив PostgreSQL 2
3. Представляюсь • Треть своей жизни я посвятил качеству ПО: • Parallels Desktop for Mac • Virtuozzo/OpenVZ • Tesseract OCR, OpenBSD • дериватив PostgreSQL 3
4. План • Немного о PostgreSQL и тестировании сообществом • Проблемы тестирования • Вопросы (и ответы) 4
5. Немного о PostgreSQL 5 • ОРСУБД, очень гибкая, надёжная и производительная • Платформа для разработки решений различной сложности и гибкости • Возраст кода 27 лет (!)
6. Немного о тестировании PostgreSQL 6 • Встроенный набор тестов 45 KLOC, 80% - SQL • Тестами покрыто 80% кода • В тестировании ~64 ОС, ~14 архитектур • Тесты запускаются автоматически с помощью BuildFarm
7. Что такое СУБД? 7 “Систе ́ ма управле ́ ния ба ́зами да ́нных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.” — Википедия
8. Откуда сложности? 8
9. Что хочет пользователь? 9 • Целостность • Производительность • Масшабируемость • Надёжность • Расширяемость • Портируемость
10. Что видит тестировщик 10 • Целостность = проверять тестовые данные • Производительность = бенчмарки • Масшабируемость = конкурентный доступ • Надёжность = стресс тестирование • Расширяемость = +100500 конфигураций • Портируемость = нюансы платформ
11. Целостность: тестовые данные • Проверка целостности: • Сохранение копии таблицы • Вычисление хэша таблицы 11
12. Целостность: проверяемость тестовых данных pg_dump/pg_restore: 12 --- heisenbug.dmp 2016-12-10 14:34:48.000000000 - 0400 +++ heisenbug.dev-dmp 2016-12-10 14:34:47. 000000000 -0400 @@ -1140,7 +1140,7 @@ -- CREATE TRIGGER last_updated - BEFORE UPDATE ON speaker + BEFORE UPDATE ON talk FOR EACH ROW EXECUTE PROCEDURE last_updated(); @@ -1160,7 +1160,7 @@ -- CREATE TRIGGER last_updated - BEFORE UPDATE ON speaker + BEFORE UPDATE ON talk FOR EACH ROW EXECUTE PROCEDURE last_updated(); ...
13. Целостность: проверяемость тестовых данных Вычисление хэша таблицы: $ q = "COPY (SELECT * FROM customers ORDER BY 1) TO STDOUT;" $ psql -c $q | openssl sha256 13
14. Производительность 14 • Тесты для атомарных операций • Моделирование нагрузки: DVD Store / TPC / DayTrader • “проигрывание” лог файлов
15. Производительность: выводы 15 • Делайте атомарные тесты для быстрого выявления деградаций • Используйте тесты, моделирующую реальную нагрузку • Используйте “проигрывание” логов
16. Надёжность 16 • Архитектура • Соответствие ACID • Лог упреждающей записи - WAL • Нюансы SQL: CLUSTER может испортить данные • Внесение неисправностей
17. Надёжность 17 “We have an employee whose last name is Null…”
18. Надёжность СУБД: внесение неисправностей • Файловая система • CharybdeFS • device-mapper • Память: failmalloc 18
19. Расширяемость 19 • Фуззер sqlsmith: • Стандартный синтаксис: 50+ ошибок • Расширения SQL синтаксиса • Клиенты бывают разными • API не фиксированное • Видовое разнообразие: типы данных, индексы
20. Расширяемость: тестовые данные • Когда лень или нет времени - pgbench -i -s 100 • Генерирование с помощью RANDOM(), GENERATE_SERIES() • “Долго, дорого, ох&енно” - datafiller 20
21. 21 Расширяемость: тестирование расширений • pg_pathman тесно интегрирован с PostgreSQL • Очень хотелось сделать юнит-тесты • Нереально сделать везде заглушки
22. 22 Расширяемость: тестирование расширений • Переделать архитектуру с учётом тестирования • Переписать код с учётом новой архитектуры
23. 23 Расширяемость: тестирование расширений • Написать юнит-тесты на cmocka • Тестировать “ядро” после каждого изменения
24. 24 Расширяемость: выводы • Учитесь “готовить” тестовые данные • В масштабных проектах нужно знать тонкости экосистемы • Проектируйте архитектуру с учётом тестирования
25. Портируемость: аппаратные архитектуры 25 • Для реального использования: x86, x86_64, ARM • Редкие: IA64, PowerPC, PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, MIPS, MIPSEL, M68K, PA- RISC и др.
26. Портируемость: нюансы 26 • Порядок байтов (big-endian, little-endian) • Разная скорость выполнения инструкций • Разные результаты математических функций • “Минус ноль”
27. Портируемость: оборудование 27 “Нахожу как минимум две серьёзные проблемы в год за счёт тестирования на разных архитектурах.” — Фёдор Сигаев, ведущий разработчик PostgreSQL
28. Портируемость: специфика ОС 28 • Поддерживаемые операционные системы: • Linux, Windows (> Win2000 SP4), FreeBSD, OpenBSD, NetBSD, Mac OS X, AIX, HP/UX, IRIX, Solaris, Tru64 Unix и UnixWare • ОС в рамках одного семейства тоже разные • Аллокатор памяти (malloc, jmalloc, openbsd-malloc и т.д.) • Функции для работы с Unicode (LibICU) • Файловые системы (https://criu.org/Filesystems_pecularities)
29. Портируемость: выводы 29 • Используйте больше хорошего и разного “железа” • Для упаковки ОС удобно использовать Packer • Использование IaaS может быть выгоднее
30. 30 Итоги: что вы узнали? • Проблемы в тестировании каждого требования PostgreSQL • Возможные пути решения проблем • Способы создания и верификации тестовых данных в СУБД
31. 31 Сергей Бронников Почта: sergeyb@postgrespro.ru Твиттер: @estet Вопросы?