Author |
Topic: Single variable database (Read 1458 times) |
|
mistaken_id
Junior Member
Posts: 132
|
 |
Single variable database
« on: Mar 27th, 2010, 2:23pm » |
 Quote  Modify
|
Suppose there is a server which holds an integer. The purpose of this server is to increment the value of the integer and return the value of integer whenever it receives a request from a client. Suppose there are millions of clients accessing this database. How do you scale it.
|
|
 IP Logged |
|
|
|
towr
wu::riddles Moderator
Uberpuzzler
Some people are average, some are just mean.
Gender: 
Posts: 13730
|
|
Re: Single variable database
« Reply #1 on: Mar 27th, 2010, 3:29pm » |
Quote Modify
|
I don't really understand the problem. What is there to scale?
|
|
IP Logged |
Wikipedia, Google, Mathworld, Integer sequence DB
|
|
|
mistaken_id
Junior Member
Posts: 132
|
|
Re: Single variable database
« Reply #2 on: Mar 27th, 2010, 6:00pm » |
Quote Modify
|
Single database is a bottleneck here. How do solve this. If you have a single database, you cannot server 1 million concurrent requests... How do you solve the problem so that you can sever maximum number of concurrent requests
|
|
IP Logged |
|
|
|
Obob
Senior Riddler
Gender:
Posts: 489
|
|
Re: Single variable database
« Reply #3 on: Mar 27th, 2010, 7:46pm » |
Quote Modify
|
I don't see how using more than a single computer could possibly make things faster.
|
|
IP Logged |
|
|
|
kaka
Newbie
Gender:
Posts: 24
|
|
Re: Single variable database
« Reply #4 on: Mar 27th, 2010, 8:49pm » |
Quote Modify
|
since a server cant handle so many requests, we can have multiple servers queuing them and passing to main server holding the variable.Again we can have multiple levels, if those level 2 servers are also cluttered.
If we strictly want to serve the requests in their order of arrival, we can have a time stamp attached to each request, and reduce the problem to sorting m sorted arrays. A min heap is maintained at server, it gets minimum from all 2nd level servers, serve the request for the top node (say this is from server x), then get the min from server x and insert into heap and repeat the same.
|
|
IP Logged |
|
|
|
diptendubhowmick
Newbie
Posts: 11
|
|
Re: Single variable database
« Reply #5 on: Mar 31st, 2010, 2:29am » |
Quote Modify
|
I think keeping multilevel servers for building the queue will not solve the main problem because we have only one server to increment the variable. So the queue will become longer and longer every minute.
So my suggestion is: If the secondary servers (used to build queues) also have the same computation power as the main server, we should use just one server for making queue and another for incrementing the variable.
|
|
IP Logged |
|
|
|
kaka
Newbie
Gender:
Posts: 24
|
|
Re: Single variable database
« Reply #6 on: Mar 31st, 2010, 7:44am » |
Quote Modify
|
yes, if you just want to return incremented count on every hit.but no, if you want some synchronization
|
|
IP Logged |
|
|
|
sk
Newbie
Posts: 45
|
|
Re: Single variable database
« Reply #7 on: Mar 21st, 2011, 10:02pm » |
Quote Modify
|
have a range of integers for a server that they can increment without any race conditions. e.g. server 1 can allocate from 1-1000, server 2 2-2000 and only when they run out of it, they request for a new chunk. this way u redcue race conditions considerably.
|
|
IP Logged |
|
|
|
Grimbal
wu::riddles Moderator
Uberpuzzler
Gender:
Posts: 7527
|
|
Re: Single variable database
« Reply #8 on: Mar 22nd, 2011, 2:11am » |
Quote Modify
|
That does not guarantee that integers are delivered in sequence. If one front-end server is underused, it could take some time to use up its allocated integers, while other servers would use up multiple chunks in the same time. You could deliver an integer that is smaller than one that was delivered a long time ago.
If the aim is to deliver unique IDs, that is fine. If the aim is to record some chronological order of events, that could be a problem.
One way to address that would be as follows:
Multiple front-end servers receive and store requests, a single back-end server distributes chunks of integers. As soon as one request is pending at a front-end server, it contacts the back-end server. During the time it takes to get the attention of the back-end server, it keeps buffering. When the back-end server is ready, the front-end server requests as many integers as it has requests pending. It then disconnects and responds to all requests.
This guarantees some chronology in the delivery. If client A receives an integer smaller than client B's, then client A requested it before client B received his.
This could be done in multiple levels if necessary.
It is when the traffic is heavy that the gain is largest, as the chunks get larger.
|
|
IP Logged |
|
|
|
|
RIDDLES SITE
WRITE MATH!
Home 
Help 
Search 
Members 
Login 
Register
Reply
Notify of replies
Send Topic
Print