4

I am currently building an application for an architecture running in the amazon cloud (some webservers w/ php5.3, load balancing, PostgreSQL).

A key feature of my (PHP5) application is, that everything (on the frontend) has to be translatable into various languages, so there will be lots of strings, which are represented by a "token", that have to be translated.

My Question ist: Where would you store these translations?

  • Store the translations in files on the local (webserver) disks?
  • Store the translations in files on a central storage?
  • Store the translations in the database?
  • Elsewhere?

Additional info: No matter where the translations will be stored - there will be some caching (Redis, + template cache), so the files / DB will not be queried on every rendered page.

Each of the above solutions has pros and cons, and after lots of discussion in my team, we did not find a solution that we all were happy with.

Some of our thoughts:

  • Files are easier to maintain (update translations via overwriting files)
  • DB-Tables are more flexible (build a nice translation interface around the translation data)
  • DB-Tables are only stored once; so this is cheaper than lots of files in the cloud, i think (we pay for storage and data transfer)
  • Central storage for the files could be a bottleneck

So what is your oppinion?

Greetings, Robert

S38
  • 1,332
  • 1
  • 8
  • 4
  • You could always build an interface that updates to files. Is there any cost involved in storing the files on the webservers (and not on EBS)? It could perhaps have a mechanism similar to code deployment. – Sukumar Jul 08 '11 at 07:49
  • 2
    It would be helpful to know where and how your application stores the untranslated texts. Are they dynmic content in a database (then it seems sensible to store the translations there, too), or is it static content stored in (source-)files, or is it something completely different? – BurninLeo Jul 09 '11 at 09:34
  • The untranslated text is stored both in db and files. DB for table-translations, files for templates. So we could store our translations in db, or files, or both - a never ending discussion in our team... – S38 Jul 13 '11 at 10:08

1 Answers1

3

You should do both - maintain a master storage of the language data in a database, which will make it easy to build management application around it, and build local files (or other local storage approach) for the actual execution. Constantly querying language data from the database is wasted effort, specifically because language data typically is pretty static.

If you want to ensure scalability, you should build on at least three layers:

  1. Local (SQLite, Redis, files in tmpfs...); and

  2. Cloud-like (e.g. Memcached); and

  3. Master storage (e.g. a database server)

The decision on which layer to store your data should always be based on from where the data is retrieved in the most efficient way:

  1. Static or de facto static data (=language, configuration, skins...) should be stored locally, to guarantee fastest possible access to the data. You will have to come up with a way for building and syncing updated data across multiple servers (save for local cache, if you are using such). Approaches include: rsync, unison, Redis replication, version control systems...

  2. Dynamic but cacheable data should live in the cloud-like cache, as the assumption is that it is often rebuilt and so can take advantage of the performance gains that come from sharing built data.

  3. Database should be only accessed when you can't avoid it (e.g. stale cache)

I wouldn't particularly worry about the IO access costs. Scaling a database server or having to do rearchitecturing mid-project will be much more expensive than the IO. And if you're worried about it, find a local storage solution that mainly relies on RAM and you can avoid the disk reads altogether and enjoy another performance gain.

Salieri
  • 782
  • 6
  • 17