One benefit of Erlang that I can see it the ease with which it supports "parallel" (multicore or distributed) computation. If tracking servers and associated datastructures can be "sharded" (partitioned) along some kind of optimized geographical boundaries then won't that be a win for most simple tracking purposes? Admittedly you won't get much obvious help for global queries but for simple things like geofencing and so on it seems like a nice solution.
Using other Erlang apps as an example (Yaws, Ejabberd, RabbitMQ), 1000 updates per server per second seems entirely reasonable, and maybe 10k/server/sec is an upper bound. Is that within the performance bounds of current real-world tracking systems? Also, I'm not sure I see the difficulty in tracking points vs lines vs polygons. Certainly time-swept data is tricky (ie keep track of the last 3 positions) but if you live in the present things like augmented R trees ( http://www.cs.purdue.edu/research/technical_reports/2005/TR%2005-020.pdf) seem adequate (although I have not tested them myself) On 10/17/07, J. Andrew Rogers <[EMAIL PROTECTED]> wrote: > > > On Oct 15, 2007, at 1:34 PM, Dave Rafkind wrote: > > I am interested in using a newly popular and hyped-up language > > called Erlang (www.erlang.org) to write a general-purpose > > distributed tracking backend, but I'm running into some difficulty > > finding a good feature set and performance profile to compare and > > benchmark against, since (as you mentioned) most systems are > > proprietary and don't release system specs :( > > > Most real-world tracking systems of the fleet and logistics kind > scale reasonably well on off-the-shelf platforms since they are not > real-time in any significant sense. The logistics field has a number > of companies that are the equivalent of "quants" in finance that > squeeze optimizations out of this data without actually owning any > real logistics assets; a tiny improvement in efficiency can mean tens > of millions of dollars of profit. The entire tool chain for tracking > is pretty competitive. > > On the other hand, some real-time tracking problems like battlespace > management and intelligence analytics do not scale as well as people > would like due in large part to traditional spatial data structures > scaling poorly at high update rates. This can be mitigated to some > extent if you limit the problem to dimensionless data (i.e. points). > > With some specs on update rate, size of data set, geometry types, > geometry distributions, etc it should be possible to come up with > rough-order-of-magnitude estimates for benchmarks. Spatial data > systems that are really "big" in some dimension tend to run up > against the limitations of the data structures, which does make them > somewhat predictable on a given piece of hardware. Like with many > things, the algorithm selection will tell you more about the scaling > behavior than the miscellaneous other optimizations and bits of > special sauce that may squeeze another 20-30% out of it. > > > Coincidentally, I have studied using Erlang in tracking back-ends as > well (and am still considering it for that purpose). It does not > solve any existing problems, but it seems well-suited to that > particular task. It would be an interesting project for Erlang, but > I do not know that it would generate a benefit an end-user would notice. > > Cheers, > > J. Andrew Rogers > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://lists.burri.to/mailman/listinfo/geowanking >
_______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
