Вставляются данные в такие таблицы:

Главная




Производная от главной:




Могу отказаться от всех индексов, кроме Primary и idxDateTimeSend в главной таблице и idxMessageIDFirewalls в производной от главной.

Dimitry SibiryakovMS SQL, Cache, любая in-memory.


А что-то полегче не потянет: Firebird, ADS?

Barclayflight-op,

SAP HANA 2.0 Express Edition (бесплатно)

(*Перекрестился*)

miksoftDimitry Sibiryakovплоские CSV-файлы со вставкой
справятся лучше.+1
С промежуточной буферизаций в CSV/TSV потянет, наверное, практически любая СУБД.


А идея-то, по факту хороша. Простой парсер csv обработал миллион строк за ~6 секунд. Сразу, было дело, подумал "Да нет, бред какой-то" :)

Alibek B.> "DateTimeSend" DATETIME,
> "DateSend" CHAR(10),
> "TimeSend" CHAR(10),

Зачем последние два?

для группировки


> inInterface VARCHAR,
> outInterface VARCHAR,

Почему не номер интерфейса?




Тут нет номера интерфейса. Здесь вообще может быть что угодно - от лога Cisco ASA до Windows Security EventLog. За универсальность решения приходится чем-то платить, в данном случае - избыточностью данных.

kdvflight-op,

до varchar без размера запись где-то 52 байта (если однобайтовые символы в строках).
это значит, что 100к записей по 52 байта в секунду это 5 мегабайт в секунду, что не бог весть что.
Но если перемножить на минуты и т.д., выходит
300 мегабайт в минуту
18 гиг в час
423 гигабайта в сутки
157 терабайт в год.

Хрень какая-то. А если еще безразмерные варчары сюда приклеить, вообще бред какой-то. Очередная супер-база?

Не надо перемножать, всё-таки актуальность логов имеет временные ограничения.
Преамбула:
Есть самописная система анализа логов. Скриптами парсит входящие данные и раскладывает их по таблицам. База SQLite, благо ничего критичного нет и данных максимум на сотню INSERT-ов в секунду.
Временами, почитывая всякое-разное из опыта эксплуатации людьми enterprise-решений удается почерпнуть что-то полезное для себя - где интересный отчет, где идею стэктрейса логов. В-общем, в мире больших решений есть вещи, полезные и для "игрушечных" систем. Перечитывая Хабр, наткнулся на интересный комментарий:

На данный момент у меня кластер А 10 машин (каждая машина 24 ядра 48 гб памяти) с трудом тянет 15к логов в секунду. На кластере Б памяти 128 гб на машину, что дает порядка 50к логов в секунду. Это при дневных индексах, 7-ми дневно ретеншене и около 1000 шард на кластер А, около 3000 шард на кластер Б. Если переключится на часовые индексы и снизить ретеншен до 3-х дней количество шард на кластере Б поднимается до 25к и он начинает падать с завидной периодичностью. У всех машин стоит по 4 диска 1.8тб. На кластере А количество документов около 7г и диски заняты от 26% до 45%, на кластере Б документов около 3.5г, диски заняты от 9% до 14%. Полный траффик логов у меня 130 логов/с, что значит мне нужно кластер А расширить до как минимум 200 машин, что будет 2 миллиона долларов только на покупку железа, обслуживание встанет в отдельные деньги. Глядя на подобные суммы начинаешь уже задумываться о спланке, который безумно дорог, но тебе вообще не надо думать об инфраструктуре.

Решил глянуть - а что же у меня с производительностью, получил (в зависимости от вида лога) цифры порядка 10-15к на ядро.
Упаси господь, думать что я со своей приблудой на Delphi собрался покорять мир, но нездоровое любопытство и толика свободного времени располагают попробовать реализовать полную производительность.

Преамбула закончилась

Я тут что подумал: можно действительно писать в csv-файл, производительность будет лимитирована дисковой подсистемой, а чтобы вытаскивать оттуда информацию - создать разреженный внешний индекс - с MessageID и временем с разрешением, скажем, в 0.5-1 сек.
Да, спасибо за идею!

Dimitry SibiryakovОбычно информация из логов нужна исключительно в виде каких-то агрегатов. Эти агрегаты
имеют гораздо меньший объём, чем сырые данные, так что тебе агрегатор, складывающий
выжимку в базу будет, вероятнее всего, полезнее, чем индекс.

А оно так и работает, по сырым данным формируются alert-ы. Но при разборе инцидента зачастую желательно знать, что происходило до и после. Так сказать, нужен контекст alert-а.

"Почему кот яйца лижет? Потому что может" :))

kealon(Ruslan)flight-op,

а говорил что у тебя всё чики пуки - 21730248 , а оно вон оно что, в базу он складывает....

Прости, с трудом тебя понимаю, в базу нынче складывать постыдно и осуждается соборно?
Да, у меня есть проблемы записать то, что я могу обработать.

kealon(Ruslan)flight-op,

По моему опыту, скрипт написанный даже самым криворуким инженером, шпарит данные куда быстрее.
Просто по факту, вы подняля сабж о потоках не выяснив где у программы узкое место. Это первое что нужно делать при оптимизациях. Я в том сабже указал что что-то не так. Судя по тому что какое-то сомнение у вас зародилось, мой пост пошёл куда нужно.

(*Миролюбиво*) Извини, Руслан, я что-то опять тебя не понимаю. В однопоточной программе я мог записать то, что обрабатываю. При повышении производительности за счет использования потоков возникло узкое место - запись на диск. Всегда возникает следующее бутылочное горлышко - в пределе это законы физики. В чём проблемы-то?

И да, старик, чуть не забыл я в суматохе - априори ставя своего собеседника ниже "криворукого инженера" ты пытаешься поднять свою самооценку? Разочарую тебя, тот кому нужно поднятие самооценки таким образом получает все остальные проблемы в жизни бесплатно.

WBR