Миллиардом за секунду тут и не пахнет..
Мы решили провести тесты работы rapeed на трёх недорогих серверах. Это даже не серверы, а мощные десктопы.
Машины такие (везде SSD-диски 1,92 Тбайт):
1) AMD Ryzen 9 7950X3D, 192 Гбайт памяти,
2) Intel Core i9-13900, 128 Гбайт памяти,
3) Intel Core i9-13900, 64 Гбайт памяти.
Забегая вперед - те, кто не верил в обработку миллиарда строк за секунду, оказались правы. Результаты оказались совсем не те, которые мы ожидали.
Конфигурация из 6 нод на этих 3х серверах оказалась быстрее, чем размещение этих же 6 нод на одном мощном сервере с двумя Xeon Gold и 1 Тбайт памяти. Если учитывать время первичной загрузки данных с диска, то расчеты стали быстрее на 17-22% в зависимости от плотности (отношения количества уникальных значений поля к количеству строк) поля и его размера. В среднем это время стало 5,6 сек, а было 7,1 сек.
Сами расчеты в памяти ускорились в десятки раз. На одном сервере расчеты составляли чуть больше 1 секунды, на 3х десктопах расчет сводной таблицы из миллиарда записей занимает 50-60 миллисекунд! В следующем видео я привел пример расчета сводной таблицы с нуля, где можно увидеть реальное время получения данных из ядра системы.
Да, rapeed не обрабатывает миллиард записей за секунду. Он обрабатывает миллиард записей за 0,05 секунды! И чем больше недорогих ресурсов ему доступно, тем быстрее он работает и тем бОльшие объемы данных обрабатывает.
#удовольствие_от_аналитики #тесты_rapeed
Мы решили провести тесты работы rapeed на трёх недорогих серверах. Это даже не серверы, а мощные десктопы.
Машины такие (везде SSD-диски 1,92 Тбайт):
1) AMD Ryzen 9 7950X3D, 192 Гбайт памяти,
2) Intel Core i9-13900, 128 Гбайт памяти,
3) Intel Core i9-13900, 64 Гбайт памяти.
Забегая вперед - те, кто не верил в обработку миллиарда строк за секунду, оказались правы. Результаты оказались совсем не те, которые мы ожидали.
Конфигурация из 6 нод на этих 3х серверах оказалась быстрее, чем размещение этих же 6 нод на одном мощном сервере с двумя Xeon Gold и 1 Тбайт памяти. Если учитывать время первичной загрузки данных с диска, то расчеты стали быстрее на 17-22% в зависимости от плотности (отношения количества уникальных значений поля к количеству строк) поля и его размера. В среднем это время стало 5,6 сек, а было 7,1 сек.
Сами расчеты в памяти ускорились в десятки раз. На одном сервере расчеты составляли чуть больше 1 секунды, на 3х десктопах расчет сводной таблицы из миллиарда записей занимает 50-60 миллисекунд! В следующем видео я привел пример расчета сводной таблицы с нуля, где можно увидеть реальное время получения данных из ядра системы.
Да, rapeed не обрабатывает миллиард записей за секунду. Он обрабатывает миллиард записей за 0,05 секунды! И чем больше недорогих ресурсов ему доступно, тем быстрее он работает и тем бОльшие объемы данных обрабатывает.
#удовольствие_от_аналитики #тесты_rapeed
👍15🔥5👏2✍1
Достаточно 12 Гбайт
Что будет, если увеличить число нод в 2 раза на тех же серверах? Мы решили попробовать и сравнить скорость работы системы. Каждой ноде выделили по 12 Гбайт оперативной памяти. Всего получилось 12 нод, по 4 ноды на сервер, и 144 Гбайт распределенной памяти на источник размером в 1 млрд записей.
Как видно на следующем видео, скорость работы системы осталась такой же, как в случае с 2 нодами на сервер - каждый расчет занимает 30-55 миллисекунд. Специально для тех, кто еще сомневается в том, что это настоящая скорость работы rapeed, в видео я создаю новый показатель, считающий число уникальных объектов (count distinct), и работаю с ним в сводной таблице.
Живая скорость работы системы - в видео.
#удовольствие_от_аналитики #тесты_rapeed
Что будет, если увеличить число нод в 2 раза на тех же серверах? Мы решили попробовать и сравнить скорость работы системы. Каждой ноде выделили по 12 Гбайт оперативной памяти. Всего получилось 12 нод, по 4 ноды на сервер, и 144 Гбайт распределенной памяти на источник размером в 1 млрд записей.
Как видно на следующем видео, скорость работы системы осталась такой же, как в случае с 2 нодами на сервер - каждый расчет занимает 30-55 миллисекунд. Специально для тех, кто еще сомневается в том, что это настоящая скорость работы rapeed, в видео я создаю новый показатель, считающий число уникальных объектов (count distinct), и работаю с ним в сводной таблице.
Живая скорость работы системы - в видео.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥3
Незыблемые законы тестирования и правило из Рататуя
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix, Oracle DB и Essbase, MS SQL Server и MS OLAP, Tableau, SiSence, другие аналитические продукты, не говоря уже о продуктах моей разработки. Например, мы проходили аудированные тесты производительности Полиматики в Швейцарии с привлечением американцев. После этого еще доводилось промышленные системы (MES) пощупать на предмет наработки на отказ.
И везде, всегда, в 100% случаев при нагрузочном тестировании соблюдаются следующие 2 закона (их может быть и больше, но эти два - точно и всегда):
1. При увеличении объема данных время их обработки растёт.
2. При увеличении количества пользователей задержка в ответе (N+100)-му пользователю увеличивается по сравнению с первым, вторым, … N-ным пользователем.
По какому закону растут 1. и 2. - линейно, квадратично, логарифмически… - зависит от конкретной системы, но они растут всегда.
Но: «Одно нужно знать наверняка - ничего нельзя знать наверняка», как говорится в любимом мультфильме моих детей «Рататуй».
С высоты всего моего опыта мне приходится признать, что есть одна система, которая плевать хотела на эти законы.
Сначала был повержен первый закон. Выше я приводил результаты тестов, где видно, что при росте объема данных время обработки в rapeed не растет - как было меньше секунды, так и осталось. Для системы, похоже, чем распределённее инсталляция, тем она быстрее работает.
При этом многие клиенты интересуются, как rapeed справляется с большим количеством пользователей на один сервер. Может, это он только для одного пользователя так? А для сотен одновременно работающих пользователей будут критические задержки?
Мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Были взяты те же серверы и источник «Чеки» размером 365 млн записей. Вопрос, на который должен был ответить тест, такой: как изменяется время отклика платформы для 301-го пользователя в сравнении с откликом для 1-го пользователя?
Ответ: никак не меняется.
Я уже свыкся с этим фактом после восьмого запуска и того, что я «переспал» с результатами. В следующем посте я подробно опишу сценарий теста, выложу аналитику и графики и - для желающих - сводный файл результатов.
#удовольствие_от_аналитики #тесты_rapeed
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix, Oracle DB и Essbase, MS SQL Server и MS OLAP, Tableau, SiSence, другие аналитические продукты, не говоря уже о продуктах моей разработки. Например, мы проходили аудированные тесты производительности Полиматики в Швейцарии с привлечением американцев. После этого еще доводилось промышленные системы (MES) пощупать на предмет наработки на отказ.
И везде, всегда, в 100% случаев при нагрузочном тестировании соблюдаются следующие 2 закона (их может быть и больше, но эти два - точно и всегда):
1. При увеличении объема данных время их обработки растёт.
2. При увеличении количества пользователей задержка в ответе (N+100)-му пользователю увеличивается по сравнению с первым, вторым, … N-ным пользователем.
По какому закону растут 1. и 2. - линейно, квадратично, логарифмически… - зависит от конкретной системы, но они растут всегда.
Но: «Одно нужно знать наверняка - ничего нельзя знать наверняка», как говорится в любимом мультфильме моих детей «Рататуй».
С высоты всего моего опыта мне приходится признать, что есть одна система, которая плевать хотела на эти законы.
Сначала был повержен первый закон. Выше я приводил результаты тестов, где видно, что при росте объема данных время обработки в rapeed не растет - как было меньше секунды, так и осталось. Для системы, похоже, чем распределённее инсталляция, тем она быстрее работает.
При этом многие клиенты интересуются, как rapeed справляется с большим количеством пользователей на один сервер. Может, это он только для одного пользователя так? А для сотен одновременно работающих пользователей будут критические задержки?
Мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Были взяты те же серверы и источник «Чеки» размером 365 млн записей. Вопрос, на который должен был ответить тест, такой: как изменяется время отклика платформы для 301-го пользователя в сравнении с откликом для 1-го пользователя?
Ответ: никак не меняется.
Я уже свыкся с этим фактом после восьмого запуска и того, что я «переспал» с результатами. В следующем посте я подробно опишу сценарий теста, выложу аналитику и графики и - для желающих - сводный файл результатов.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥2👏2
Тесты производительности rapeed на 300 пользователях
Как говорилось выше, мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Был взят распределенный контур из 3х серверов и источник «Чеки» размером 365 440 448 записей.
Для каждого из 300 пользователей выполнялись следующие действия:
0. Авторизация (в результаты не вошла)
1. Создание таблицы из одной колонки: слева поле name_group_level3, показатель Сумма (quantity). Без сортировки.
2. Открытие состава поля (get_elements) по полю name_group_level2
3. Создание таблицы с левым полем name_group_level3, верхним полем name_group_level2 с сортировкой по показателю по убыванию для каждого столбца (перебор столбцов для сортировки распределен случайным образом между пользователями)
4. Открытие состава поля (get_elements) по полю short_name - код магазина
5. Создание таблицы с левым полем short_name, вторым (вложенным) левым полем name_wares (название товара) с раскрытием по первому элементу поля short_name, фильтр по price_segment = Премиум, с сортировкой по показателю по убыванию
6. Открытие состава поля (get_elements) по полю short_name и по полю name_group_level2
7. Создание таблицы с верхним полем name_group_level2, левым полем short_name, вторым левым полем name_wares с последовательным раскрытием по первому элементу поля short_name для каждого столбца, фильтр по price_segment = Эконом, с сортировкой по показателю по убыванию для каждого столбца.
Пользователи перебираются последовательно. По какому столбцу делается сортировка в п.3, раскрытие в п.5 и раскрытие и сортировка в п.7, определяется случайно и равномерно распределяется между пользователями.
Последовательность тестов повторяется после небольшой паузы. Итого сделано 4200 запросов от пользователей (300 пользователей * 7 действий * 2 повтора) и получено 4200 ответов. Ошибочных ответов нет.
Параллельно снималась нагрузка на сервера - использование совокупного CPU в %, объем памяти и обмен по сети.
Ниже выложен сводный файл запросов и ответов в формате XLSX, а также график распределения времени отклика от количества запросов в секунду, график среднего времени отклика по пользователям и динамика среднего времени отклика по времени.
Всё время теста занимает 1 минуту. То есть распределенный кластер из трёх десктопов обработал 4200 аналитических запросов в минуту без ошибок со средним временем отклика 0,3 секунды.
Повторю вывод: время отклика системы на запрос пользователя при многопользовательской работе остается стабильным и не меняется.
#удовольствие_от_аналитики #тесты_rapeed
Как говорилось выше, мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Был взят распределенный контур из 3х серверов и источник «Чеки» размером 365 440 448 записей.
Для каждого из 300 пользователей выполнялись следующие действия:
0. Авторизация (в результаты не вошла)
1. Создание таблицы из одной колонки: слева поле name_group_level3, показатель Сумма (quantity). Без сортировки.
2. Открытие состава поля (get_elements) по полю name_group_level2
3. Создание таблицы с левым полем name_group_level3, верхним полем name_group_level2 с сортировкой по показателю по убыванию для каждого столбца (перебор столбцов для сортировки распределен случайным образом между пользователями)
4. Открытие состава поля (get_elements) по полю short_name - код магазина
5. Создание таблицы с левым полем short_name, вторым (вложенным) левым полем name_wares (название товара) с раскрытием по первому элементу поля short_name, фильтр по price_segment = Премиум, с сортировкой по показателю по убыванию
6. Открытие состава поля (get_elements) по полю short_name и по полю name_group_level2
7. Создание таблицы с верхним полем name_group_level2, левым полем short_name, вторым левым полем name_wares с последовательным раскрытием по первому элементу поля short_name для каждого столбца, фильтр по price_segment = Эконом, с сортировкой по показателю по убыванию для каждого столбца.
Пользователи перебираются последовательно. По какому столбцу делается сортировка в п.3, раскрытие в п.5 и раскрытие и сортировка в п.7, определяется случайно и равномерно распределяется между пользователями.
Последовательность тестов повторяется после небольшой паузы. Итого сделано 4200 запросов от пользователей (300 пользователей * 7 действий * 2 повтора) и получено 4200 ответов. Ошибочных ответов нет.
Параллельно снималась нагрузка на сервера - использование совокупного CPU в %, объем памяти и обмен по сети.
Ниже выложен сводный файл запросов и ответов в формате XLSX, а также график распределения времени отклика от количества запросов в секунду, график среднего времени отклика по пользователям и динамика среднего времени отклика по времени.
Всё время теста занимает 1 минуту. То есть распределенный кластер из трёх десктопов обработал 4200 аналитических запросов в минуту без ошибок со средним временем отклика 0,3 секунды.
Повторю вывод: время отклика системы на запрос пользователя при многопользовательской работе остается стабильным и не меняется.
#удовольствие_от_аналитики #тесты_rapeed
👍6🔥3👏2
Аналитическая платформа Rapeed - в реестре российского ПО Минцифры
Вот это подарок так подарок для нас для всех! С Новым годом!!
Подробности >>
#удовольствие_от_аналитики
Вот это подарок так подарок для нас для всех! С Новым годом!!
Подробности >>
#удовольствие_от_аналитики
👍17🔥8👏5
algoritm.mp4
27.6 MB
Вот раньше..)
С Романом Дидычем (Optimacros) и Алексеем Арустамовым (Loginom) обсуждаем нейросети и качество данных.
С Романом Дидычем (Optimacros) и Алексеем Арустамовым (Loginom) обсуждаем нейросети и качество данных.
👍14🔥7❤1❤🔥1👏1😁1
Разработка продукта
Разработка любого коммерческого продукта, и прежде всего Enterprise-продукта - это конусовидная спираль. Чем больше делаешь, тем больше делать на следующем шаге. И периодически возвращаешься почти туда же, откуда начинал.
#удовольствие_от_аналитики
Разработка любого коммерческого продукта, и прежде всего Enterprise-продукта - это конусовидная спираль. Чем больше делаешь, тем больше делать на следующем шаге. И периодически возвращаешься почти туда же, откуда начинал.
#удовольствие_от_аналитики
1👍6💯5🔥4
Привет вновь присоединившимся подписчикам!
Чтобы вы не листали до начала канала, вот ссылка на первую публикацию)
А здесь скоро будет информация о тестах на 40 000 пользователей, работающих на одном контуре системы с двумя источниками по 4 млрд записей каждый. Продолжаем!
#удовольствие_от_аналитики
Чтобы вы не листали до начала канала, вот ссылка на первую публикацию)
А здесь скоро будет информация о тестах на 40 000 пользователей, работающих на одном контуре системы с двумя источниками по 4 млрд записей каждый. Продолжаем!
#удовольствие_от_аналитики
🔥16👍5🥴2
40 000 «трёхруких» пользователей на 3 источниках по 4 млрд записей - нагрузочные тесты rapeed
В декабре мы проводили тесты производительности системы на 300 пользователях на наших серверах. На самом деле мы готовились к гораздо более масштабным нагрузочным тестам, которыми мы занимались после этого вместе с крупным государственным заказчиком (спасибо вам огромное, коллеги!). И вот, наконец, мы их сделали!
Задачей тестов было промоделировать поведение целого города аналитиков из 40 000 пользователей, которые одновременно работают с rapeed, решая аналитические задачи - создать сводную таблицу различных конфигураций, раскрыть её, отсортировать, отфильтровать, построить другую таблицу на другом источнике, сделать подобные действия с ней, затем СВЯЗАТЬ эти источники по нескольким полям на лету, затем построить на этих связанных источниках сводную таблицу и опять её сортировать и фильтровать.
В ходе создания скрипта для тестов мы решили сделать пользователей трёхрукими, держащими по три мышки сразу, создавая одновременно три разных таблицы и делая в них разные операции. В жизни, конечно, люди работают медленно и делают паузы между действиями - но при таких паузах каждый тест длился бы по двое суток! Поэтому запросы на построение таблиц от каждого пользователя высылались пакетом. Более того, для моделирования одновременной нагрузки на систему мы объединяли по 333 и 500 пользователей в блоки.
Логика сценария выглядела так: от каждого пользователя в блоке генерировались запросы на создание, фильтрацию, раскрытие и сортировку трёх таблиц. При этом узлы, по которым происходило раскрытие и фильтрация, менялись от пользователя к пользователю перебором значений. Максимальное число одновременно посылаемых запросов к системе доходило до 30 000 (тридцати тысяч).
После отправки всех запросов собирались ответы системы для текущего блока пользователей - и запускался новый блок трёхруких аналитиков-пулемётов).
Пользователи работали на двух источниках данных по 4 млрд записей в каждом. У источников некоторые поля совпадали (одно из них Дата) - их связывали для получения показателя, рассчитываемого по двум источникам.
Такой сценарий выбрали, чтобы с лихвой перекрыть все возможные ситуации с одновременной работой пользователей и исследовать работу системы на больших источниках данных при интенсивной аналитической нагрузке. Нам также было интересно понять, какое влияние оказывает связывание полей на скорость расчетов.
Отдельным бонусом шла задача исследовать поведение системы при работе с источником, содержащим около 50 длинных текстовых полей - влияют ли длинные поля на производительность.
Каждая команда от каждого пользователя фиксировалась в логе (время, тип, другие параметры, в том числе уникальный номер Trace_Id), также собирались ответы системы (время обработки и Trace_Id).
По результатам тестов не было зафиксировано ни одного ошибочного ответа - система в 100% случаях отработала корректно и дала верные результаты расчетов.
Для запусков тестов коллеги выделили 25 виртуальных серверов, каждый с процессором Intel Xeon Gold 5220R CPU @ 2.20GHz, память 64 Гбайт, SSD 62 Гбайт. Общая распределенная память контура системы – 1 600 Гбайт. Плановая скорость сети - 100 Мбит/с. В ходе тестов фиксировались: загрузка CPU, использование памяти и сетевой трафик в среднем на контур и на каждой ноде.
Не знаю, проводил ли кто-то до этого в России нагрузочные тесты аналитической платформы в такой конфигурации. В некоторые моменты это напоминало DDOS-атаку аналитическими запросами! Мы получили крайне интересные результаты, о которых - в следующих постах.
#удовольствие_от_аналитики #тесты_rapeed
В декабре мы проводили тесты производительности системы на 300 пользователях на наших серверах. На самом деле мы готовились к гораздо более масштабным нагрузочным тестам, которыми мы занимались после этого вместе с крупным государственным заказчиком (спасибо вам огромное, коллеги!). И вот, наконец, мы их сделали!
Задачей тестов было промоделировать поведение целого города аналитиков из 40 000 пользователей, которые одновременно работают с rapeed, решая аналитические задачи - создать сводную таблицу различных конфигураций, раскрыть её, отсортировать, отфильтровать, построить другую таблицу на другом источнике, сделать подобные действия с ней, затем СВЯЗАТЬ эти источники по нескольким полям на лету, затем построить на этих связанных источниках сводную таблицу и опять её сортировать и фильтровать.
В ходе создания скрипта для тестов мы решили сделать пользователей трёхрукими, держащими по три мышки сразу, создавая одновременно три разных таблицы и делая в них разные операции. В жизни, конечно, люди работают медленно и делают паузы между действиями - но при таких паузах каждый тест длился бы по двое суток! Поэтому запросы на построение таблиц от каждого пользователя высылались пакетом. Более того, для моделирования одновременной нагрузки на систему мы объединяли по 333 и 500 пользователей в блоки.
Логика сценария выглядела так: от каждого пользователя в блоке генерировались запросы на создание, фильтрацию, раскрытие и сортировку трёх таблиц. При этом узлы, по которым происходило раскрытие и фильтрация, менялись от пользователя к пользователю перебором значений. Максимальное число одновременно посылаемых запросов к системе доходило до 30 000 (тридцати тысяч).
После отправки всех запросов собирались ответы системы для текущего блока пользователей - и запускался новый блок трёхруких аналитиков-пулемётов).
Пользователи работали на двух источниках данных по 4 млрд записей в каждом. У источников некоторые поля совпадали (одно из них Дата) - их связывали для получения показателя, рассчитываемого по двум источникам.
Такой сценарий выбрали, чтобы с лихвой перекрыть все возможные ситуации с одновременной работой пользователей и исследовать работу системы на больших источниках данных при интенсивной аналитической нагрузке. Нам также было интересно понять, какое влияние оказывает связывание полей на скорость расчетов.
Отдельным бонусом шла задача исследовать поведение системы при работе с источником, содержащим около 50 длинных текстовых полей - влияют ли длинные поля на производительность.
Каждая команда от каждого пользователя фиксировалась в логе (время, тип, другие параметры, в том числе уникальный номер Trace_Id), также собирались ответы системы (время обработки и Trace_Id).
По результатам тестов не было зафиксировано ни одного ошибочного ответа - система в 100% случаях отработала корректно и дала верные результаты расчетов.
Для запусков тестов коллеги выделили 25 виртуальных серверов, каждый с процессором Intel Xeon Gold 5220R CPU @ 2.20GHz, память 64 Гбайт, SSD 62 Гбайт. Общая распределенная память контура системы – 1 600 Гбайт. Плановая скорость сети - 100 Мбит/с. В ходе тестов фиксировались: загрузка CPU, использование памяти и сетевой трафик в среднем на контур и на каждой ноде.
Не знаю, проводил ли кто-то до этого в России нагрузочные тесты аналитической платформы в такой конфигурации. В некоторые моменты это напоминало DDOS-атаку аналитическими запросами! Мы получили крайне интересные результаты, о которых - в следующих постах.
#удовольствие_от_аналитики #тесты_rapeed
Telegram
rapeed
Незыблемые законы тестирования и правило из Рататуя
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix…
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix…
🔥16👍5✍2
Результаты тестов. Скорость импорта и почему она такая
Начнем с импорта. Внизу в системном ответе видно, что источники, в которых по 5 полей и по 4 млрд записей, импортируются примерно за 6 часов:
ССЧ Большой = 6 часов 10 минут
Начислено большой = 5 часов 59 минут
⁃ и скорость импорта для них составляет 11,1 млн записей в минуту или 0,68 млрд записей/час.
Источник из 26 длинных текстовых полей (с кодовым названием «широкий») и 500 млн записей закачался за 5 часов 7 минут, и для него скорость составила 1,6 млн записей в минуту.
Для сравнения источников надо сказать, что в базе PostgreSQL, из которой производился импорт, этот «широкий» источник занимал больше места, чем «большие», и для дальнейшего его увеличения просто не было места на диске.
_________________
Импорт в rapeed можно представить как распределительный пылесос. Одним широким входным концом трубы импорт постоянно засасывает у источника данные блоками по 10 000 записей, а множеством отдающих труб отдает эти блоки нодам по кругу. Из-за такой параллельно-распределенной архитектуры скорость импорта максимально приближена к скорости драйвера СУБД-источника или, в случае файлового источника, к скорости чтения файлов с диска с учетом ограничений со стороны сети. Естественно, что пересылать потрубе сети блоки записей из пяти полей средней длины гораздо быстрее, чем из 26 длинных полей.
На нашем контуре импорт аналогичных пяти полей из MS SQL идет со скоростью 21,4 млн записей в минуту или 1,28 млрд записей/час - почти в два раза быстрее:
_________________
Импорт в rapeed - инкрементный. В случае больших источников данных первичная загрузка накопленных объемов может занимать существенное время. Зато объем ежедневных обновлений уже не будет таким большим.
Далее разберем среднее время отклика системы в тестах.
#удовольствие_от_аналитики #тесты_rapeed
Начнем с импорта. Внизу в системном ответе видно, что источники, в которых по 5 полей и по 4 млрд записей, импортируются примерно за 6 часов:
ССЧ Большой = 6 часов 10 минут
Начислено большой = 5 часов 59 минут
⁃ и скорость импорта для них составляет 11,1 млн записей в минуту или 0,68 млрд записей/час.
Источник из 26 длинных текстовых полей (с кодовым названием «широкий») и 500 млн записей закачался за 5 часов 7 минут, и для него скорость составила 1,6 млн записей в минуту.
Для сравнения источников надо сказать, что в базе PostgreSQL, из которой производился импорт, этот «широкий» источник занимал больше места, чем «большие», и для дальнейшего его увеличения просто не было места на диске.
_________________
"data_sources": [
{
"id": "МСП синтетические",
"name": "МСП синтетические",
"state": "VALID",
"type": "PGSQL",
"rows_count": "500000000",
"created": "2025-02-27 19:06:45",
"updated": "2025-02-28 00:14:04",
…
},
{
"id": "ССЧ Большой",
"name": "ССЧ Большой",
"state": "VALID",
"type": "PGSQL",
"rows_count": "4000000512",
"created": "2025-02-03 10:07:36",
"updated": "2025-02-03 16:17:37",
…
},
{
"id": "Начислено Большой",
"name": "Начислено Большой",
"state": "VALID",
"type": "PGSQL",
"rows_count": "4000001024",
"created": "2025-02-03 21:33:03",
"updated": "2025-02-04 03:32:45",
…
}
_____________________Импорт в rapeed можно представить как распределительный пылесос. Одним широким входным концом трубы импорт постоянно засасывает у источника данные блоками по 10 000 записей, а множеством отдающих труб отдает эти блоки нодам по кругу. Из-за такой параллельно-распределенной архитектуры скорость импорта максимально приближена к скорости драйвера СУБД-источника или, в случае файлового источника, к скорости чтения файлов с диска с учетом ограничений со стороны сети. Естественно, что пересылать по
На нашем контуре импорт аналогичных пяти полей из MS SQL идет со скоростью 21,4 млн записей в минуту или 1,28 млрд записей/час - почти в два раза быстрее:
_________________
{
"id": "Пример чеков",
"name": "Пример чеков",
"state": "VALID",
"type": "MSSQL",
"rows_count": "365440448",
"created": "2025-03-08 18:38:07",
"updated": "2025-03-08 18:55:01",
…
}
_____________________Импорт в rapeed - инкрементный. В случае больших источников данных первичная загрузка накопленных объемов может занимать существенное время. Зато объем ежедневных обновлений уже не будет таким большим.
Далее разберем среднее время отклика системы в тестах.
#удовольствие_от_аналитики #тесты_rapeed
👍7👏3
Результаты тестов.
Среднее время отклика системы
За всё время тестов система выполнила более 2,5 миллионов запросов get_table во «взрывном» режиме. Запросы были к разным источникам (в том числе к связанным по двум полям), на разные действия и разной сути: таблицы разной конфигурации с нуля построить, раскрыть их, отфильтровать и отсортировать. Завершённый отклик системы - это JSON с данными таблицы, пришедший в интерфейс. Измерялось время посылки запроса (при этом формировался уникальный Trace_Id) и время получения JSON c этим Trace_Id.
Среднее время отклика в этих условиях будет скорее качественным показателем.
На массиве данных всех тестов среднее время отклика системы составило 1,3 секунды. Напомню, каждый запрос - это сводная таблица на одном или двух источниках по 4 млрд записей в условиях обработки до 30 000 одновременных запросов. Это примерно как классическая сервировка стола в условиях расстрела взводом автоматчиков)
Если посмотреть динамику среднего времени оклика по источникам (1й, 2й и составной), то она выглядит так (масштаб осей разный!):
#удовольствие_от_аналитики #тесты_rapeed
Среднее время отклика системы
За всё время тестов система выполнила более 2,5 миллионов запросов get_table во «взрывном» режиме. Запросы были к разным источникам (в том числе к связанным по двум полям), на разные действия и разной сути: таблицы разной конфигурации с нуля построить, раскрыть их, отфильтровать и отсортировать. Завершённый отклик системы - это JSON с данными таблицы, пришедший в интерфейс. Измерялось время посылки запроса (при этом формировался уникальный Trace_Id) и время получения JSON c этим Trace_Id.
Среднее время отклика в этих условиях будет скорее качественным показателем.
На массиве данных всех тестов среднее время отклика системы составило 1,3 секунды. Напомню, каждый запрос - это сводная таблица на одном или двух источниках по 4 млрд записей в условиях обработки до 30 000 одновременных запросов. Это примерно как классическая сервировка стола в условиях расстрела взводом автоматчиков)
Если посмотреть динамику среднего времени оклика по источникам (1й, 2й и составной), то она выглядит так (масштаб осей разный!):
#удовольствие_от_аналитики #тесты_rapeed
👍6🔥2
Из этих графиков можно сделать два неожиданных вывода:
1. Получается, что при блоке из 500 пользователей время отклика меньше, чем на блоке из 333 (!!!)
2. Время отклика на составном источнике с двумя связанными полями меньше, чем сумма времён обработки двух исходных источников.
О втором факте мы знали и раньше, но первый факт неожиданный и пока объяснению не поддаётся.
Интересно проанализировать время отклика на каждом источнике в разрезе операций. На графиках распределения среднего времени отклика по количеству запросов в секунду каждая операция выделена своим цветом. При этом можно видеть, какое максимальное количество запросов в секунду выполнял контур и какое среднее время отклика у них было - 107 запросов в секунду при среднем времени 0.78 сек на запрос при блоке 333 пользователях и 100 запросов в секунду при 1.38 сек при блоке в 500 пользователей:
#удовольствие_от_аналитики #тесты_rapeed
1. Получается, что при блоке из 500 пользователей время отклика меньше, чем на блоке из 333 (!!!)
2. Время отклика на составном источнике с двумя связанными полями меньше, чем сумма времён обработки двух исходных источников.
О втором факте мы знали и раньше, но первый факт неожиданный и пока объяснению не поддаётся.
Интересно проанализировать время отклика на каждом источнике в разрезе операций. На графиках распределения среднего времени отклика по количеству запросов в секунду каждая операция выделена своим цветом. При этом можно видеть, какое максимальное количество запросов в секунду выполнял контур и какое среднее время отклика у них было - 107 запросов в секунду при среднем времени 0.78 сек на запрос при блоке 333 пользователях и 100 запросов в секунду при 1.38 сек при блоке в 500 пользователей:
#удовольствие_от_аналитики #тесты_rapeed
👍4