В общем после сбора информации, проб и ошибок с использованием сторонних систем логгирования все-таки было принято решение попробовать собрать что-то более подходящее самостоятельно. На текущий момент получилось следующее:
- один инстанс логгера может принимать данные по любому из настроеных каналов: UnixSocket, WebSocket, HTTP
- в качестве БД для занесения информации для тестов использовали Монго в ее базовой настройке
- максимальную скорость принятия и внесения в БД поступающей информации получили через UnixSocket - около 100тыс записей в сек (причем есть все основания считать "узким местом" Монгу)
- клиентская библиотека в UnixSocket в пиковых тестах успевала "напихивать" до 500тыс событий в сек
В принципе скорость в штатном режиме будет гораздо ниже, думаю и до 20тыс в сек не дойдет (до 50тыс пиковые нагрузки). Но встал следующие вопросы, требующие решения (возможно, некоторые мои предположения будут нупскими):
1. Монго, конечно, быстро принимает записи, но работать потом по ней с выборками будет, наверное, очень проблематично, т.к. если хранить все данные в одной коллекции, она вырастет до неимоверных размеров. Рассматриваем вариант "посуточного" хранения информации - в 00:00 просто переименовать рабочую коллекцию в суточную. Но тут появляются сомнения, а можно ли потом эффективно работать по нескольким коллекциям с выборками/фильтрациями/слияниями?
2. Если отказаться от Монго, то какая из РСУБД в состоянии "принимать в себя" около 100тыс записей в сек? Речь не про инсерты, а именно про сами записи, т.к. вставка производится не "построчно", а блоками размер которых зависит от объема поступающей информации (если мало - малыми порциями, если поток выше - порции больше).
3. Может какой-то смешанный вариант реализовать, с системой переноса и "нормализации" из Монго в РСУБД. Но тут встает вопрос оперативности. Если сервис логгера будет писать в Монго, а некий переносчик раз в минуту будет все забирать из Монго и складировать в РСУБД, будет ли он успевать за минуту переносить все то, что будет накоплено в Монго, даже если брать большими блоками? Ну и плюс появится некоторая задержка с отображении поступающей информации, а иногда нужно "реалтайм" мониторить поступление информации от какого-то из клиентов и сразу же ее отображать в гуевке. Придется шаманить с межпроцессовым взаимодействием логгера и ГУИ.
Буду благодарен за любой совет/предложение по существу.
ЗЫ. Критика, конечно, тоже приветствуется, но в рамках приличия =))
0. Что принимаете: структирированую, не струтурированную, бинарную, текстовую
1. Как храните: бинарник, текстовик, 3NF
2. Как обрабатываете для хранения: на лету, ...
3. Какие запросы к данным идут
4. Какой rps требуется
sim3x,
0. частично структурированную: несколько полей обязательных, строковые данные + одно поле JSON-строки (на текущий момент в монго все летит как один объект)
1. сейчас в Монго все летит как объекты
2. обработка для записи сейчас не требуется, т.к. передаются уже сформированные клиентами объекты, проверяются только обязательные "поля - свойства"
3. по выборкам пока предсказать сложно, но что точно будет - это запрос логов за какой-то интервал времени с фильтрацией по обязательным полям и сортировкой по времени, и наверняка будет еще просто поиск по подстроке в свободном поле данных
4. как минимум около 20тыс в сек входящих данных, с пиковым пределом около 50тыс в сек (но это будет крайне редко, только в случае падения подключенных систем)
sim3x, так потому и появилась необходимость базы и всего остального, что появилась серьезная необходимость читать/анализировать логи, причем как разных модулей раздельно, так и в совокупности сквозной сортировкой по времени. Так что текстовики - это пройденный этап.
появилась серьезная необходимость читать/анализировать логи, причем как разных модулей раздельно, так и в совокупности сквозной сортировкой по времени.
Артем, только нужно учесть несколько моментов:
- в КХ нет UPDATE (хотя подвижки в этом направлении есть)
- в КХ нет DELETE (в привычном понимании)
- КХ не любит много INSERT (быстрее вставить 10к за раз, чем 10 раз по 1к)
Дмитрий Беляев, ага, это уже почитал и понял.
В принципе:
- логи апдейтить не надо, так что не страшно
- интерес к логам пропадает через недельки две, а как я понял, есть удаление партициями месячными, ну в принципе не критично, если старые полежат в базе на пару недель дольше
- по поводу инсертов, там простая как кирпич саморегуляция - пришел пакет данных, выполняется вставка, пока не вернулся колбек о результатах новая порция копится (конечно есть и тайминг на случай отвала БД и страховка), как пришел ответ от базы о завершении операции кидается весь следующий накопленный в буфере кусок. В пиковые нагрузки такие "пакеты" могут быть по 15-20 тыс записей, в среднем они (пока для Монги получается) около 5-6 тыс в команде
Артем, именно так и есть, просто решил поделится своим опытом, ибо штука хорошая, но требует особого подхода
в частности у нас она позволила заменить 6 машин с монгой на 2 с КХ после перевода собираемой статистики на КХ, и то вторая больше на случай отказов, по факту справляется 1 машина
Еще раз спасибо за наводку.
Не кривя душой, в сравнении с монгой скорость вставки ниже примерно на 40% (на одном инстансе логгера удалось добиться скорости вставки около 60тыс в сек, против 100тыс в сек на Монго). Может быть если покрутить настройки, получится и увеличить данный показатель, но в принципе это уже перекрывает наши запросы.
Выборки делаются быстро и четко, партиции сделали посуточные, так что даже не придется хранить лишнее дольше, чем это нужно.
Единственное, что смущает - это подъедание памяти сравнимое с Монгой. Но тут сложно сравнивать - ибо и CH и MDB на одной машине крутятся и монго по идее должна есть все, что может, освобождая то, что просит система... в общем тут сложнее - надо будет покурить мануалы и может помучать самих яндексоидов на тему ограничений в параметрах запуска сервиса.
Еще раз СПАСИБО!
PS. Поправочка. На сервере скорость вставки в один поток из одного инстанса при приеме данных через UNIX-сокет достигла 80тыс в сек. Этого более чем достаточно для работы!!!
chupasaurus, Если это вопрос ко мне, то нет =)))
Мы пока изучаем решение от Яндекса и его возможности (и возможности работы с системой под наши хотелки).
1. MongoDB вам и миллион записей создаст в секунду, используйте шардинг и будет вам счастье.
2. Использование MongoDB для хранения логов так себе решение поскольку она придумана не для этого.
3. Смотрите в сторону ELK. Не нравится оно, есть https://prometheus.io/docs/introduction/overview/ + Graphana. Еще есть graylog.
Опций много.
ELK смотрели, GrayLog тоже и еще ряд уже готовых "из коробки" систем лог-менеджмента. Но они не совсем устраивают своими возможностями. Точнее даже сказать, у них у каждой есть что-то нужное, но в совокупности ни у одной =(
К тому же помимо менеджмента логов в обычном понимании, нам нужна возможность читать логи "реалтайм" хотя бы по простейшим фильтрам (проект/сервер/тип событий) + отображать в минифреймах текущую информацию о каждом из проектов (которую каждый проект постоянно сообщает о себе)
Philipp, Вы правильно говорите, что никто не сможет это прочесть, но это уже такой нюанс, который решается нюансами ГУИ. Простой вариант - это просто ведение счетчика, который считает полученные для отображения записи и в случае превышения, скажем, 100 в секунду, стопит отображение и выдает предупреждение о слишком общих условиях выборки для реалтайм вывода.
Но по факту - нужна возможность, это один из базовых критериев, который нельзя пересмотреть.
Монго, конечно, быстро принимает записи, но работать потом по ней с выборками будет, наверное, очень проблематично
Ага-ага блокировки всякие.
какая из РСУБД в состоянии "принимать в себя" около 100тыс записей в сек?
Правильно настроенный MySQL. Повторяю, не MariaDB, а MySQL.
Ещё в версии 5.7 можно было сделать так чтобы он работал почти как NoSQL база.
Если сервис логгера будет писать в Монго, а некий переносчик раз в минуту будет все забирать из Монго и складировать в РСУБД, будет ли он успевать за минуту переносить все то, что будет накоплено в Монго, даже если брать большими блоками?
Так и не нашёл такой переносчик. Разве что самому писать.
Буду благодарен за любой совет/предложение по существу.
Посмотрел аранго - крайне сомневаюсь в его подходимости:
- работать с ним через HTTP вместо поддержки постоянного коннекта
- так и не нашел возможности вставки записей блоками
Может он и держит большое кол-во данных и умеет нечто схожее с SQL, но для высокоскоростного наполнения данными там какой-то треш...
Но спасибо в любом случае, теперь знаю еще одну БД.
Лучшим опен сорс решением будет, на мой взгляд, для данной задачи будет взять elastic стак + RabbitMQ/Kafka (гибкая фильтрация + симпотная вебмордашка прилагаются).
Средний
