Где хранить переводы в облачных приложениях? - PullRequest
4 голосов
/ 07 июля 2011

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

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

Мой вопрос: где вы будете хранить эти переводы?

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

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

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

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

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

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

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

1 Ответ

3 голосов
/ 15 июля 2011

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

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

  1. Local ( SQLite , Redis , файлы в tmpfs ...); и

  2. Облакообразный (например, Memcached ); и

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...