In article <201005311116.48397.fmgrotep...@yahoo.co.uk>, Frans Grotepass <fmgrotep...@yahoo.co.uk> wrote:
> Hi all, Thanks for the responses. > > On Thursday 27 May 2010 15:13:50 Joseph Gwinn wrote: > > In article <201005271035.46352.fmgrotep...@yahoo.co.uk>, > > > > Frans Grotepass <fmgrotep...@yahoo.co.uk> wrote: > > > Hi all, > > > > > > Sorry for abusing my membership to this forum for this question. > > > > > > We are busy with building an embedded application that must retrieve data > > > very fast. > > > > Please define "very fast" in numbers. For example, 95% of responses must > > be fully received within 1,000 microseconds, and 100% within 10 > > milliseconds, or the planet will explode. > > This matches the specs. Blind luck wins again. This is pretty fast for access to a remote database to work well. > > What does the embedded application do? > > > SMS-routing How many subscribers? How big is the database? > > > The choice is to either have the data locally or go to a central > > > server(pool) that contains the data. > > > > Well, locally is always faster and more predictable than remotely, so why > > even consider remotely? > > The problem is that the remote db is already available and this will mean > replicating the remote db locally. The remote db has all the data in memory. > The local response time must be so fast that one needs a db solution with all > the data in memory, otherwise the disk seek time will kill us. How about local caching of the database data, as needed? What fraction of the database is used locally at a worst-case instant in time? Caching can be done in local memory, using some kind of hash code access method. Local caching may be useful even if one has a local replica of the database. By the way, unless you really do need fast access to unpredictable queries, there are better designs than relational et al. Purpose-built databases often outperform general purpose databases by a factor of a hundred in speed and in footprint. > > > In evaluating the network option, I thought that the people here could > > > possibly help me with the expected network latency for a Gb network via a > > > switch. My gut feeling says that with increased load, the switch will > > > bundle the traffic to the different nodes more and this will result in > > > higher latency. > > > > Big switches can have transit latencies of a few tens of microseconds, but > > there is far more to it than that. And if there is a choke point > > somewhere, the observed latencey will vary wildly depending on perhaps > > unrelated traffic and loading, making it appear that the latency varies > > randomly. The farther the commands and resulting data travel, the more > > vulnerable one is to these effects. > > These delays (even with local network) will make the solution impossible. > > Sorry again for posing the questions here. I know this is a blatant off topic > post, but getting the details from the internet is a little more difficult > and there are so many people here with the knowledge at hand. Thanks for the > help. You're welcome. I gather you have decided that local databases are required. Joe Gwinn _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
