在云应用程序中存储翻译的位置?

时间:2011-07-07 09:42:15

标签: php postgresql cloud translation php-5.3

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

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

我的问题是:您将在哪里存储这些翻译?

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

附加信息:无论翻译存储在哪里 - 都会有一些缓存(Redis,+模板缓存),因此不会在每个渲染页面上查询文件/ DB。

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

我们的一些想法:

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

那你的意见是什么?

问候, 罗伯特

1 个答案:

答案 0 :(得分:3)

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

如果你想确保可扩展性,你应该建立至少三层:

  1. SQLite中的本地(Redistmpfs文件...);以及

  2. 类似云(例如Memcached);和

  3. 主存储(例如数据库服务器)

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

    1. 静态或事实上的静态数据(=语言,配置,皮肤......)应存储在本地,以保证尽可能快地访问数据。您将不得不想出一种在多个服务器上构建和同步更新数据的方法(如果您使用此类服务​​器,请保存本地缓存)。方法包括:rsyncunison,Redis复制,版本控制系统......

    2. 动态但可缓存的数据应该存在于类似云的缓存中,因为它假设它经常被重建,因此可以利用共享构建数据带来的性能提升。

    3. 只有在无法避免的情况下才能访问数据库(例如过时缓存)

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