RS
А при группировке событий есть ограничение на 1000 строк, да?..😔
Меняется в конфиге
Size: a a a
2020 August 11
v
Меняется в конфиге
Можно чуть чуть подробнее?
v
в каком конфиге)
v
сохранил
v
спасибо
NA
@erthink Лёня, привет. Вот такой вопрос по FPTA: Есть у меня 200К записей (пусть это будет фид с IP). Все записи лежат в табличке и являются первичным ключом. Кейс 1: Запрос вида: Если у меня в событии есть IP из таблички, то что-то там сделать (не с данными в табличке). Кейс 2: В табличке уже не 1 колонка, а 5 (IP - первичный ключ, какое-то текстовое поле 2 штуки, числовые поля - 2 штуки). И я делаю такой же запрос ( Если у меня в событии есть IP из списка, то что-то там сделать) при этом я проверяют только наличие IP в таблице и не достаю оттуда данные.
NA
Вопрос: Кейс 1 и кейс 2 будут одинаковы по производительности?
NA
или есть накладные расходы на поддержание доп. полей и кейс 2 будет более тормозной
LY
или есть накладные расходы на поддержание доп. полей и кейс 2 будет более тормозной
Накладные расходы непосредственно на поддержку дополнительных колонок минимальны, ты их не заметишь.
Но:
- если в колонках будут длинные значения, то их всё-таки придется таскать (в том числе через кеш CPU).
- если колонки проиндексировать, то стоимость обновлений вырастит пропорционально кол-ву индексов.
P.S.
Если не ошибаюсь, сейчас в ТС всегда создается теневая колонка _id, которая является настоящим PK.
Т.е. весьма вероятно, что ты не сможешь через GUI создать табличку без лишних индексов.
Но:
- если в колонках будут длинные значения, то их всё-таки придется таскать (в том числе через кеш CPU).
- если колонки проиндексировать, то стоимость обновлений вырастит пропорционально кол-ву индексов.
P.S.
Если не ошибаюсь, сейчас в ТС всегда создается теневая колонка _id, которая является настоящим PK.
Т.е. весьма вероятно, что ты не сможешь через GUI создать табличку без лишних индексов.
К
Накладные расходы непосредственно на поддержку дополнительных колонок минимальны, ты их не заметишь.
Но:
- если в колонках будут длинные значения, то их всё-таки придется таскать (в том числе через кеш CPU).
- если колонки проиндексировать, то стоимость обновлений вырастит пропорционально кол-ву индексов.
P.S.
Если не ошибаюсь, сейчас в ТС всегда создается теневая колонка _id, которая является настоящим PK.
Т.е. весьма вероятно, что ты не сможешь через GUI создать табличку без лишних индексов.
Но:
- если в колонках будут длинные значения, то их всё-таки придется таскать (в том числе через кеш CPU).
- если колонки проиндексировать, то стоимость обновлений вырастит пропорционально кол-ву индексов.
P.S.
Если не ошибаюсь, сейчас в ТС всегда создается теневая колонка _id, которая является настоящим PK.
Т.е. весьма вероятно, что ты не сможешь через GUI создать табличку без лишних индексов.
а во втором кейсе не получится без лишних индексов
NA
Ага, ясно. Скажи, если есть поля с длинными строками и они не затрагиваются поиском, все равно это повлияет на сокрость?
LY
Ага, ясно. Скажи, если есть поля с длинными строками и они не затрагиваются поиском, все равно это повлияет на сокрость?
FPTA будет читать из b+tree всю строку (row), и если там пяток строк по 20К, то это никогда не будет бесплатно.
Поэтому повлияет, но минимально (скорее всего не заметишь, если строки не мега-длинные).
Поэтому повлияет, но минимально (скорее всего не заметишь, если строки не мега-длинные).
NA
Огромное спасибо! В моем кейсе нет таких убер-длинных строк, т.ч. я успокоился ))))
LY
Огромное спасибо! В моем кейсе нет таких убер-длинных строк, т.ч. я успокоился ))))
Незашто )
2020 August 12
A
добрый день! а кто пользуется типовыми отчетами по событиям в MP SIEM ?
i
добрый день! а кто пользуется типовыми отчетами по событиям в MP SIEM ?
добрый! а типовые - это которые "отчет по всем событиям"?
A
Детальные отчеты по событиям и отчеты по статистике событий
A
Те что можно выбирать в выпадающем списке.
i
мы пользуемся. не хватает возможности пробрасывать группы в отчет.