sure, create a single table. Put an index on the date-time column.
Create an architecture with one central db server (possibly clustered for
reliability) with a dispatcher service running on the db server. The
dispatcher will look for records that need to be handled, and will dispatch
them. That's all it does. It can load up an hour's worth of records in
memory, and then simply dispatch from memory when the time trigger is hit.
To dispatch, have the dispatcher call a web service running on an agent
system. The agent should accept the transaction async... so that the
dispatcher is not blocked while the agent does its work. You could use MSMQ
3.0 if you'd like. .NET Remoting works well too, and is fairly fast, but I
don't think it load balances very well, so you may not want to go this way.
The agent is responsible for sending the bid to the auction site, getting a
response, and informing the data server if the post was successful.
Load balance your agents. Some systems will take time to accept the bid.
That way, if you have 15,000 bids to place at exactly 9:52pm on 61 different
sites, you simply have your dispatcher call the web service of the agent,
and have the load balancer decide which of your dozens of servers will pick
up the request and attempt to update the auction site.
This configuration starts with two servers, and scales well.
If your database becomes a bottleneck, then you create two databases and you
logically partition the transactions. E.G. if you have 15,000 bids that
need to be placed between 9 and 10 pm, 7,500 would be sitting on db server
A, while 7,500 will be on db server B. This means that the ability to store
the record in a database should be abstracted in some way. (dozens of ways
to do this). I like random numbers as a good seed for this kind of thing.
Hope this helps,
--- Nick Malik
Application Systems Architect
"dee" <da********@kagi.com> wrote in message
news:3e**************************@posting.google.c om...
hi,
I considering designing a online snipe system. This where i input a
price and the application will submit the snipe at the desired time to
the site. I have been thinking about the design of the system at a
higher level view and wanted some ideas on what would be the best
design of the system in terms of performance , managability and
scallability. I was thinking of three database tables , one not very
urgent , urgent and very urgent . The very urgent would be checked
every second to submit bids, this would have less rows than the others
so would help performance. The urgent checked every 1 mins and would
move bids ending in two min or less to the urgent table. The not
urgent checked every 10 mins and moved to the urgent when ending in 20
mins ir less. I was thinking MSMQ could also be used , does any one
have any advice?
