Загрузка изображений через PHP в SVN и хранение метаданных в нескольких базах данных

Question

В настоящее время мы разрабатываем переписать наш сайт PHP. Новая версия будет находиться под контролем версий SVN и будет иметь отдельную базу данных для сайтов разработки и живых сайтов.

В настоящее время у нас есть около 200 000 изображений на сайте, и мы добавляем около 5-10 в месяц. Мы хотели бы иметь эти изображения под SVN.

Текущий план состоит в том, чтобы хранить и обслуживать изображения из файловой системы, одновременно обслуживая их метаданные из базы данных. Изображения будут обрабатываться через систему обработки изображений PHP с правилами перезаписи Apache, чтобы http://host/image/ImageID получал доступ к сценарию PHP, который запрашивает базу данных для изображения с указанным идентификатором и (на основе столбца path в таблице) возвращает соответствующее изображение.

У меня проблема с синхронизацией файлов изображений и их метаданных между живыми сайтами и сайтами разработки.

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

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

Одним из жизнеспособных решений, которое мне удалось найти, является то, что наш скрипт загрузки PHP фиксирует новые изображения в SVN и отправляет запросы INSERT в оперативные базы данных и базы данных разработки. Но мне это кажется неэффективным. Плюс поддержка SVN в PHP все еще экспериментальна, и мне не нравится полагаться на вызовы exec ().

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

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

Каков наилучший способ обработки сценариев такого типа?

Answer 1

Лучший способ справиться с этим - использовать отдельный процесс для синхронизации ваших изображений и метаданных между live и dev. Для файлов изображений вы можете использовать bash-скрипт, запущенный из cron, для выполнения «svn add» и «svn commit» для любых изображений, загруженных в вашу среду. Затем вы можете периодически запускать «svn up» в вашей среде dev, чтобы убедиться, что dev имеет последний набор. Репликация Mysql была бы лучшим способом обеспечить синхронизацию баз данных live и dev с учетом вашего набора данных. Это решение предполагает две вещи: 1) Данные передаются в одном направлении, от prod к dev, а не наоборот. 2) Ваши пользователи могут терпеть небольшую степень задержки (количество времени, в течение которого live и dev будут не синхронизированы). Величина задержки будет прямо пропорциональна количеству данных, загруженных в продукт. С учетом 5-10 изображений, добавляемых в месяц, задержка должна быть бесконечно мала.

Answer 2

Если у вас уже есть решение для переноса данных из dev в prod для ваших баз данных, почему бы не сохранить фактические изображения в виде больших двоичных объектов в БД вместе с метаданными?

Когда изображения запрашиваются, вы можете иметь сценарий, записывающий их в плоские файлы на сервере (или использовать что-то вроде mem_cache, чтобы упростить обслуживание общих изображений) в первый раз, а затем обрабатывать их как файлы после слов (делать проверку file_exists() или подобное).Пусть ваш скрипт mod_rewrite обрабатывает поиск в БД.Таким образом, вы получите преимущество от того, что большинство ваших пользователей получают доступ к «плоским» файлам изображений, обрабатываемым вашим сценарием mod_rewrite, и все синхронизируется с различными БД.Недостатком является то, что ваши базы данных становятся большими.

Answer 3

Мне пришлось решить такую ​​проблему для ряда различных сред. Вот некоторые из техник, которые я использовал; какая-то комбинация может решить вашу проблему или, по крайней мере, дать вам правильное представление о ее решении.

Управление версиями данных приложения во время разработки

Я работал над приложением базы данных, которое должно было иметь возможность доставлять определенные данные как часть приложения. Когда мы поставили новую версию приложения, схема базы данных, вероятно, эволюционировала, поэтому нам потребовались сценарии SQL, которые либо (1) создавали бы все таблицы приложения с нуля, либо (2) обновляли все существующие таблицы для соответствия новая схема, добавить новые таблицы и удалить ненужные таблицы. Кроме того, нам нужно было доказать, что сценарии обновления будут работать независимо от того, какая версия приложения обновляется (у нас не было контроля над средой развертывания или расписаниями обновления, поэтому было возможно, что конкретному сайту может потребоваться обновить с 1.1 до 1.3, пропуская 1.2).

В данном случае я использовал инструмент, который выводил бы базу данных в виде одного большого сценария SQL, содержащего все определения таблиц и данные. Затем я написал инструмент, который разделил этот огромный скрипт на отдельные файлы (фрагменты) для каждой таблицы, хранимой процедуры, функции и т. Д. Я написал другой инструмент, который бы брал все фрагменты и создавал один SQL-скрипт. Наконец, я написал третий инструмент, который использовался во время установки, который определял, какие сценарии следует запускать во время установки, основываясь на состоянии базы данных и установленного приложения. Как только я был доволен инструментами, я запустил их для текущей базы данных, а затем отредактировал фрагменты, чтобы исключить посторонние данные, оставив только те части, которые мы хотели отправить. Затем я контролировал версии фрагментов вместе с набором дампов баз данных, представляющих базы данных из поля.

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

Во время разработки разработчики запускали инструмент установки, чтобы инициализировать (действительно обновить) свои базы данных разработки, а затем вносить свои изменения. Они запускали утилиту dump / split и фиксировали измененные фрагменты вместе со сценарием обновления, который обновлял бы любые существующие таблицы в соответствии с новой схемой. Сервер непрерывной интеграции будет проверять изменения, собирать все и запускать все модульные тесты (включая мои регрессионные тесты базы данных), а затем указывать пальцем на любого разработчика, который забыл зафиксировать все свои изменения базы данных (или соответствующий сценарий обновления). ).

Перенос данных в реальном времени на тестовый сайт

Я создаю веб-сайты, используя Wordpress (на PHP и MySQL), и мне нужно поддерживать «живые» и «тестовые» версии каждого сайта. В частности, мне часто нужно перенести все данные из «живого» в «тестовый», чтобы я мог видеть, как определенные изменения будут выглядеть с живыми данными. Данные в этом случае - это веб-страницы, загруженные изображения и метаданные изображения, а метаданные изображения хранятся в MySQL. Каждый сайт имеет полностью независимые файлы и базы данных.

Подход, который я разработал, представляет собой набор скриптов, которые делают следующее:

1. Извлечь два набора (исходный и целевой) учетных данных базы данных и расположений файлов из данных конфигурации.
2. Загрузите файлы для исходного сайта.
3. Сотрите область файла для целевого сайта.
4. Распакуйте файлы в целевую файловую область.
5. Создать дамп таблиц для исходной базы данных в файл.
6. Удалить все данные из соответствующих таблиц в целевой базе данных.
7. Загрузить данные таблицы из файла дампа.
8. Выполнение SQL-запросов для исправления любых исходных имен файлов, соответствующих целевой области файла.

Одни и те же сценарии могут использоваться в двух направлениях, чтобы их можно было использовать для извлечения данных для тестирования из живого или pushсайт переходит с тестового на живое.