Где хранить переводы в облачных приложениях?

В настоящее время я создаю приложение для архитектуры, работающей в облаке Amazon (некоторые веб-серверы с php5.3, балансировка нагрузки, PostgreSQL).

Ключевой особенностью моего приложения (PHP5) является то, что все (во внешнем интерфейсе) должно быть переведено на разные языки, поэтому будет много строк, которые представлены «токеном», которые необходимо перевести.

У меня вопрос: где бы вы хранили эти переводы?

  • Хранить переводы в файлах на локальных (серверных) дисках?
  • Хранить переводы в файлах в центральном хранилище?
  • Хранить переводы в базе данных?
  • В другом месте?

Дополнительная информация: независимо от того, где будут храниться переводы - будет некоторое кеширование (Redis, + кеш шаблона), поэтому файлы / БД не будут запрашиваться на каждой отображаемой странице.

У каждого из вышеперечисленных решений есть свои плюсы и минусы, и после долгих обсуждений в моей команде мы не нашли решения, которым все были бы довольны.

Некоторые из наших мыслей:

  • Файлы легче поддерживать (обновляйте переводы путем перезаписи файлов)
  • Таблицы DB более гибкие (создайте удобный интерфейс перевода на основе данных перевода)
  • DB-таблицы хранятся только один раз; так что это дешевле, чем много файлов в облаке, я думаю (мы платим за хранение и передачу данных)
  • Центральное хранилище файлов может быть узким местом

Итак, что вы думаете?

Привет, Роберт


postgresql php cloud translation php-5.3
person S38    schedule 07.07.2011    source источник
comment
Вы всегда можете создать интерфейс, который обновляет файлы. Есть ли какие-либо затраты на хранение файлов на веб-серверах (а не на EBS)? Возможно, у него может быть механизм, аналогичный развертыванию кода.   -  person Sukumar    schedule 08.07.2011
comment
Было бы полезно знать, где и как ваше приложение хранит непереведенные тексты. Являются ли они динамическим контентом в базе данных (тогда кажется разумным хранить там и переводы), или это статический контент, хранящийся в (исходных) файлах, или это что-то совершенно другое?   -  person BurninLeo    schedule 09.07.2011
comment
Непереведенный текст хранится как в базе данных, так и в файлах. БД для таблиц-переводов, файлы для шаблонов. Таким образом, мы могли хранить наши переводы в БД, или в файлах, или в том и другом - бесконечное обсуждение в нашей команде ...   -  person S38    schedule 13.07.2011

Ответы (1)


arrow_upward
3
arrow_downward

Вы должны сделать и то, и другое - поддерживать главное хранилище языковых данных в базе данных, что упростит создание управляющего приложения на его основе, и создавать локальные файлы (или другой подход к локальному хранилищу) для фактического выполнения. Постоянные запросы языковых данных из базы данных - напрасная трата усилий, особенно потому, что языковые данные обычно довольно статичны.

Если вы хотите обеспечить масштабируемость, вы должны использовать как минимум три уровня:

  1. Локальный (SQLite, Redis, файлы в tmpfs ...); а также

  2. Подобно облаку (например, Memcached); а также

  3. Главное хранилище (например, сервер базы данных)

Решение о том, на каком уровне хранить ваши данные, всегда должно основываться на том, откуда данные извлекаются наиболее эффективным способом:

  1. Статические или де-факто статические данные (= язык, конфигурация, скины ...) должны храниться локально, чтобы гарантировать максимально быстрый доступ к данным. Вам нужно будет найти способ создания и синхронизации обновленных данных на нескольких серверах (за исключением локального кеша, если вы его используете). Подходы включают: rsync, unison, репликация Redis, системы контроля версий ...

  2. Динамические, но кешируемые данные должны храниться в облачном кеше, поскольку предполагается, что они часто перестраиваются и поэтому могут использовать преимущества прироста производительности, получаемые от совместного использования встроенных данных.

  3. Доступ к базе данных должен осуществляться только тогда, когда вы не можете этого избежать (например, устаревший кеш)

Я бы не стал особо беспокоиться о стоимости доступа к вводу-выводу. Масштабирование сервера базы данных или необходимость переархивировать промежуточный проект будет намного дороже, чем ввод-вывод. И если вас это беспокоит, найдите решение для локального хранилища, которое в основном полагается на оперативную память, и вы можете полностью избежать чтения с диска и получить еще один прирост производительности.

person Salieri    schedule 15.07.2011