Hi all, 
sorry for the cross posting.

We would like to add MBTiles support to GWC. 
Follows a description of the work with the main issues\limitations.

I would like to have community feedback on this, by the way is there a better 
way to propose this work ?

* MBtiles and SQLitle *

MBtiles is a specification that describe how to store tiles in an SQLite 
database, this will allow us to store many tiles in a single SQLite
file avoiding us file systems headaches: 
https://github.com/mapbox/mbtiles-spec/blob/master/1.1/spec.md.

We can rely on GeoTools gt-mbtiles module for reading and writing MBTiles, this 
way most of the work of implementing this blobstore will be
managing SQLite connections and SQLite files.

SQLite files cannot be managed as simple files. When connections to an SQLite 
database are open we should not delete, move or switch the
associated file. Databases files can be filled with "empty space" after 
deleting an huge amount of data or can become fragmented after
frequent inserts, updates or delete operations. 

SQLite documentation warns us against putting databases files on a shared file 
system if multiple process need access to it (which is our
case). Unless we can rely on a distributed lock mechanism SQLite databases 
files should not be used with shared stores.

* VACUUM and DiskQuota *

To remove the fragmented space (or the empty space), the VACUUM command needs 
to be executed. Although, performing a VACUUM command as a few
drawbacks:

    - During a VACUUM twice the size of the original database file is required 
in disk.
    - During the VACUUM operation no access to the database is allowed.
    - The VACUUM operation copies the whole database which can take minutes.

For these reasons the VACUUM command cannot  be performed after each operation. 
When possible we will avoid creating fragmented space. For
example, during a truncate operation we may prefer remove a whole SQLilte file 
instead of deleting part of is content. Another consequence
of the fragmented space is that DiskQuota will not be compatible with this 
blobstore.

* MBTiles Granularity *

Reading and writing tiles on an SQLite database will be slower than writing on 
a file system but will allow us to avoid file system
headaches. In order to limit the amount of contention on each single MBTiles 
file we will allow users to decide the granularity of the files
so that instead of having a single file for each single layer we will allow 
users to have more granularity.

MBTiles force us to have at least a file per layer and format. If we want to 
support more CRSs we will also need a file for each CRSs. By
configuration it will be possible to configure the granularity  of the database 
files. By default we will have a granularity per layer, crs,
format and zoom level. As an instance something like this could be offered:

    <blobstore>
       <file>/path/to/{grid}/{dim}/{tileset}/{z}/{x}-{y}.sqlite</file>
       <xcount>1000</xcount>
       <ycount>1000</ycount>
    </blobstore>

In this case we should include the {x}, {y} and {z} replacements in the 
template determining the file to use. In the previous example, tile
(z,x,y)=(15,3024,1534) would be stored in a file named 
/path/to/g/mytileset/15/3000-1000.sqlite3 and tile (5,2,8) would be stored in a 
file
named /path/to/g/mytileset/5/0-0.sqlite3.

With more databases files we have more performance but we will have also more 
files to manage on the file system. In addition we can couple
this with the in-memory cache in order to improve tile serving performance.

* Connection Pooling and Performance *

SQLite allow multiple readers but only allow one writer at the time which will 
block the entire database. At most only one connection should
be open to each SQLite database, the total number of open connections is 
limited by the number of open files allowed by the OS (in linux
this is controlled by the ulimit). A connection pool that will control the 
number of open connections and that will be responsible to manage
the connections will be implemented.

* Replace Operation *

As said before, if the cache is running we cannot simply switch SQLite files, 
we need to make sure that all connections are closed. A
replace operation will be created for this propose. The replace operation will 
first copy the new file side by side the old one, then block
the requests to the old file, tear down the store, delete the old one, rename 
the new file to current one, reopen the new db file and start
serving requests again. Should be almost instant. A REST entry point for this 
operation will be created (with the possibility to send the
new file with the request).

Regards,

-- 
==
GeoServer Professional Services from the experts! 
Visit http://goo.gl/it488V for more information.
==
Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:   +39 0584 1660272
mob:   +39  333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i 
file/s allegato/i sono
da considerarsi strettamente riservate. Il loro utilizzo è consentito 
esclusivamente al destinatario del messaggio, per le finalità indicate
nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il 
destinatario, Vi preghiamo cortesemente di darcene notizia via e
-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal 
Vostro sistema. Conservare il messaggio stesso, divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per 
finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the 
attention and use of
the named addressee(s) and may be confidential or proprietary in nature or 
covered by the provisions of privacy act (Legislative Decree
June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord 
with its purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or partial, is strictly 
forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact immediately 
the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender does 
not give any warranty or accept liability as the content,
accuracy or completeness of sent messages and accepts no responsibility  for 
changes made after they were sent or for other risks which
arise as a result of e-mail transmission, viruses, etc.


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to