[Tilesathome] t at h server performance

[D Tucny]

On 24/12/2007, Martijn van Oosterhout <kleptog at gmail.com> wrote:
>
> On Dec 23, 2007 7:21 PM, D Tucny <d at tucny.com> wrote:
> > On 23/12/2007, Martijn van Oosterhout <kleptog at gmail.com> wrote:
> > > The whole point of the exercise is to not store all those. Doesn't
> > > really matter how, just need to find a way.
> >
> >  With 18 zoom levels (0-17) and a single layer, we get a total of approx
> 23
> > billion tiles... If all we are going to store all of them as land or
> sea,
> > the most efficient (storage wise, not speed wise and ignoring
> compression)
> > way we could store them would be a single set of sequential bits, that
> would
> > come out as about 2.7GiB...
>
> You need at least three states, (LAND/SEA/TILE) so I'd suggest you
> look at the code supporting the oceantiles_12.dat file which does
> exactly this. Not everybody likes it though. An SQL table has the huge
> advantage of being easily accessable with standard tools...


Do we need the 'tile' state? This is fall back, if a tile is marked as land
or sea, but we serve a tile from the filesystem, it makes no difference...
Having a third state doubles our storage requirements...
We do need the ability to support every zoom level I guess though, the data
required for up to zoom 17 is 1024x the amount needed for up to zoom 12 or
1365x zoom 12 only which mixes things up a little...
Advantages and disadvantages with any approach... Right now the disadvantage
we're talking about is that an SQL tables can't keep up with the growth of
the data, so, the advantage of a single SQL table being easier to use is
soon going to be outweighed by the disadvantage of the failing
performance...

d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071224/7c25ba4c/attachment.html>