+1
Disapointed too
--
via Samsung Galaxy S avec Tapatalk
Disapointed too
--
via Samsung Galaxy S avec Tapatalk
In the past it has been said that there will be zero DB changes until the infra stuff is fixed. I assume this means they were switching to a more distributed DB to get around their lock issue to help with load balancing(complete guess). Adding a toll road attribute to the segments would necessitate a DB change. The shields are presumably there already but probably not in the way they ultimately want it when it's added to the editor, so same boat.HavanaDay wrote:Why can’t toll roads be in the editor so we can start getting these mapped out.
Yeah, i certainly don't want to get back to once every 45 days map updates :/HavanaDay wrote:Two week's I would probably consider a time frame I can live with. But we have all been through those multiple weeks and months time frame as well.
You may be missing the fact that the speeds gathered from all the users are saved to the db 24/7.xteejx wrote:You're all kinda missing the point. Why is the tile and drive processing done on the same servers as the realtime stuff like routing? Anyone with a brain would know they are 2 separate things and should never touch.
2 copies of the sql database, 1 on each server zsyncing with each other, well live to static anyway. Realtime stuff carries on while the processing of drives and tiles is done on the db snapshot machine, thereby eliminating processing and memory load completely.
Basically, these things should be on separate servers, free to run simultaneously. It's really not that difficult to setup zsync on a cron job, or even to start it manually after last build.
The fact that the process has been stopped is the indication that currently, everything is ran together on the same server. What the hell?!
Sent from my GT-I9100P using Tapatalk 2
So are we assuming that historical data only updates during a tile process? or does the routing server talk to the 'edit database' to get historical information? If the latter than the ability to get historical data, and thus the routing server to perform it's duty, would be impacted during a tile rebuild. If the former, then the delays in tile processing impact historical gathering which would be a shamebgodette wrote:Yes and no. The realtime segment speed (traffic layer) is part of Live, however historical data is part of the edit database and comes from drive analysis. You can see this for yourself on any newly created segment, it will start to collect average speed data from every drive across it without being part of the Live/Routing map. So basically xteejx is still right, there's no logical reason for them to be tied together, they shouldn't even be on the same database server or datastore.
Which is the 'it' 'we' know?xteejx wrote:We're not assuming, we know that. It's been confirmed by Waze.
Sent from my GT-I9100P using Tapatalk 2
That's an assumption on your part, and may well not be correct. For example, it may well be that Waze have bought N-units of resourcing from Amazon, and then Waze choose how to use these resources. They can decide to use it all for Live stuff, or a mix of Live and Backend stuff.xteejx wrote:You're all kinda missing the point. Why is the tile and drive processing done on the same servers as the realtime stuff like routing? Anyone with a brain would know they are 2 separate things and should never touch.
The fact that the process has been stopped is the indication that currently, everything is ran together on the same server. What the hell?!
And my point was that they probably can run both concurrently - now. They just don't want to spend the extra money to buy more resource from Amazon. I.e. it's not a technical issue, it's a financial one.xteejx wrote:Either way, my point is very valid. If they were separate things it wouldn't happen. No need for assumptions, it's either separate servers or separate clusters. Both have memory and processing requirements that are pretty damn high. Should be able to run both concurrently is my point.
Re: Tile updates paused