LINUX.ORG.RU

Архитектура простого приложения

 ,


0

1

Здравствуйте.

Нужна помощь опытных разработчиков. Суть задачи: собирается информация, допустим средняя загрузка системы (avg) за три дня с интервалом в 5с. Она записывается в БД sqlite. Затем пользователь по запросу через браузер получает эти данные.

Приложение использует Ruby on Rails.

Как организовать сбор данных:

  1. Выделить отдельный процесс для сбора
  2. Организовать сбор данных через Active Jobs
  3. ????????

3. Рисовать график?

Зависит от того, что тебе надо, а то ты, вроде как, и сам не понимаешь, что ты хочешь получить, судя по тексту.

Только каждые пять секунд — это перебор. Вполне хватит сбора каждые десять-тридцать минут. Нутыпонил.

Или тебя реализация интересует?

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Меня интересует как лучше организовать сбор данных которые обновляются достаточно часто, для примера каждые 5 сек. Выделить отдельный процесс который самостоятельно будет собирать данные и выгружать в БД или это можно организовать средствами rails.

bihunger
() автор топика
Ответ на: комментарий от bihunger

можно использовать эту библиотеку, она предоставляет DSL для генерации правил для cron https://github.com/javan/whenever

создай сервис или таск в коде своего rails приложения который будет собирать данные и ложить в базу, cron будет запускать этот сервис в отдельном процессе

также можешь глянуть на другие библиотеки типа https://github.com/tobiassvn/sidetiq или https://github.com/resque/resque-scheduler

anonymous
()
Ответ на: комментарий от anonymous

можно использовать эту библиотеку, она предоставляет DSL для генерации правил для cron

Можно и эту. Только не поможет! :) Не умеет cron в «каждые 5 сек» :)

anonymous
()
Ответ на: комментарий от bihunger

Меня интересует как лучше организовать сбор данных которые обновляются достаточно часто, для примера каждые 5 сек.

Да чем угодно, что умеет в sql, если тебе не принципиально. Но на таких условиях оно у тебя само будет нагружать систему, тем более с такой частотой.

r3lgar ★★★★★
()
Ответ на: комментарий от bihunger

Интересно а как тогда работает команда top?

Так и работает. Некоторую дополнительную нагрузку он всё же даёт.

Будет небольшая лишняя нагрузка (или большая, если руки из задницы растут), но тебе всё равно только поллингом, исходя из условия задачи.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Проблема не в лишней нагрузке, а в синхронизации. Нужен лок на момент обновления базы, иначе данные будут не консистенты. Плюс в случае sqlite и прочих embedded СУБД подключится к базе в два потока вряд ли получится из-за ограничений самой СУБД.

Вообще топик стартеру лучше почитать про RRD.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

MySQL думаю то же, или ты че хочешь сказать что при написании какого нибудь сраного форума или чата надо париться с локами при каждом добавлении сообщения? Это просто срыв покровов какой то.

TDrive ★★★★★
()
Ответ на: комментарий от xpahos

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

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

постгрес например

Атомарна именно транзакция, которая и вызывает лок таблицы. Понимаешь разницу?

MySQL думаю то же, или ты че хочешь сказать что при написании какого нибудь сраного форума или чата надо париться с локами при каждом добавлении сообщения? Это просто срыв покровов какой то.

Последовательность сообщений в чате не имеет значения, как и на форуме. Если ты завязан на время, то все становится значительно сложнее. Как самый простой вариант как раз и RRD подойдет.

Даже в монге, которая кстати любит просто так просирать данные, и то инсерт атомарная операция.
When a single write operation modifies multiple documents, the modification of each document is atomic, but the operation as a whole is not atomic and other operations may interleave. However, you can isolate a single write operation that affects multiple documents using the $isolated operator.

https://docs.mongodb.com/manual/core/write-operations-atomicity/ Не атомарная.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Атомарна именно транзакция, которая и вызывает лок таблицы. Понимаешь разницу?

Во первых этим всем занимается драйвер, во вторых какой лок? Что хочешь сказать что к одной таблице нельзя одновременно сделать 2 операции?

Последовательность сообщений в чате не имеет значения, как и на форуме.

Их принято по времени сортировать, или ты о чем вообще?

Если ты завязан на время, то все становится значительно сложнее.

Что значит завязан?

https://docs.mongodb.com/manual/core/write-operations-atomicity/ Не атомарная.
the modification of each document is atomic

Помойму как раз это и нужно.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

Во первых этим всем занимается драйвер, во вторых какой лок?

Не драйвер, а СУБД.

Что хочешь сказать что к одной таблице нельзя одновременно сделать 2 операции?

При конкурентном доступе к одной и той же записи происходит либо блокировка, либо версионирование. В случае блокировки мы получаем семафор. Каждая последующая транзакция будет ждать предыдущую в случае если СУБД разрешает шарить данные между транзакциями. Это называется isolation.

Их принято по времени сортировать, или ты о чем вообще?

Я не правильно выразился. Последовательность изменений сообщений на форуме не имеет значения. Если модератор удалил мат из сообщения, а в этот момент пользователь что-то дописывал и они одновременно нажмут сохранить, то ничего страшного не произойдет. А вот если скрипт считает твой годой бонус на работе и сначала должен умножить зарплату на какой-то коэфициент, записать значение, а потом другой скрипт должен вычесть налоги, то последовательность имеет значение. Теперь ты понимаешь зачем нужна изоляция?

Что значит завязан?

Попробуй сделать систему мониторинга и все быстро поймешь.

Помойму как раз это и нужно.

Видимо ты никогда не работал с распределенными вещами и тем более геораспределенными. Ты в курсе что люди покупают атомные часы за много-много денег для того чтобы просто проверять консистентность данных?

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Не драйвер, а СУБД.

Не суть, главное что нам это делать не нужно.

При конкурентном доступе к одной и той же записи происходит либо блокировка, либо версионирование.

А как двумя инсертами сделать конкурентный доступ к одной записи?

А вот если скрипт считает твой годой бонус на работе и сначала должен умножить зарплату на какой-то коэфициент, записать значение, а потом другой скрипт должен вычесть налоги, то последовательность имеет значение.

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

Теперь ты понимаешь зачем нужна изоляция?

Я не понимаю каким образом изоляция может влиять на порядок выполнения запросов, если запускаются они одновременно.

Попробуй сделать систему мониторинга и все быстро поймешь.

Там нет ничего кроме простого инсерта в базу данных, записи не апдейтятся. О какой завязки на время ты говоришь?

Ты в курсе что люди покупают атомные часы за много-много денег для того чтобы просто проверять консистентность данных?

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

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

А как двумя инсертами сделать конкурентный доступ к одной записи?

а) INSERT с апдейтом б) одинаковые значения при одном и том же индексе.

Я не понимаю каким образом изоляция может влиять на порядок выполнения запросов, если запускаются они одновременно.

Отрой для себя мир ACID. Почитай книжки. Посмотри как люди делают.

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

Конечно прекрасно синхронизируются. Записи в ДЦ1 и записи в ДЦ2 сами будут знать какой вариант выбрать. В системах мониторинга это все есть, просто ты не видел ничего сложнее zabbix и не видел что значит N+1 ДЦ.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

а) INSERT с апдейтом

upsert? казалось бы причем тут он если речь про обычные инсерты?

б) одинаковые значения при одном и том же индексе.

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

Зачем конкретно ТСу брать лок на таблицу перед инсертом (кроме случая использования sqlite) ты так и не смог объяснить, за неделю.

Отрой для себя мир ACID. Почитай книжки. Посмотри как люди делают.

И про ACID знаю, и книжки читал и как люди делаю смотрел. А ты видимо решил уйти от моего вопроса: «Каким раком с помощью изоляции регулировать порядок выполнения определенных запросов?»

Конечно прекрасно синхронизируются. Записи в ДЦ1 и записи в ДЦ2 сами будут знать какой вариант выбрать. В системах мониторинга это все есть, просто ты не видел ничего сложнее zabbix и не видел что значит N+1 ДЦ.

У тебя какая то мания рассказывать другим что они видели а чего не видели.

TDrive ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.