как протестировать СУБД (sql и nosql) на архитектуре s390x (в основном мэйнфреймы IBM)
У меня есть доступ к машине s390x, точнее zbc12, с 32 ГБ ОЗУ, которую я могу использовать в качестве лаборатории в течение нескольких месяцев (!).
Я хотел изучить возможности этой архитектуры, особенно в отношении баз данных, и я хотел бы протестировать как sql, так и nosql. Сравнивая это с архитектурой x86, у меня также есть x86, и я могу подключить оба к одной и той же сети SAN, чтобы я мог правильно сравнить архитектуры. как бы вы, ребята, провели такой тест, у меня практически нет опыта в сравнительном тестировании. какие еще тесты вы хотели бы увидеть? Я уже несколько месяцев пользуюсь этой машиной и могу играть с ней столько, сколько захочу. Есть какие-нибудь крутые и интересные идеи?
1 ответ
Поздравляю с доступом к системе Z.
Для сравнения различных баз данных я могу дать лишь некоторые общие рекомендации. Вот некоторые моменты, которые следует учитывать при формулировании своего плана.
Атомарность — разделите свои базы данных на типы ACID и BASE, поскольку согласованность между ними различается, и учитывайте дополнительные соображения с точки зрения настройки, таких как сеть, диск и т. д.
Тестируемая система (SUT) должна быть четко определена с точки зрения количества и типов узлов. Как можно лучше задокументируйте базовую сеть и хранилище, чтобы люди могли сравнить вашу настройку с предполагаемым развертыванием. Какие переключатели вы используете? Вы настроены на Jumbo Frames? хранилище подключено напрямую или к SAN? Какова базовая сетевая инфраструктура для обоих (скорость и IOPS).
Конфигурация памяти должна быть хорошо документирована с точки зрения настройки БД. Убедитесь, что она согласована, или, если вы ее тестируете, задокументируйте ход настройки.
Если вы сравниваете ACID и BASE, какова цель согласованности и как вы обеспечиваете полную согласованность с точки зрения репликации/регистрации транзакций.
Рассмотрим целевую точку восстановления (RPO), которая означает, какой объем данных я готов потерять? а также целевое время восстановления (RTO), которое определяет, когда БД снова станет доступна в случае сбоя. Это повлияет на вашу конфигурацию и предположения.
Согласованный клиент для создания повторяемой нагрузки и обеспечения согласованности тестов. Вы масштабируете количество клиентов? Можете ли вы провести пост-валидацию, чтобы убедиться, что ожидаемый результат с точки зрения устойчивости достигнут?
При проведении любого теста следует учитывать ряд других факторов, но они послужат основой для дальнейшего развития.