UPD2:
Для потомков. В конечном итоге выбрал шаблоны на основе Excel. Использую github.com/vernes/PHPReport, которая есть небольшая надстройка над PHPExcel
Я понимаю вашу реакцию. Но по собственно опыту, могу предположить что в вас говорит однобокий взгляд на git. Покопавшись в нем и поняв как он работает, понимаешь что это в первую очередь фремворк для работы с распределенными данными, на котором, удобно организовывать и DVCS.
Так что очень рекомендую вам еще раз взглянуть на свою задачу, и подумать, не решается ли она проверенными временем инструментами. Меньше изобритения велосипедов — больше времени делть полезные фичи :)
Ну как бы не стороник, выискивать кто прав. С дискуссиях меня больше интересует узнать чтото новое :)
> Имхо на нормальном проекте все же сервер баз данных должен быть физически отдельным.
Наверное я и правда не очень ясно выразился. Это 110% поддерживаю. Какое то время апп сервер можно держать с СУБД на одном серваке, но как появится возможноть — лучше разнести.
Основная мысль которую я хотел донести, что очень часто лучше проапгрейдить сервер СУБД, чем делать шардинг, или хитрое дерево слейвов для чтения. Репликация в mysql ломается не так уж и сложно.
У одного большого сервер есть свои плюсы. Нет проблем рассинхронизации данных. Можно делать JOIN любых таблиц на уровне СУБД, а вытаскивать из 2-3 разных серверов и извращаться в коде приложения. Мониторить это дело проще, профилировать. Да куда не плюнь — плюсы сплошные :) А пока новый, мощный сервер дает нам фору времени — зарабатывать бабки. И на них… тадам! купить еще более мощный сервер! :) шутка.
Я хочу сказать — нужно быть готовым к тому, что бы «распылить» свои данные по разным серверам, но делать это надо, не раньше чем все остальные способы оказываются экономически невыгодными.
но если затронули тему
> новых серверов больше 4 вы не навтыкаете. там ускороение от новых серверов падает
То я скорее соглашусь, с этим утверждение в рамках этого конкретного топика. Топикастер говорил просто о репликации все базы на слейв. И при таком сценарии, N слейвов НЕ дадут N кратный прирост производительности.
С тем что, базу можно вертикально расшардить по таблицам конечно спорить не будут. часто это даже хороший вариант. Но в вопросе речь была не об этом. Я же хотел сказать, что возможно топикастеру, на текущем этапе проекта это еще и не нужно…
возьмите сервер с SAS винтам. еще лучше с SSD. 8 гигов для СУБД это не серьезно. Воткните 16 или 32. Поверьте это будет сильно лучше, чем 4 сервера с 8ГБ :)
Если вы не гугль, с огромным количеством данных, то оттягивайте шардинг данных. Он усложняет разработку, а значит сделает ее дороже. scale up в виде памяти или винта пошустре, даст вам 4-6 месяцев форы. Потратьте их на то что бы сделать сервис более юзабельным, привлеките инвестора, напишите юнит тесты. Да имхо что угодно будет для сервиса полезней, чем попытка распределить СУБД на кучу серверов раньше времени :)
Вы уверены что конфиг MySQL идеален и вытягивает все из железа? А пробовали percona server? Он будет побыстрее mysql. Если не хватает производительности, не спасет ли вас HandlerSocket? А профилирование запросов и приложения чем делали? точно ли СУБД тормоизит?
А вообще, вы точно уверены что вам пора масшатбироваться на два сервера? Мой опыт показывает, что mysql можно неплохо отюнить и дать себе еще месяц другой передышки, за которые допилить код. Пиши в личку, если что, подскажу может что.
В целом — иметь два разных конекта на уровне кода это правильный путь.
Прекрасное замечание. При удаленной работе энтропию нужно всячески уменьшать. Стандарты кодирования, постановка целей по SMART, описание архитектуры системы и важныех концепций, требования к QA писать максимально подробные багрепорты — этот тот минимум без которого будет просто хаос.
Соглашусь с коллегой. На контроль и пинание будет уходить оч много ресурсов. Для себя пришел к следующему правилу: либо доверяешь человеку в команде полностью либо просто не сотрудничаешь с ним. Все остальное — трата времени и лишняя нервотрепка.
Найти претендентов не сложно, а вот отобрать достойных — сложнее чем на работу в офисе. Вы не сможете эффективно контролировать человека на удаленке. Если он сидит на ЗП, то если захочет, вполне сможет вас обманывать. Так что нужно искать людей одновременное:
* компетентных
* фанатов своего дела
* заинтересованных в работе на этом конкретном проекте
* ну и просто порядочных
Все это конечно прописные истины, верные и для офисной работы, но при удаленке это просто маст хев.
На собеседование попытайтесь понять насколько человеку интересно заниматься своим делом. Дайте ему сложнуый, интересный таск — спроектировать архитектуру, протокол, API. Решить не тривиальную задачу (только не про количество шариков в автобусе :) Посмотрите за ходом его мыслей. Дайте ему время подумать (час, день). Нравится ли ему сам процесс решения этой задачи или это для него просто способ отхватить теплое местечко и не более?
Пообщайтесь с ним о новостях в его области, обсудите последние релизы библиотек и тд.
Честно говоря тогда не понял вашего вопроса. Если вам нужно просто готовое решение, для инкрементного бэкапа сайта, на S3, то duplicity прекрасное решение.
Если хотите создать свой ПО, для этих целей, то не совсем понял причем здесь S3. Если вы научите ваше ПО, получать diif от прошлой версии бэкапа (тут опять же стоит смотреть исходники duplicity или www.cis.upenn.edu/~bcpierce/unison/), то скинуть его на S3 это уже 1% сложности.
Видимо проблема в том, что далеко не все юзеры умеют использовать пейпал. поверьте это так, для многих QIWI это самый удобный способ оплаты. Но для топикастера видимо удобней получать деньги именно на PayPal, так что вопрос вполне имеет смысл.
В пишите приложение с миллионами хитов в час? если нет, то очень сомневаюсь что миллисекунды разницы отклика будут играть роль. 100 пудов на коннект и работу с БД времени уходит больше. MpaK999 вам верно сказал — не использовать готовый код это скорее дурной тон, чем признак профессионализма.
мой вам совет — начинайте сразу с RoR учить, не только руби выучите, но и кучу полезных приемов и практик из RoR
