Масштаб сейчас или позже? - PullRequest
9 голосов
/ 12 марта 2011

Я хочу начать разработку относительно простого веб-приложения, которое будет извлекать данные из различных источников и нормализовать их. Пользователь также может вводить данные непосредственно на сайт. Я ожидаю удара по шкале, если получится. Стоит ли сейчас уделять время использованию масштабируемых или распределенных технологий или просто начинать со стека LAMP? Рамочная или нет? Любые мысли, предложения или комментарии помогут.

Не обращая внимания на мое смутное описание идеи, я хотел бы поделиться, как только я продвинусь дальше.

Ответы [ 5 ]

8 голосов
/ 12 марта 2011

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

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

Кстати, если вы хотите написать свой собственный фреймворк, помните, что это много работы. У моей компании есть собственная компания, которой мы очень гордимся, но на ее взросление ушло 3-4 года.

6 голосов
/ 12 марта 2011

Стоит ли сейчас уделять время использованию масштабируемых или распределенных технологий или просто начинать со стека LAMP?

Стек LAMP является масштабируемым. Apache предоставляет много, много альтернатив.

рамки или нет?

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

Сконцентрируйтесь на том, что важно: Получите что-нибудь для работы.

Если у вас нет чего-то, что работает, масштабируемость не имеет значения, не так ли?

Тогда читайте об оптимизации. http://c2.com/cgi/wiki?RulesOfOptimization очень полезно.

Правило 1. Не надо.

Правило 2. Пока нет.

Правило 3. Профиль перед оптимизацией.

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

Не предполагай. Мера.

Это значит создать что-то, что люди на самом деле используют. Масштаб прибывает позже.

3 голосов
/ 12 марта 2011

Абсолютно сделай это позже.Проблемы с масштабированием - это хорошая проблема, это означает, что людям нравится ваш проект настолько, что они подчеркивают аппаратное обеспечение, на котором он работает.

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

Когда я поднялся на борт, они начали выходить за пределы своей нынешней потенциальной масштабируемости, и , когда - это когдаони решили начать изучать CDN, методы кэширования lighttpd и другие способы очистки кода и обеспечения более плавной работы в условиях большой нагрузки.Я больше на них не работаю, но это был хороший опыт по расширению архитектуры за пределы того, на что она была изначально рассчитана.

Я могу сказать вам прямо сейчас, пытались ли они выполнить масштабируемость и оптимизацию перед продажейконтент и создание сайта вживую - они бы никогда не выросли до того размера, который есть сейчас.Компания www.beatport.com, если вам интересно, о ком я говорю (повторюсь, я не пытаюсь рекламировать их, так как больше не связан с ними, но это хороший примеручитесь, и людям будет легче понять, о чем я говорю, когда они увидят свой веб-сайт).

Лично, после работы с Ruby и Rails (и понимания разделения!) в течение нескольких лет и имеяопыт работы с PHP в Beatport - я могу с уверенностью сказать, что никогда больше не хочу работать с PHP-кодом = p

1 голос
/ 27 сентября 2011

Забавно спросить "масштаб сейчас или позже?"и маркируйте это "рубином на рельсах".На самом деле, Ruby on Rails был создан Дэвидом Хейнемайером Ханссоном, у которого в книге есть целая глава под названием «Масштаб позже» :)) http://gettingreal.37signals.com/ch04_Scale_Later.php

0 голосов
/ 13 марта 2011

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

Как менеджер по продукту Berkeley DB , я встречал множество примеров разработчиков, которые решили: «О, мы просто напишем это в простой файл» или «Я могу написать свой собственный простой B -три функции "или" База данных XYZ "достаточно хороша", мне не нужно беспокоиться о параллелизме или масштабируемости до тех пор, пока позже ". Проблема с этим подходом состоит в том, что а) вы заново изобретаете колесо (и упускаете то, что другие уже усвоили сложным путем) и б) вы игнорируете тот факт, что вам придется иметь дело с масштабируемостью в какой-то момент и идти с «достаточно хорошим» решением.

Удачи в вашей реализации.

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