Help for a question - Networking

upul1986

Member
Aug 9, 2012
2
0
0
In your university you are asked to come up with a social network to be used for internal communication. Using your experience of programming languages, scripting, web designing and database systems you come up with a proposal for a small scale social network using RDBMS. Your design utilizes only 2 servers (one works all the time whilst the other is idle). After going through a few evaluations you realize you've missed the most important non-functional requirement of a social network i.e. 'Scalability' What are the changes you will be making? (Hint: Think of the Network architecture and the properties of the DB you have to consider)

Thanks
 

lankanatha

Well-known member
  • Dec 8, 2008
    3,560
    212
    63
    As you are having two servers, its a waste that keeping one in idle. If the simultaneous requests for the server becomes high in time to time. It may fail to response such high number of requests and may become unresponsive.

    So as a solution we can use both servers to handle requests simultaneously so that higher scales of server load will be shared by both servers and resource usage will also be efficient. Still the back pan will be active, as one server goes down other server will still be there as a backup plan.

    The database can also be derived in same way.
     

    upul1986

    Member
    Aug 9, 2012
    2
    0
    0
    Thank you very much for giving me a helping hand as soon as possible. I understand that we can utilize both servers to balance the load and we can preserve the backup plan as well. Is there a specific reason for using RDBMS for social networking projects?

    Thanks again.
     

    lankanatha

    Well-known member
  • Dec 8, 2008
    3,560
    212
    63
    I am not sure about this answer.

    RDBMS supports multi server hosting (Load balanced) of databases in parallel servers. RDBMS is having parallel query functions to facilitate this. So if its a social networking we will have to use RDBMS.