Evgeny_CD, Архитектор (11.10.2016 21:24, просмотров: 73) ответил Скрипач на А накидайте ссылок на опен-сорсные проекты трендов-архивов.-
- В первый момент мне почудилось, что ТС хочет такое на MCU залудить. От этого и офигел слегка. Мне доводилось проектировать (на уровне архитектуры) весьма производительные логгеры (с поиском и произвольной выдачей) при небольшом объеме Evgeny_CD(192 знак., 11.10.2016 21:47)
- Евгений, при всём, блин, глубочайшем уважении, ответ "их очень много" не совсем подходит к вопросу "накидайте ссылок", вы не находите? :) Скрипач(106 знак., 11.10.2016 22:16)
- Самые распространенные -> --> Более серьезная внутри Evgeny_CD(272 знак., 11.10.2016 22:23, ссылка, ссылка)
- Евгений, при всём, блин, глубочайшем уважении, ответ "их очень много" не совсем подходит к вопросу "накидайте ссылок", вы не находите? :) Скрипач(106 знак., 11.10.2016 22:16)
- Железо - сервер начального уровня. А в чем проблема? Объем хранения: 10байт*10лет*365*24*60 = 52МБ По нынешним временам, даже в сто раз больше - не впечатляет, нет? - Скрипач(11.10.2016 21:41)
- Если это целый сервер, а не контроллер с SD-карточкой, то зачем что-то искать? С таким запасом по железу оно тупо пишется за полчаса. Файло на диске, дубликат в оперативке, усреднить 52 метра и без оптимизации -- один чих. Николай Коровин(84 знак., 11.10.2016 21:46)
- А чё распутывать-то? RRDTool, вон - есть. Что еще есть? Готовое? Скрипач(276 знак., 11.10.2016 22:23)
- Параметры надо рассматривать в комплексе. Evgeny_CD(180 знак., 11.10.2016 21:45)
- Насчет 17 транзакций... может тысяч транзакций? Дисковый кэш, опять же. Нет? Скрипач(77 знак., 11.10.2016 22:25 - 22:29)
- Я не спец по БД. Чуток курил в силу прикладных задач. Оптимизация БД - это целое искусство, и ничего очевидного там нет. В зависимости от тонкостей настройки тот же MySQL дает разницк в перфомансе на порядок запросто на одной и той же задачи. Evgeny_CD(52 знак., 11.10.2016 22:36, ссылка)
- Это, практически ассемблер, в контексте обсуждаемой задачи. - Скрипач(11.10.2016 22:41)
- Категорически не согласен! На чистом SQL все описанное Вами укладывается в полэкрана. И ничего изобретать не надо ваще. - Evgeny_CD(11.10.2016 22:44)
- Т.е. тулза для работы с самим SQL готовая, ставится и работает. К популярным интерфейсы есть чуть ли не под все языки прогаммирования, для всех ОС. А эти полэкрана все равно написать придется. - Evgeny_CD(11.10.2016 22:45)
- Евгений, посмотрите RRDTool. Кагбэ не совсем "пол экрана". Нет? - Скрипач(11.10.2016 22:52)
- Т.е. тулза для работы с самим SQL готовая, ставится и работает. К популярным интерфейсы есть чуть ли не под все языки прогаммирования, для всех ОС. А эти полэкрана все равно написать придется. - Evgeny_CD(11.10.2016 22:45)
- Категорически не согласен! На чистом SQL все описанное Вами укладывается в полэкрана. И ничего изобретать не надо ваще. - Evgeny_CD(11.10.2016 22:44)
- Это, практически ассемблер, в контексте обсуждаемой задачи. - Скрипач(11.10.2016 22:41)
- Я не спец по БД. Чуток курил в силу прикладных задач. Оптимизация БД - это целое искусство, и ничего очевидного там нет. В зависимости от тонкостей настройки тот же MySQL дает разницк в перфомансе на порядок запросто на одной и той же задачи. Evgeny_CD(52 знак., 11.10.2016 22:36, ссылка)
- Насчет 17 транзакций... может тысяч транзакций? Дисковый кэш, опять же. Нет? Скрипач(77 знак., 11.10.2016 22:25 - 22:29)
- Если это целый сервер, а не контроллер с SD-карточкой, то зачем что-то искать? С таким запасом по железу оно тупо пишется за полчаса. Файло на диске, дубликат в оперативке, усреднить 52 метра и без оптимизации -- один чих. Николай Коровин(84 знак., 11.10.2016 21:46)
- В первый момент мне почудилось, что ТС хочет такое на MCU залудить. От этого и офигел слегка. Мне доводилось проектировать (на уровне архитектуры) весьма производительные логгеры (с поиском и произвольной выдачей) при небольшом объеме Evgeny_CD(192 знак., 11.10.2016 21:47)