1

Suppose there is system for gathering info about system activities. There is a client part with an interface and there are agent parts that are installed on each machine. I estimate that there could be max 20 computers now. Later could be more like 50.

My solutions:

  1. Agent stores data into local database e.g. sqlite. There is also a service which can be used by a client to query data. So if a client wants to display data for 50 computers, he sends a query to 50 computers. I'am on that solution now but maybe it's totally wrong.

  2. Agent stores data into local database (I don't known good one for that). There is also server (main database) and local databases are synchronized with the server. In this case, a client connects to the main database to display data.

  3. Agent sends data in realtime to main database. So same as point 2, but there is no sync.

  4. Like in point 3, but agent buffers data in local database and sends it in small chunks to main database.

What is the best approach?

Improve this question
2
  • 3
    I'd spend a bit more time considering what's really required versus what is nice to have. In particular, what kind of speed/accuracy does the system need? You might want to look at existing projects like Cacti or Nagios.
    – Darien
    Jun 14, 2011 at 19:31
  • So you're trying to implement your own Nagios-like? Maybe look at their architecture decisions. But start by shipping the simplest thing that could possibly work, a minimum viable product. Don't design everything up front. It's a waste of time.
    – Rein Henrichs
    Jun 14, 2011 at 19:37

2 Answers 2

Reset to default
1

Either go Real-time (Option 3) if you are anticipating a constant connection to the DB. Or go with Sync (Option 2) if your users need to work offline.

Options 1 & 4 are hybrids, with the down side of both 2 & 3 but none of the Up Side.

Improve this answer
0

The decision whether to store a database locally or on the server depends on many factors, here a few from the top of my head:

  • the size of the data.
  • the frequency at which you obtain data on the client. Do you obtain more data than what you may be able to transmit to the server ?
  • security. Do you trust clients to store data ?
  • failure policy of your system. Ex. you send all data to central DB but in the middle of the night the server db fail. Is it acceptable to lose the data generated on the client since the moment the DB failed to the moment the DB is restored ? Or, there is a network failure and client can't send data to the server, is it acceptable to lose the client data until the network is restored ?

A possible solution is an hybrid approach. Save the data on each client and put it in a transfer queue. Periodically pull the data from the queue and send it to the server and delete it from the client once the transfer is complete (wait for a server notification). If the server DB fails, you're still saving data on the client so you're not losing them. Same if network fails.

That's all I can tell you with the information you've given us.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.