在云应用程序中将翻译存储在哪里？
我目前正在为在亚马逊云中运行的架构构建一个应用程序（一些带有 php5.3、负载平衡、PostgreSQL 的网络服务器）。
我的（PHP5）应用程序的一个关键特征是，所有内容（在前端）都必须可翻译成各种语言，因此必须翻译大量由“令牌”表示的字符串。
我的问题是：您将在哪里存储这些翻译？
- 将翻译存储在本地（网络服务器）磁盘上的文件中？
- 将翻译存储在中央存储的文件中？
- 将翻译存储在数据库中？
- 别处？
附加信息：无论翻译将存储在哪里 - 都会有一些缓存（Redis，+模板缓存），因此不会在每个呈现的页面上查询文件/数据库。
上述每个解决方案都有优点和缺点，经过我的团队的大量讨论，我们没有找到一个我们都满意的解决方案。
我们的一些想法：
- 文件更容易维护（通过覆盖文件更新翻译）
- DB-Table 更灵活（围绕翻译数据构建一个漂亮的翻译接口）
- DB-Table 仅存储一次；所以这比云中的大量文件便宜，我认为（我们为存储和数据传输付费）
- 文件的中央存储可能是瓶颈
那么您的意见是什么？
您好， 罗伯特
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该同时执行这两项操作 - 在数据库中维护语言数据的主存储，这将使围绕它构建管理应用程序变得容易，并为实际执行构建本地文件（或其他本地存储方法）。不断地从数据库查询语言数据是浪费精力，特别是因为语言数据通常是相当静态的。
如果要确保可扩展性，您应该至少构建在三层上：
Local (SQLite, < a href="http://redis.io/" rel="nofollow">Redis，tmpfs...);和
类云（例如Memcached）；和
主存储（例如数据库服务器）
在哪一层存储数据的决定应始终基于以最有效的方式检索数据的位置：
静态或事实上的静态数据（=语言、配置、皮肤...）应存储在本地，以保证最快地访问数据。您必须想出一种方法来跨多个服务器构建和同步更新的数据（如果您正在使用本地缓存，则保存本地缓存）。方法包括：rsync、unison、Redis 复制、版本控制系统...
动态但可缓存的数据应该存在于类似云的缓存中，因为假设它经常被重建，所以可以采取利用共享构建数据带来的性能提升。
数据库应该只在你无法避免的时候访问（例如过时的缓存）
我不会特别担心 IO访问成本。扩展数据库服务器或必须在项目中期重新架构将比 IO 昂贵得多。如果您对此感到担心，请找到一个主要依赖于 RAM 的本地存储解决方案，您可以完全避免磁盘读取并享受另一个性能提升。
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:
Local (SQLite, Redis, files in tmpfs...); and
Cloud-like (e.g. Memcached); and
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:
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...
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.
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.