php – 在云应用程序中存储翻译的位置？

我目前正在构建一个运行在亚马逊云中的架构的应用程序(一些web服务器w / PHP5.3,负载平衡,Postgresql).

我的(PHP5)应用程序的一个关键特性是,所有(在前端)必须可以翻译成各种语言,因此将有许多字符串,由“标记”表示,必须被翻译.

我的问题是：你会在哪里存储这些翻译？

>将翻译存储在本地(网络服务器)磁盘上的文件中？
>将翻译存储在中央存储的文件中？
>将翻译存储在数据库中？
>其他地方？

附加信息：无论翻译将存储在何处 – 都会有一些缓存(Redis,模板缓存),因此不会在每个呈现的页面上查询文件/ DB.

上述每个解决方案都有利有弊,经过我团队的大量讨论,我们找不到一个我们都满意的解决方案.

我们的一些想法：

>文件更易于维护(通过覆盖文件更新翻译)
> DB-Tables更灵活(围绕翻译数据构建一个很好的翻译界面)
> DB-Tables只存储一次;所以这比云中的大量文件便宜,我认为(我们支付存储和数据传输费用)
>文件的中央存储可能是一个瓶颈

那你的意见是什么？

问候,
罗伯特

解决方法:

您应该同时执行这两项操作 – 在数据库中维护语言数据的主存储,这样可以轻松地围绕它构建管理应用程序,并为实际执行构建本地文件(或其他本地存储方法).不断地从数据库查询语言数据是浪费精力,特别是因为语言数据通常是非常静态的.

如果要确保可伸缩性,则应至少构建三个层：

>本地(SQLite,Redis,tmpfs中的文件……);和
>云状(例如Memcached);和
>主存储(例如数据库服务器)

决定存储数据的层应始终基于以最有效的方式检索数据的位置：

>静态或事实上的静态数据(=语言,配置,皮肤……)应存储在本地,以保证尽可能快地访问数据.您将不得不想出一种在多个服务器上构建和同步更新数据的方法(如果您使用此类服务​​器,请保存本地缓存).方法包括：rsync,unison,Redis复制,版本控制系统……
>动态但可缓存的数据应该存在于类似云的缓存中,因为假设它经常被重建,因此可以利用共享构建数据带来的性能提升.
>只有在无法避免的情况下才能访问数据库(例如过时缓存)

我不会特别担心IO访问成本.扩展数据库服务器或不得不在项目中进行重新架构将比IO昂贵得多.如果你担心它,找到一个主要依赖于RAM的本地存储解决方案,你可以完全避免磁盘读取,并享受另一个性能提升.