Simple web photo albums put all images (a.k.a thumbnails) on an HTML page and offer to view them in larger size either on the same page (dynamic) or on a separate “slide” page (static). However, when a gallery author wants to enrich the album with advanced functions – like search or tags – using a database will be unavoidable because plain HTML pages cannot be used for storing data. Especially not for storing data in other folders.
The so-called SQL database is used the most often on the web, in tandem with an appropriate database-management software (MySQL, MongoDB, or MariaDB) running on the server. Such databases require a server that is capable of running them – you can’t simply run such services on a PC. These databases also need regular maintenance and backup, which is something most content creators would like to avoid. Therefore we chose the middle ground for jAlbum album’s lightweight services – the JSON database model (JavaScript Object Notation) – which does not require server-side database processing. Instead, the database is downloaded by the visitor’s browser, and processed by the script running behind the page.
Currently, the following skins utilize this JSON database: Tiger (default), Photoblogger, Projector, and Story.
Structure
This database is generated by jAlbum when you hit Make album. Two versions are made: one that contains all the data of all the folders (deep-data.json), the other is made up of a bare-bones tree (tree.json) and several data1.json files – folder data – distributed over the folders. This allows skins to pick the most appropriate database(s) for the chosen features.
When you run a Make album, all these databases get updated, unless you turn ON Settings / Advanced / Process only updated directories. In this case, the database will get easily corrupted over time, where the tree points to missing folders or the next folder’s links get broken. That’s why we always suggest turning this feature OFF with database-driven skins. Recreating the database on each Make isn’t as a burden as running Make on a fresh album, and generating the scaled images – which I guess is the main motivation behind turning this feature on.
When you do manual uploads, e.g. using an external FTP application, you need to pay attention to updating the root folder’s tree.json and data1.json files besides the currently updated folder. (Naturally, the /res folder also needs to be updated after every skin update, but you have to pay attention to this with non-JSON skins too.)
Size matters
While the JSON database brings simplicity, it has disadvantages too. One is you can’t go beyond a certain limit without spoiling the user experience. In an album containing 50,000 images, the JSON database could easily grow as big as 50 MB, which takes cca. 4 seconds to download on a 100 Mbit/s line. There is an overhead time too while the browser recontructs the database in the memory. That’s not ideal. This is why these JSON-based skins try to mitigate the delay by loading the full database only when the visitor starts a search. On page load, they only load the folder tree (tree.json), and the current folder’s individual database (data1.json). The only function that requires the full database is tag cloud, but the album loads it only after the page composition has finished, to avoid delay.
| Number of images | Database size / using gzip | Download @100 Mbit/s | Processing time | Delay before the first search results |
|---|---|---|---|---|
| 10.000 | 10 / 0.6 MB | 0.8 / 0.05 s | 0.5 s | 0.5–1.3 s |
| 50.000 | 50 / 3 MB | 4 / 0.26 s | 2.5 s | 3–6 s |
| 100.000 | 100 / 6 MB | 8 / 0.53 s | 5 s | 6–13 s |
| 500.000 | 500 / 30 MB | 40 / 2.6 s | 25 s | 28–65 s |
From this table you can see how important it is to turn the server’s GZIP feature on to speed up the database in huge albums. A JSON database can be compressed down to 5-6% of its original size! I’d say above some 10-20 thousand images it is essential. If you are hosting albums with us – on jalbum.net – don’t worry, you’re already covered.
If you are using the Tag Cloud feature, I’d suggest collecting tags only from the “Current folder” above some 20-30 thousand images, as collecting tags from the whole album might noticeably slow down the page load.
Although the Search function doesn’t affect all visitors, those who run a search might face longer delays on very large albums or a very slow connection. So you might want to turn off search in albums larger than, say, 200,000 images, as the results could appear only after 5-10 secs in the best case.
For the more curious
If you wonder how these databases are built up, you can install a JSON viewer browser extension – I use this for instance –, and peek into the database by appending data1.json at the end of the URL or instead of index.html. Comes in handy in case your album gets broken, and you want to check if the database looks fine. Here’s one example. (Don’t forget to install the viewer first, otherwise, it will look rather ugly. 🙂 )
Your feedback is welcome,
Laza
Leave a Reply
You must be logged in to post a comment.