В том то и дело, что не структуру БД. Подход к описанию контракта в статически типизированном виде предпочтительнее работы с моделями базы данных, это типичная практика. Например потому что ответ от базы не всегда соответствует таблицам в базе.
Во-первых правильнее будет тогда уж делать не удаление из кэша, а обновление.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
Одно из преимуществ wiki на GitHub – возможность редактировать файлы локально на компьютере, работая как с репозиторием. Так как менеджеры с терминалом работать не умеют, на помощь приходят настольные приложения для git. В частности, можно скачать GitHub for Mac. Репозиторий с wiki для проекта лежит по адресу git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс .wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.
А эти структуры никак не связаны с масштабированием. Массив служит для упрощения организации ассоциативных связей. hstore удобен для динамических атрибутов объекта. А json для кэшированных структур данных. Валидации на уровне обработчиков в приложении. Разумеется триггеры и хранимые процедуры не используем, всё концентрируется в приложении.
А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.
Раньше не писали. Возможностей ORM хватало с головой. Позже стало ещё проще – старались делать запросы попроще. Самой большой проблемой при смене базы данных была миграция сами данных. Вроде полно скриптов, которые должны облегчить жизнь, но на практике пришлось повозиться. Кроме того был момент: приостанавливать работу редакции или нет. Решили, что проще для всех, если мы на некоторое время остановим редакцию, нежели будем делать realtime репликацию-миграцию или доливать изменения.
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений where. Одна из проблем ActiveRecord. Добавим до кучи жёсткую привязку всегда иметь поле id primary key – с любой нестандартной схемой начинаются танцы. Посматривали на Sequel, но пока не решились.
Так может подробно и опишите, как упростить локальное развертывание nginx? Например неплохо бы, чтобы у нас был доступен некий app.local который частично повторяет логику production конфигурации.
А тут просто. При разработке на локальной машине, ребята запускают веб приложения через Pow. Соответственно nginx с его настройками локально нет. В production стараемся делать это средствами nginx.
Да. И с помощью nginx можно перестраховаться, если после релода приложение валится. В ситуации с одним сервером это хорошее решение. А если кластер, то лучше балансировать уровнем выше, конечно.
https://habr.com/en/articles/774274/
Было бы интересно обзорно посмотреть еще на решения в таком ключе:
Как давно компания на рынке и развивает своё решение
Где действительно есть уникальная разработка, где это красиво собранное решение
Кто какой вклад привнес в open source (вклад в проекты на базе которых собрали, публикация своего решения)
Есть ли у проектов точки пересечения, потенциал на объединение, или они "развелись" недавно.
Все это интересно именно обзорно в сравнении, а не только "в одной статье описать одно решение"(условно)
Спасибо за труд, может получиться интересное исследование.
Можно.
Не принципиально.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс.wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений
where. Одна из проблем ActiveRecord. Добавим до кучи жёсткую привязку всегда иметь полеid primary key– с любой нестандартной схемой начинаются танцы. Посматривали на Sequel, но пока не решились.