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
При сравнении быстродействия в разрезе операций хорошо бы учитывать не только среднее время, но и минимальное с максимальным для оценки разброса значений.
Ниже привожу пример такого анализа. Для него хорошо подойдет область связей - в таблице нужно раскрывать каждый узел, а здесь есть полный список операций со всеми показателями, связанных с источниками:
#удовольствие_от_аналитики #тесты_rapeed
Ниже привожу пример такого анализа. Для него хорошо подойдет область связей - в таблице нужно раскрывать каждый узел, а здесь есть полный список операций со всеми показателями, связанных с источниками:
#удовольствие_от_аналитики #тесты_rapeed
👍4
Дальше узнаем, какая была нагрузка на вычислительные мощности и что вообще происходит при расчетах в rapeed
#удовольствие_от_аналитики #тесты_rapeed
#удовольствие_от_аналитики #тесты_rapeed
👍4
Результаты тестов.
Нагрузка на вычислительные мощности
Параллельно с логами в тестах фиксировалась нагрузка на CPU, память и сеть. Потом оценку нагрузки на сеть выключили, поскольку она была крайне низка.
На скриншоте внизу видно, что нагрузка на CPU небольшая: в момент скриншота средняя нагрузка на процессоры контура составляет 6,4%. Система зарезервировала весь процессор под себя (синий фон), но понадобилось только 6,4%. За всё время вычислений загрузка CPU не превышала 15%.
В левой части скриншота виден блок высокой нагрузки - это была авторизация 40 000 пользователей. Поскольку авторизация связана с криптографией и выдачей токенов, то это «дорогая» с точки зрения потребления CPU операция. Поскольку в жизни одновременных авторизаций десятков тысяч пользователей не бывает, то эта информация непосредственно к работе системы не относится.
Потребление памяти стабильно, практически без флуктуаций. Как данные попали в распределенную память нод, так они там и живут. Сессии и задания пользователей памяти дополнительно практически не потребляют.
#удовольствие_от_аналитики #тесты_rapeed
Нагрузка на вычислительные мощности
Параллельно с логами в тестах фиксировалась нагрузка на CPU, память и сеть. Потом оценку нагрузки на сеть выключили, поскольку она была крайне низка.
На скриншоте внизу видно, что нагрузка на CPU небольшая: в момент скриншота средняя нагрузка на процессоры контура составляет 6,4%. Система зарезервировала весь процессор под себя (синий фон), но понадобилось только 6,4%. За всё время вычислений загрузка CPU не превышала 15%.
В левой части скриншота виден блок высокой нагрузки - это была авторизация 40 000 пользователей. Поскольку авторизация связана с криптографией и выдачей токенов, то это «дорогая» с точки зрения потребления CPU операция. Поскольку в жизни одновременных авторизаций десятков тысяч пользователей не бывает, то эта информация непосредственно к работе системы не относится.
Потребление памяти стабильно, практически без флуктуаций. Как данные попали в распределенную память нод, так они там и живут. Сессии и задания пользователей памяти дополнительно практически не потребляют.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥3
Результаты тестов. Интерпретация и выводы
Тесты безусловно достигли своей цели, полностью доказав, что rapeed на одном контуре (то есть с одной точкой входа для пользователей, или иначе с одним master-ом) способен обслуживать 40 000 пользователей, работающих во «взрывном» режиме с большими источниками данных, причем с большим практическим запасом, сохраняя при этом время отклика менее 2 секунд.
Вторая цель тестов была - оценить, как связывание источников на лету влияет на скорость обработки запросов. Здесь тоже есть результат - технология связанных полей оправдала ожидания.
То, что размер источников - 4 млрд записей, объясняется спецификой задачи и дефицитом места. Если источники будут по 40 млрд, 400 млрд или любого другого размера, нужно будет рассчитать потребность в «железе», импортировать данные - и система будет работать.
Что происходит при расчетах и от чего зависит время отклика? В наших внутренних тестах оно составляло 0,1 сек на 400 млн записей, да и в этих нагрузочных тестах значительная доля откликов выполнялась за доли секунды.
Расчетные операции в rapeed состоят из следующих этапов:
- первичное распределенное чтение данных с диска;
- расчеты внутри нод;
- сетевой обмен внутри распределенной памяти нод;
- расчеты внутри распределенной памяти;
- формирование ответа в формате JSON;
- пересылка ответа потребителю в формате JSON.
Бывают ответы такого большого размера (хоть у нас в ядре и пагинация, то есть задается, сколько первых N элементов нужно), что только их пересылка по сети займет полсекунды - например, раскрытие длинного текстового поля, когда сверху в таблице тоже текстовые поля.
Система адаптируется к пересылкам расчетов определенных конфигураций, и повторно высылает их быстрее. Когда конфликтующих запросов много, на разных уровнях возникают очереди их обработки, и тогда скорость их обработки зависит от десятков практически случайных факторов типа состояния каналов памяти.
Одно можно сказать определенно: архитектура системы была разработана именно под такую нагрузку и под такие задачи и успешно справилась со стресс-тестами.
#удовольствие_от_аналитики #тесты_rapeed
Тесты безусловно достигли своей цели, полностью доказав, что rapeed на одном контуре (то есть с одной точкой входа для пользователей, или иначе с одним master-ом) способен обслуживать 40 000 пользователей, работающих во «взрывном» режиме с большими источниками данных, причем с большим практическим запасом, сохраняя при этом время отклика менее 2 секунд.
Вторая цель тестов была - оценить, как связывание источников на лету влияет на скорость обработки запросов. Здесь тоже есть результат - технология связанных полей оправдала ожидания.
То, что размер источников - 4 млрд записей, объясняется спецификой задачи и дефицитом места. Если источники будут по 40 млрд, 400 млрд или любого другого размера, нужно будет рассчитать потребность в «железе», импортировать данные - и система будет работать.
Что происходит при расчетах и от чего зависит время отклика? В наших внутренних тестах оно составляло 0,1 сек на 400 млн записей, да и в этих нагрузочных тестах значительная доля откликов выполнялась за доли секунды.
Расчетные операции в rapeed состоят из следующих этапов:
- первичное распределенное чтение данных с диска;
- расчеты внутри нод;
- сетевой обмен внутри распределенной памяти нод;
- расчеты внутри распределенной памяти;
- формирование ответа в формате JSON;
- пересылка ответа потребителю в формате JSON.
Бывают ответы такого большого размера (хоть у нас в ядре и пагинация, то есть задается, сколько первых N элементов нужно), что только их пересылка по сети займет полсекунды - например, раскрытие длинного текстового поля, когда сверху в таблице тоже текстовые поля.
Система адаптируется к пересылкам расчетов определенных конфигураций, и повторно высылает их быстрее. Когда конфликтующих запросов много, на разных уровнях возникают очереди их обработки, и тогда скорость их обработки зависит от десятков практически случайных факторов типа состояния каналов памяти.
Одно можно сказать определенно: архитектура системы была разработана именно под такую нагрузку и под такие задачи и успешно справилась со стресс-тестами.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥4
Результаты тестов. И вишенка на торте!..
Завершающим тестом был «циклический тест на отказ». Представьте: заходит в систему пользователь и начинает довольно интенсивно работать со сводными таблицами: создает их, добавляет поля влево и вверх, сортирует, фильтрует, раскрывает узлы.. И продолжает делать эти действия по циклу до бесконечности. Заходит второй пользователь и начинает довольно интенсивно работать… третий…двадцатый… - и каждый повторяет в цикле эти действия, пока всё новые и новые пользователи входят в систему.
Представили? А мы наблюдаем за этим процессом и фиксируем, когда система перестает справляться с таким наплывом интенсивно работающих пользователей. Контур и источники данных те же.
Как вы думаете, на каком пользователе система перестала справляться (то есть начала выдавать ошибки)? Пишите в комментариях! Правильный ответ будет опубликован в пятницу 21 марта.
#удовольствие_от_аналитики #тесты_rapeed
Завершающим тестом был «циклический тест на отказ». Представьте: заходит в систему пользователь и начинает довольно интенсивно работать со сводными таблицами: создает их, добавляет поля влево и вверх, сортирует, фильтрует, раскрывает узлы.. И продолжает делать эти действия по циклу до бесконечности. Заходит второй пользователь и начинает довольно интенсивно работать… третий…двадцатый… - и каждый повторяет в цикле эти действия, пока всё новые и новые пользователи входят в систему.
Представили? А мы наблюдаем за этим процессом и фиксируем, когда система перестает справляться с таким наплывом интенсивно работающих пользователей. Контур и источники данных те же.
Как вы думаете, на каком пользователе система перестала справляться (то есть начала выдавать ошибки)? Пишите в комментариях! Правильный ответ будет опубликован в пятницу 21 марта.
#удовольствие_от_аналитики #тесты_rapeed
👍3🔥2
rapeed - 100% надежный аналитический сервис
Правильный ответ такой: потолок не найден! Тест работал почти трое суток, добавляя пользователей каждые 30 секунд, и его пришлось прервать по банальной причине: кончилось место на диске для логов. Да, в логах фиксировалась каждая операция, в том числе ответы системы, и файлы логов съели всё место.
За всё время циклического теста на отказ система обработала более 11 000 000 запросов и на все из них (100,00%) выдала верный ответ. Для rapeed неважно, один пользователь работает или десятки тысяч одновременных - система гарантирует верный ответ.
Ответ может быть получен в собственном интерфейсе системы или во внешнем средстве по API. Таким образом, мы доказали, что rapeed - 100% надежный аналитический сервис для любого количества пользователей на любых объемах данных!
#удовольствие_от_аналитики #тесты_rapeed
Правильный ответ такой: потолок не найден! Тест работал почти трое суток, добавляя пользователей каждые 30 секунд, и его пришлось прервать по банальной причине: кончилось место на диске для логов. Да, в логах фиксировалась каждая операция, в том числе ответы системы, и файлы логов съели всё место.
За всё время циклического теста на отказ система обработала более 11 000 000 запросов и на все из них (100,00%) выдала верный ответ. Для rapeed неважно, один пользователь работает или десятки тысяч одновременных - система гарантирует верный ответ.
Ответ может быть получен в собственном интерфейсе системы или во внешнем средстве по API. Таким образом, мы доказали, что rapeed - 100% надежный аналитический сервис для любого количества пользователей на любых объемах данных!
#удовольствие_от_аналитики #тесты_rapeed
🔥10👏6👍5
Зали пушечное видео на www.rapeed.ai
На главной странице нашего обновленного сайта, помимо ключевых преимуществ системы и калькулятора выгоды от её использования, вас встречает небольшое видео живой работы rapeed.
Вопрос к читателям: как вы думаете, что происходит на этом видео?
Пишите свои ответы в комментариях к этому посту!
#удовольствие_от_аналитики
На главной странице нашего обновленного сайта, помимо ключевых преимуществ системы и калькулятора выгоды от её использования, вас встречает небольшое видео живой работы rapeed.
Вопрос к читателям: как вы думаете, что происходит на этом видео?
Пишите свои ответы в комментариях к этому посту!
#удовольствие_от_аналитики
👍5🔥4
Сайзинг rapeed - сколько нужно «железа»?
Данные в rapeed хранятся на диске, а при расчете загружаются и обрабатываются в совокупной оперативной памяти всех нод (виртуальных или физических машин).
Значит, для обработки больших объемов данных системе требуется оперативная память и место на диске. Сколько?
Для первичного расчета мы сделали опросник, в котором можно указать количество записей во всех значимых источниках данных - сколько там дат, чисел и текстовых полей - и получить верхнюю оценку требуемой оперативной памяти и места на диске.
На практике система потребляет в разы меньше памяти, чем занимает дискового пространства.
Во-первых, в память загружаются только те данные, которые нужны для расчетов пользователей. Понятно, что это далеко не весь объем данных, хотя заранее сказать нельзя, какие именно поля потребуются.
Во-вторых, объем занимаемой памяти прямо зависит от плотности данных - доли уникальных значений каждого поля в отношении к количеству записей. Здесь сложно заранее делать какие-то оценки, нужно просто загрузить данные и посмотреть по факту)
В-третьих, система может работать даже в минимальном объеме памяти. При этом новые расчеты будут вытеснять из памяти более старые по принципу FIFO. Если диски быстрые и имеют свой кэш, то пользователи даже не заметят, что данные постоянно грузятся с диска, а небольшой объем памяти интенсивно обновляется. В этом режиме потребность rapeed в памяти несущественно выше обычных СУБД.
Доступная память даёт дополнительный комфорт в работе пользователей - им надо меньше ждать загрузок с диска, хоть это и недолго на современных SSD. Поэтому наш опросник даёт достаточно хороший ориентир по сайзингу с учетом комфорта пользователей - то самое #удовольствие_от_аналитики.
Данные в rapeed хранятся на диске, а при расчете загружаются и обрабатываются в совокупной оперативной памяти всех нод (виртуальных или физических машин).
Значит, для обработки больших объемов данных системе требуется оперативная память и место на диске. Сколько?
Для первичного расчета мы сделали опросник, в котором можно указать количество записей во всех значимых источниках данных - сколько там дат, чисел и текстовых полей - и получить верхнюю оценку требуемой оперативной памяти и места на диске.
На практике система потребляет в разы меньше памяти, чем занимает дискового пространства.
Во-первых, в память загружаются только те данные, которые нужны для расчетов пользователей. Понятно, что это далеко не весь объем данных, хотя заранее сказать нельзя, какие именно поля потребуются.
Во-вторых, объем занимаемой памяти прямо зависит от плотности данных - доли уникальных значений каждого поля в отношении к количеству записей. Здесь сложно заранее делать какие-то оценки, нужно просто загрузить данные и посмотреть по факту)
В-третьих, система может работать даже в минимальном объеме памяти. При этом новые расчеты будут вытеснять из памяти более старые по принципу FIFO. Если диски быстрые и имеют свой кэш, то пользователи даже не заметят, что данные постоянно грузятся с диска, а небольшой объем памяти интенсивно обновляется. В этом режиме потребность rapeed в памяти несущественно выше обычных СУБД.
Доступная память даёт дополнительный комфорт в работе пользователей - им надо меньше ждать загрузок с диска, хоть это и недолго на современных SSD. Поэтому наш опросник даёт достаточно хороший ориентир по сайзингу с учетом комфорта пользователей - то самое #удовольствие_от_аналитики.
👍6👏1
Горизонтальное масштабирование ресурсов в rapeed
Что делать, если объем данных продолжает расти, а ресурсы заканчиваются? Или, например, хочется подбавить оперативной памяти, чтобы увеличить пользователям #удовольствие_от_аналитики? Или подоспели новые источники данных и радостно ждут своего переселения в хранилище rapeed?
Всё просто - добавляйте виртуальные машины в контур rapeed, и произойдет следующее:
- процессор и память только что добавленных машин (нод) мгновенно станут использоваться в расчетах;
- диски новых машин начнут наполняться данными при ближайшем сеансе импорта.
Причем импорт так сделан, что пишет данные на самый свободный диск. То есть диски новых нод будут усиленно заполняться данными до достижения равномерного распределения источников между всеми нодами.
Очень простая аналогия - добавление новой ёмкости для потока воды, связанной с другими ёмкостями единой трубой. Без ограничений. Это и есть настоящее горизонтальное масштабирование.
Что делать, если объем данных продолжает расти, а ресурсы заканчиваются? Или, например, хочется подбавить оперативной памяти, чтобы увеличить пользователям #удовольствие_от_аналитики? Или подоспели новые источники данных и радостно ждут своего переселения в хранилище rapeed?
Всё просто - добавляйте виртуальные машины в контур rapeed, и произойдет следующее:
- процессор и память только что добавленных машин (нод) мгновенно станут использоваться в расчетах;
- диски новых машин начнут наполняться данными при ближайшем сеансе импорта.
Причем импорт так сделан, что пишет данные на самый свободный диск. То есть диски новых нод будут усиленно заполняться данными до достижения равномерного распределения источников между всеми нодами.
Очень простая аналогия - добавление новой ёмкости для потока воды, связанной с другими ёмкостями единой трубой. Без ограничений. Это и есть настоящее горизонтальное масштабирование.
👍8🔥2
Номинация на Data Awards’25
Меня вместе с rapeed номинировали на премию Data Awards’25. Организаторы выложили интервью со мной про rapeed и его значение для отрасли. Почитайте!
#удовольствие_от_аналитики
Меня вместе с rapeed номинировали на премию Data Awards’25. Организаторы выложили интервью со мной про rapeed и его значение для отрасли. Почитайте!
#удовольствие_от_аналитики
🔥17👍7❤3👏2🥰1
У Фейсбука не получилось..
Мы всё время ищем, есть ли в мире еще аналоги нашей технологии. В результате поисков нашли статью 2016 года ученых из Facebook Research Lab, в которой они описывали принципы технологии Cubrick - распределенного OLAP in-memory движка.
Интересно, что пишут математики Facebook о недостатках ROLAP-средств анализа данных: операции «slice-n-dice, roll-ups, drill-down» недоступны пользователям в режиме онлайн, что резко ограничивает свободу работы с данными и, следовательно, количество и качество бизнес-решений.
Технология «не взлетела» дальше тестов - больше о ней упоминаний нет. Есть признаки, что Google тоже пыталась создать распределенный in-memory OLAP по тем же причинам - и у них тоже не получилось. Нам, сделавшим эту технологию и доведшим её до production, интересно почитать описание и математические модели технологий гигантов. Даже видно места, где маститые математики Фейсбука свернули не туда. Но мы им об этом не скажем) - пусть #удовольствие_от_аналитики получают наши пользователи!
Мы всё время ищем, есть ли в мире еще аналоги нашей технологии. В результате поисков нашли статью 2016 года ученых из Facebook Research Lab, в которой они описывали принципы технологии Cubrick - распределенного OLAP in-memory движка.
Интересно, что пишут математики Facebook о недостатках ROLAP-средств анализа данных: операции «slice-n-dice, roll-ups, drill-down» недоступны пользователям в режиме онлайн, что резко ограничивает свободу работы с данными и, следовательно, количество и качество бизнес-решений.
Технология «не взлетела» дальше тестов - больше о ней упоминаний нет. Есть признаки, что Google тоже пыталась создать распределенный in-memory OLAP по тем же причинам - и у них тоже не получилось. Нам, сделавшим эту технологию и доведшим её до production, интересно почитать описание и математические модели технологий гигантов. Даже видно места, где маститые математики Фейсбука свернули не туда. Но мы им об этом не скажем) - пусть #удовольствие_от_аналитики получают наши пользователи!
🔥12👍8🤣4❤3
Сводная таблица или дашборд?
Вечный холивар в среде BI - что нужно пользователям? Ученые из Facebook пишут, что операции раскрытия/сворачивания, добавления срезов на лету и сквозной сортировки таблицы (примерно так можно перевести с английского «slice-n-dice, roll-ups, drill-down») по определению возможны только в сводной таблице и что только она даёт свободу работы с данными.
Российские вендоры BI-средств поголовно выступают за интерактивные дашборды - видимо, потому, что сводной таблицы из коробки у них нет и каждая сводная таблица - это кастомная разработка на SQL и средствах визуализации.
Если говорить про пользователей, то мы не нашли опросов, которым можно верить. Экспертные оценки западных вендоров (а эксперты кто и где они сейчас?..) говорили, что 80% пользователей сидят в сводных таблицах Excel и им ничего больше не надо. Дашбордами пользовались только руководители или неквалифицированные пользователи - одни не хотели данные крутить, другие не умели. Дашборды при этом создавали и создают сотнями и тысячами, а средний срок жизни одного дашборда - 3,5 открытия (!!!, данные Qlik).
Как вы думаете, что нужнее пользователям? Пишите в комментариях!
#удовольствие_от_аналитики
Вечный холивар в среде BI - что нужно пользователям? Ученые из Facebook пишут, что операции раскрытия/сворачивания, добавления срезов на лету и сквозной сортировки таблицы (примерно так можно перевести с английского «slice-n-dice, roll-ups, drill-down») по определению возможны только в сводной таблице и что только она даёт свободу работы с данными.
Российские вендоры BI-средств поголовно выступают за интерактивные дашборды - видимо, потому, что сводной таблицы из коробки у них нет и каждая сводная таблица - это кастомная разработка на SQL и средствах визуализации.
Если говорить про пользователей, то мы не нашли опросов, которым можно верить. Экспертные оценки западных вендоров (а эксперты кто и где они сейчас?..) говорили, что 80% пользователей сидят в сводных таблицах Excel и им ничего больше не надо. Дашбордами пользовались только руководители или неквалифицированные пользователи - одни не хотели данные крутить, другие не умели. Дашборды при этом создавали и создают сотнями и тысячами, а средний срок жизни одного дашборда - 3,5 открытия (!!!, данные Qlik).
Как вы думаете, что нужнее пользователям? Пишите в комментариях!
#удовольствие_от_аналитики
👍5👏3🔥2💯2❤1