Модель данных

Доброго времени суток.

Пытаюсь применить elasticsearch для анализа логов тестирования, но не могу определиться с моделью данных(маппингом). Проблема в том что тесты имеют иерархическую структуру, на верхнем уровне находятся, например 10 тестов, каждый из которых состоит из нескольких шагов, которые, в свою очередь, тоже могут состоять из нескольких шагов и т.д., т.е. вложенность может быть "в глубину" на 10 и у каждого шага свой результат(PASS/FAIL). Если внутренний шаг имеет статут FAIL это еще не означает, что все шаги выше него тоже будут FAIL.
Все это необходимо для построения запросов следующего типа:
взяв тест со статусом FAIL получить внутренний шаг который не прошел и наоборот, взяв определенный шаг(его имя) посмотреть его историю(в составе какого теста/шага он проходил/не проходил). Так же если какой-то шаг упал, сохраняется сообщение с ошибкой и по части этого сообщения хотелось бы получить упавший тест/шаг.
Корректно ли записывать в elastic результат теста как обьект со всей вложенной структурой?
Или лучше записывать много мелких объектов, например результаты каждого шага записывать как отдельный документ в котором содержится информация связывающая его с породившими его шагами и тестом (в данном случае будем много дублирующей информации).

Может я совсем не правильно понимаю концепцию, но что-то застрял и мыли закончились.
Буду благодарен за любые подсказки.

А какой размер ожидается у этого индекса? Сколько будет этих тестов самого верхнего уровня и какой размер будет у все дерева для этого теста?

В идеале хочется хранить все данные тестов, а это ежедневно 11 дженкинс джоб, в каждой от 10 до 56 тестов, каждый из которых, как я и писал, состоит из многих шагов(от 1-го до 10-ти).
Сами лог файлы ежедневно занимают порядка 400мб и это около 1млн строк, но не вся информация нужна, думаю, половина точно отсечется.

И сколько дней это все будет храниться?

Об этом еще не думал, но могу с уверенностью сказать, что 30ти дней будет вполне достаточно.

Я бы попробовал и так и так и посмотрел, что получиться. У вас маленький объем данных, так что можно в любой момент все данные переиндексировать. Я думаю, что главный вопрос здесь не в том, как вы будете искать - поиск будет работать и в том и в другом случае примерно одинаково. Но вот если вы начнете агрегировать результаты, то могут начаться проблемы.

А у вас глубина имеет какое-то конкретное значение? То есть все тесты на 1-м уровне это проэкты, на 2-м группы, на 3-м классы, на 4-м методы и т.д.?

1 Like

По поводу тестов, конкретное количество уровней не назову. Для тестирования используется robot framework, запускается тестовый сценарий состоящий из списка тестов, тесты состоят из кейвордов, кейворды тоже из кейвордов и тд. Для отдельно взятого теста, можно определить структуру вложенности, но для всех выделить общую - нет.

Спасибо за совет, буду дальше изучать документацию и попробую для начала вариант с дублированием информации, мне он кажется проще, нежели вложенная структура, особенно с точки зрения построения запросов.
Очень вам благодарен!

Я спросил про уровни потому, что каждый уровень будет представлен в схеме. Если уровни что-то означают, то их можно было бы назвать соответсвенно, и это упростило-бы написание вложенных запросов.

Интересно, с этой стороны я не думал. Попробую реализовать и с данной стороны - конкретизировать кол-во уровней. Как правило в основном "глубина" 3-4.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.