Разное

Ага, только похитрее, поддерживает коллекции (плюс по сравнению с memcached поддерживает репликацию и сохранение на диск с последующим считыванием при старте, а может не работать с диском). Фактически да, это только для кэша, возможно чуть более интеллектуального.

>Получается, что какой-то адаптер писать придётся в обоих случаях?
Ага, но мне кажется в моем случае не удастся сделать вид, что проблемы не существует... хотя многим пожалуй это удается.

Redis же это вроде бы банальное key/value хранилище типа мемкеша. Нет?

>> и на плечи приложения ложиться определение, что перед ним, старый или новый формат
>> и требуется работа по конвертации в новый формат.

Получается, что какой-то адаптер писать придётся в обоих случаях?

>А какую nosql базу предпочитаете тогда?
redis

Mongo позволяет с легкостью хранить любые объекты, в том числе старого формата, отличающегося от нового и на плечи приложения ложиться определение, что перед ним, старый или новый формат. В СУБД такой номер, как правило, не прокатывает и требуется работа по конвертации в новый формат.

Удалить, создал вместо этого ответа отдельную тему Старожилы форума.

А какую nosql базу предпочитаете тогда?

>> мне их свободный подход к проектированию схемы не очень нравится.

Вообще mongo используется для хранения готовых объектов, для которых какая-то жёсткая структура не сильно то и нужна. Особенно хорошо получается хранить какие-то нечёткие структуры данных, в которых количество полей может сильно варьироваться и поэтому классическая реляционная таблица получается сильно раздута.

Например одна из задач которую у меня успешно выполняет mongo - хранение сырых данных после парсинга. Т.е. робот парсит какой-то источник и сваливает сущности в коллекцию, не особо заботясь о их структуре. А потом другой скрипт уже извлекает их, индексирует и аккуратно раскладывает по таблицам реляционной базы. Получается быстро и удобно.

Так же mongo отлично с кеширующей денормализацией баз справляется, когда пять джойнов заменяются одним запросом коллекции сохранённых объектов. Тут тоже не особо какая-то продуманная структура требуется.

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

>> Есть гем octopus - по-моему отлично справляется, недавно строил сервис по слиянию 4-х реплик баз данных в одну

Спасибо, действительно удобно делать шардинг реляционных баз.

А mongo туда можно воткнуть? Встречались с такой задачей?

Со всем согласен :)

кроме "Без танцев с бубном трудно настроить работу с более чем одной базой данных"
Есть гем octopus - по-моему отлично справляется, недавно строил сервис по слиянию 4-х реплик баз данных в одну - только со sphinx-ом возникли проблемы, решились одной строчкой кода.

>Ну у вас там наверное куча автоматических тестов и создания тестовых песочниц под каждый билд?
Есть такое дело

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

>> На рельсах написаны многие крупные проекты, просто на PHP у вас наверное опыт больше

Скорее были написаны :) Как раз потому что быстро по времени, а деньги на кучу серверов не проблема в условиях западных стартапов.

Тот же twitter когда стал реально популярным был переписан. На scala вроде.
Насчёт гитхаба не уверен, но тоже вроде бы там от рельсов мало что осталось.
Basecamp вроде держится пока на ROR, но скорее всего из-за того, что там собственно автор рельсов и заправляет.
Ну и т.д. Как только проект становится очень большим - рельсы становятся неоправданно дорогими в плане накладных расходов. И если тот же php можно разогнать используя костыли типа HHVM, то для ruby ничего такого нет, насколько я знаю.

Ну и плюс сама архитектура фреймворка не сильно располагает к разработке крупных проектов. Например актив рекордс сильно проигрывает в плане гибкости той же доктрине. Глобальная MVC архитектура не всегда удобна - трудно без создания своего гема "окуклить" сущности в рамках логического раздела (см. бандлы в symfony). Без танцев с бубном трудно настроить работу с более чем одной базой данных, не говоря уж о том, чтобы одновременно работать с реляционной и nosql (mongodb я так и не понял как подружить с mysql в рамках одного проекта). Ну и т.д.

>> Сегодня завершил описание развертывания одного портала (3 сервера + git-сервер + деплой; 4 рельсы + 3 капистрано): 40 страниц.

Ну у вас там наверное куча автоматических тестов и создания тестовых песочниц под каждый билд?

Про трудности деплоя я писал в сравнении с лёгкостью этого дела в PHP. На начальном этапе. Купил хостинг - по ftp или rsyncом по ssh копируешь файлы в public_html в и всё работает. А в рельсах без хороших знаний линукса просто не обойдёшься. Тут просто копировать не получится. Даже на "hello world" проекте :)

В рельсах порог входа сильно повыше будет.

>Очень большой проект я по-прежнему пилю на symfony, так как он лучше заточен под огромные вещи. Но
>средние проекты и прототипы я теперь пишу только на рельсах.
На рельсах написаны многие крупные проекты, просто на PHP у вас наверное опыт больше.

PS Сегодня завершил описание развертывания одного портала (3 сервера + git-сервер + деплой; 4 рельсы + 3 капистрано): 40 страниц. На самом деле это особенность крупных порталов, тот же деплой из под ant или puppet он ведь тоже не проще... а когда у вас десятки или не дай бог сотни серверов - вы обычным копированием не обойдетесь. Собственно деплой - это и есть признак средних и крупных проектов.