Comments 85
Все истины — просты =)
Особенно, когда выбираете, какую БД использовать, зачем вам использовать MongoDB, PostgreSQL, или даже MySQL? Пишите всё под SQLite. Аналогий полно.
Кстати, в этом есть доля правды, если используется ORM, то на ранних стадиях разработки лучше писать на sqlite, закинув файл с БД в SVN (или что там у вас), чем возится с миграциями. Да и для маленьких сайтиков, типа визиток, где основная часть работы с БД — это чтение, такой вариант может быть более рассудительным.
Кстати, в этом есть доля правды, если используется ORM, то на ранних стадиях разработки лучше писать на sqlite, закинув файл с БД в SVN (или что там у вас), чем возится с миграциями. Да и для маленьких сайтиков, типа визиток, где основная часть работы с БД — это чтение, такой вариант может быть более рассудительным.
На самом деле даже если сайте на SQLite, пришло 100000 пользователей и он перестал справляться с нагрузкой — вполне можно что-то изменить. А вот если 100000 пользователей не пришло, то Вам глубоко все равно какая у Вас БД.
Хотя в принципе PostgeSQL самая удобная и она же вполне подходит для масштабируемых сайтов :-)
Хотя в принципе PostgeSQL самая удобная и она же вполне подходит для масштабируемых сайтов :-)
UFO just landed and posted this here
Если мы говорим про чистый html, то думаю да…
Ответ на ваш вопрос: тем, что ФС не поддерживает синтаксис запросов (имеется в виду, хотя бы фильтрация по условиям и сортировка).
А вообще, знаю таких людей, которые часто думают, что те или иные задачи гораздо проще сделать, храня информацию в файлах. Как правило, если дальнейшие условия этих задач усложняются, переписывать приходится гораздо больше, все-равно перенося в БД, чем изначально было бы написать с БД.
Да и разве выбор в хранении данных в пользу ФС чем-то упрощает жизнь разработчикам? Что вы создали таблицу, и запросы к ней, допустим, для выполнения CRUD, что прописали весь код по открытию, удалению, соблюдению аттрибутов файлов, чтению, записи… Короче, не ахты.
Ответ на ваш вопрос: тем, что ФС не поддерживает синтаксис запросов (имеется в виду, хотя бы фильтрация по условиям и сортировка).
А вообще, знаю таких людей, которые часто думают, что те или иные задачи гораздо проще сделать, храня информацию в файлах. Как правило, если дальнейшие условия этих задач усложняются, переписывать приходится гораздо больше, все-равно перенося в БД, чем изначально было бы написать с БД.
Да и разве выбор в хранении данных в пользу ФС чем-то упрощает жизнь разработчикам? Что вы создали таблицу, и запросы к ней, допустим, для выполнения CRUD, что прописали весь код по открытию, удалению, соблюдению аттрибутов файлов, чтению, записи… Короче, не ахты.
идея понятная, но сравнение реляционных и документных бд в таком контексте неуместно.
А как вы понимаете слово «маркетинг»?
Как перевод marketing. А вообще — лично я для себя как «продвижение сайта».
Как я понимаю — это не просто продвижение сайта.
Маркетинг — это как бы философия создания, развития и продвижения сайта, его поддержки, изменения тех или иных деталей исходя из потребностей пользователей рынка и исходя из цели получения наилучшей выгоды (прибыли) как в ближайший момент так и в отдаленной перспективе,… также сюда относится формирование сопутствующих действий (цель которых см выше), таких как — подбор домена, торговая марка, схожие проекты в других сферах (издательская деятельность. ТВ) и т д…
Маркетинг — это как бы философия создания, развития и продвижения сайта, его поддержки, изменения тех или иных деталей исходя из потребностей пользователей рынка и исходя из цели получения наилучшей выгоды (прибыли) как в ближайший момент так и в отдаленной перспективе,… также сюда относится формирование сопутствующих действий (цель которых см выше), таких как — подбор домена, торговая марка, схожие проекты в других сферах (издательская деятельность. ТВ) и т д…
На моей памяти был только один проект, который умер именно он внезапной нагрузки, а не от просчетов в маркетинге: приложение для ВК «Продажа друзей». Оно было одним из первых приложений, и нагрузка увеличивалась экспоненциально каждый день. При этом, насколько я знаю, оно было сделано совершенно не масштабируемым, на базе Google App Engine, и в какой-то момент загнулось полностью под нагрузкой. С тех пор так и не ожило (потом появились другие аналоги, которые держали нагрузку лучше). Но потом рынок наполнился, и теперь о взрывных ростах можно больше не мечтать))
Так ведь Google App Engine автоматически накидывает ресурсы по мере роста нагрузок. Что-то вы не договариваете. У разработчиков не было денег поддерживать необходимые лимиты, или вышли за пресловутые 500 rps и не смогли договориться с Google'ом об увеличении?
AFAIK на базе GAE сделать не масштабируемое приложение фактически не возможно. Просто GAE так устроен внутри. Если это возможно я хотел бы услышать технические детали.
Там история была другая. Запрос обрабатывался слишком долго и GAE его часто терминировал. Так что написать что либо, что в итоге для пользователя не работает, под GAE проще.
Ну тогда это не scalability это perfomance — одно с другим вообще говоря никак не связано. GAE гарантирует что и 10 и 10000 одновременных запросов будут обрабатываться примерно одинаково медленно (или быстро — тут уже зависит от личной хитрости разработчика).
GAE на самом деле вообще очень быстрый если уже на то пошло.
GAE на самом деле вообще очень быстрый если уже на то пошло.
вот тест моего тестового проекта на GAE Java (чистая jsp без базы)
# ab -c 10 -n 1000 www.keyfy.com/
Time per request: 334 ms
Это быстро для чистой jsp страницы?
# ab -c 10 -n 1000 www.keyfy.com/
Time per request: 334 ms
Это быстро для чистой jsp страницы?
При -c 100 среднее время уже 564 мс. Так что не все так идеально в современных облачных платформах.
ну тут два момента
1. Оно идет с одного хоста, т.е. эксперимент не чист. По уму должно идти с разных хостов, а лучше с разных стран. Тогда уже идет балансировка по дата центрам и т.п.
2. Ну и понятно что вообще равномерной кривой не будет, интересно посмотреть на график 100,200,… 900 подозреваю что там что-то логарифмическое.
1. Оно идет с одного хоста, т.е. эксперимент не чист. По уму должно идти с разных хостов, а лучше с разных стран. Тогда уже идет балансировка по дата центрам и т.п.
2. Ну и понятно что вообще равномерной кривой не будет, интересно посмотреть на график 100,200,… 900 подозреваю что там что-то логарифмическое.
Повторю предыдущего комментатора — масштабируемость и скорость — разные вещи. Облака нужны для масштабируемости, это у них «в крови», а скорость зависит от выделенных и используемых ресурсов.
поправка НЕ очень быстрый, виноват — опечатка.
Ага, было такое:) Проблемы начались после того, как нагрузка превысила 200rps. Latency стала доходить до 10 секунд и соединение принудительно разрывалось. Обратившись в тех. поддержку, от разработчиков GAE я узнал, что они впервые сталкиваются с такой нагрузкой и посоветовали несколько вариантов решения проблемы. К сожалению, они не помогли, но в ходе дальнейшей переписки все-таки удалось выявить ботлнэк. Кстати, вскоре после этого они сделали отдельный раздел с советами по масштабируемости, который обязателен к прочтению всем тем, кто собирается разрабатывать высоконагруженный проект на этой платформе.
Спасибо, действительно очень интересно. Вопросы
1. Google Doc сделан на GAE (так говорят) у них то точно больше 200rps. Не понятно
2. Грустные подробности Python/Java если ява — то какой фреймворк, цикл запроса и т.п.
3. Сессия stateless/statefull?
4. Что и сколько хранили в memcache
5. Как были организованные данные в DataStore
6. Было ли пресловутое datastore contention — и если да то что за данные попадали под удар? Я пробовал прикинуть как убить GAE приложение — первое что пришло в голову — антипаттерн — «все меняют одну запись».
7. Как боролись с counters и прочими артефактами GAE
8. Можно посмотреть на какие количественные характеристики размер БД, кол-во запросов и тп. В общем то, что в биллинге фигурирует?
Действительно очень интересно — с большими приложениями сделанными на GAE я реально не сталкивался, когда делал свои прототипы для этой платформы — для себя отметил много темных мест. Теперь любопытство просто ест.
1. Google Doc сделан на GAE (так говорят) у них то точно больше 200rps. Не понятно
2. Грустные подробности Python/Java если ява — то какой фреймворк, цикл запроса и т.п.
3. Сессия stateless/statefull?
4. Что и сколько хранили в memcache
5. Как были организованные данные в DataStore
6. Было ли пресловутое datastore contention — и если да то что за данные попадали под удар? Я пробовал прикинуть как убить GAE приложение — первое что пришло в голову — антипаттерн — «все меняют одну запись».
7. Как боролись с counters и прочими артефактами GAE
8. Можно посмотреть на какие количественные характеристики размер БД, кол-во запросов и тп. В общем то, что в биллинге фигурирует?
Действительно очень интересно — с большими приложениями сделанными на GAE я реально не сталкивался, когда делал свои прототипы для этой платформы — для себя отметил много темных мест. Теперь любопытство просто ест.
Ага судя по тому что автор состоит в django framework группе — наверное таки питон :-) В принципе это не существенно. Все таки самое любопытно тут — это организация данных в store и в сессии.
1. Когда я активно изучал GAE, не слышал, чтобы docs был сделан на нем.
2. Python. Сначала django, потом родной для GAE webapp.
3. Stateless.
4. При пиковой нагрузке в memcache хранилось 0,8 — 2 млн. объектов. Каждый объект содержал данные о юзере. В каждом объекте — не более 100 байт. Впоследствие оказалось, что узкое место было именно в чтении из datastore и memcache при этом не спасал. Так что, скорее всего, размер memcache полтора года назад был не более 200 МБайт на приложение.
5. Объект в datastore хранил тоже самое, что и memcache + историю операций пользователя.
6,7. Datastore contention — это первое, что пришло на ум разработчикам GAE. В итоге пришлось использовать технику sharding и разбить каждый объект на несколько, переписав логику работы с ними. Не помогло. Как я уже говорил, узкое место было в datastore read, т.к. каждый запрос в среднем генерировал по 10-20 запросов к хранилищу. Решение проблемы заключалось в присвоении каждому объекту ключевого имени (которым было id пользователя) и чтению объектов batch запросами по этим ключевикам. Кстати, вскоре после этого они написали статью о решении этой проблемы: code.google.com/appengine/articles/scaling/minimize.html.
8. Глянул сейчас в админку GAE и не нашел способа посмотреть данные логов годичной давности. На самом деле приложение было не большим, наоборот, простейшим, но все равно проблем избежать не удалось. Сейчас размер datastore 5 gb, но вряд ли это очень интересно.
2. Python. Сначала django, потом родной для GAE webapp.
3. Stateless.
4. При пиковой нагрузке в memcache хранилось 0,8 — 2 млн. объектов. Каждый объект содержал данные о юзере. В каждом объекте — не более 100 байт. Впоследствие оказалось, что узкое место было именно в чтении из datastore и memcache при этом не спасал. Так что, скорее всего, размер memcache полтора года назад был не более 200 МБайт на приложение.
5. Объект в datastore хранил тоже самое, что и memcache + историю операций пользователя.
6,7. Datastore contention — это первое, что пришло на ум разработчикам GAE. В итоге пришлось использовать технику sharding и разбить каждый объект на несколько, переписав логику работы с ними. Не помогло. Как я уже говорил, узкое место было в datastore read, т.к. каждый запрос в среднем генерировал по 10-20 запросов к хранилищу. Решение проблемы заключалось в присвоении каждому объекту ключевого имени (которым было id пользователя) и чтению объектов batch запросами по этим ключевикам. Кстати, вскоре после этого они написали статью о решении этой проблемы: code.google.com/appengine/articles/scaling/minimize.html.
8. Глянул сейчас в админку GAE и не нашел способа посмотреть данные логов годичной давности. На самом деле приложение было не большим, наоборот, простейшим, но все равно проблем избежать не удалось. Сейчас размер datastore 5 gb, но вряд ли это очень интересно.
Сейчас быстро погуглил не нашел ничего про Google doc & GAE — не знаю почему мне так думается. Если позже встретится ссылка скажу.
#6,7 — в общем как и ожидалось — не РСУБД — мало кто умеет оптимизировать — нужен специфичный опыт и специфичные решения. Не хотите статью написать? Думаю многим было бы интересно прочитать. Действительно ценный и уникальный опыт а не «еще одна статья как оптимизировать MySQL»
#8 — 5гб — интересно. Дело в том, что база 5 гигов — это для РСУБД «маленькая» база и как правило если она спроектирована разумно, то проблем с ней не бывает. Она просто вся сидит в памяти вместе с индексами и т.п. Обращение к диску идет только на запись. (Ну оговорюсь зависит от сервера и настроек).
#6,7 — в общем как и ожидалось — не РСУБД — мало кто умеет оптимизировать — нужен специфичный опыт и специфичные решения. Не хотите статью написать? Думаю многим было бы интересно прочитать. Действительно ценный и уникальный опыт а не «еще одна статья как оптимизировать MySQL»
#8 — 5гб — интересно. Дело в том, что база 5 гигов — это для РСУБД «маленькая» база и как правило если она спроектирована разумно, то проблем с ней не бывает. Она просто вся сидит в памяти вместе с индексами и т.п. Обращение к диску идет только на запись. (Ну оговорюсь зависит от сервера и настроек).
И еще вопрос — сколько в месяц платили за хостинг? В принципе в классической архитектуре 200rps (ну понятно что сильно зависит от задачи но так в среднем) можно получить на хостинге стоимостью, ну наверное около $2000-$3000 в месяц. Скажем если взять на амазоне 4 high mem instаnce на двух БД на двух web — как раз ~$3000 получается в месяц.
High-Memory Quadruple Extra Large Instance
68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
Для IO прикрутить RAID 0 из нескольких EBS если база по структуре относительно вменяемая должно весьма быстро стрелять.
High-Memory Quadruple Extra Large Instance
68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
Для IO прикрутить RAID 0 из нескольких EBS если база по структуре относительно вменяемая должно весьма быстро стрелять.
если Ваше сервис платный.
Ваше -> Ваш
Ваше -> Ваш
Мне кажется, что все зависит от основной профессии стартапера. Маркетологи думают о привлечении пользователей и преимуществах продукта, но могут наделать кучу ошибок в технической реализации. Разработчикам легче думается о масштабируемости, чем о продвижении.
А стартапер должен быть сразу всеми специалистами в одном флаконе:) ну или лучше команда чтоб была, я считаю)
А стартапер должен быть сразу всеми специалистами в одном флаконе:) ну или лучше команда чтоб была, я считаю)
Батенька, Вам бы, прежде чем браться за переводы, правила русского языка сначала подучить. Пунктуация в топике — ну просто вырвиглаз. Неприятно читать.
Вот вам немного запятых и тире, пригодятся:
,,,,,,,,,,,,,,,,,
— — — — — — —
Вот вам немного запятых и тире, пригодятся:
,,,,,,,,,,,,,,,,,
— — — — — — —
UFO just landed and posted this here
Тут как бы одно без другого не живет… Если вы не сосредоточились на маркетинге и пиаре, то пользователей у вас не будет, и ваш стартап сдохнет. Но если вы не позаботились о масштабируемости на этапе проектирования, то ваш проект сдохнет от того, что все пользователи, которых вы завлекли продуманным маркетингом, просто не смогут пользоваться. Как это сейчас происходит с сервисом www.slideshare.net/. Вот и сервис классный, хочется им пользоваться, а вот никак… За последние 2 дня, что я был вынужден обращаться к данном сервису, 80% времени он висел + 503 error. И нафига такое счастье?
Давайте говорить так:
1) Нужен хороший маркетинг
2) Нужна грамотная масштабируемая разработка (ведь мы хотим миллионы пользователей)
3) Нужны еще прочие составляющие, которые мы можем увидеть в постах, типа этого, где кто-то будет тянуть одеяло на свой элемент.
И тогда таки будет Хабр!)))
Давайте говорить так:
1) Нужен хороший маркетинг
2) Нужна грамотная масштабируемая разработка (ведь мы хотим миллионы пользователей)
3) Нужны еще прочие составляющие, которые мы можем увидеть в постах, типа этого, где кто-то будет тянуть одеяло на свой элемент.
И тогда таки будет Хабр!)))
ИМХО между первым и вторым лежит огромный временной промежуток (чем хотелось бы стартаперу) — вот это автор и хотел донести. что нужно бороться вначле чтобы егос сокртить и потом уже переходить к шагу 2
Это уже другая история и называться она должна если Вам поперло, не сидите на месте а работайте. www.slideshare.net — видимо поперло, но к изменениями они оказались не готовы.
> Стартапы умирают из-за малого количества пользователей, ХВАТИТ думать о масштабируемости
Стартапы не то чтобы умирают, они практически и не рожадаются.
Когда разработчик станет эгоистичен на 100% и перестанет быть говно-прогеро-ботаном — тогда может быть что-то получится. А так быдро-кодеры только дрочат на своё трупаковое детище, которое не родится, что тут рассуждать…
Стартапы не то чтобы умирают, они практически и не рожадаются.
Когда разработчик станет эгоистичен на 100% и перестанет быть говно-прогеро-ботаном — тогда может быть что-то получится. А так быдро-кодеры только дрочат на своё трупаковое детище, которое не родится, что тут рассуждать…
Стартапы из-за многого умирают… Вот и ipicture сдулся, а таким удобным был — но увы, нагрузка.
Интересная статья, перевод адекватный. Были бы интересны другие переводы в тему.
Я думаю тут не всё так однозначно =) Я видел стартапы которые написаны говнокодерами на друпале на коленке, неожиданно выходили на несколько тысяч пользователей онлайн, и сервер манерно умирал… а как известно 3-4 дня лежания проекта равнозначно смерти в общем случае.
Так что я думаю одно другое не исключает, да и как программист скажу что «мытарства» с масштабируемостью не сильно замедляют разработку, если разработчик адекватный.
Да и потом, если изначально сделать проект «немасштабируемым», то у него даже не будет шанса выдержать серьезную нагрузку (если пиар удастся).
Так что я думаю одно другое не исключает, да и как программист скажу что «мытарства» с масштабируемостью не сильно замедляют разработку, если разработчик адекватный.
Да и потом, если изначально сделать проект «немасштабируемым», то у него даже не будет шанса выдержать серьезную нагрузку (если пиар удастся).
Мне кажется что тут зависит от менеджмента — если у верхнего менеджмента хватит ума это угадать и с этим справится — то все будет хорошо.
Facebook сделан на PHP но специально для него был написали компилятор :-)
lib.rus.ec — друпал, но когда пользователи повалили — был поднят десяток шлюзов-прокси и острота проблемы снялась.
Я не говорю что нельзя сделать такое такое решение которое потом в разумные сроки нельзя будет отмасштабировать. «Совершенству» нет предела, увы. Сам делал аудит приложения где ВСЯ проверка прав доступа на ЛЮБОЙ чих делалась синхронно в триггере БД MySQL. Больше трех одновременных запросов оно не держало и поскольку там было густо замешано именно на правах доступа — малой кровью переписать не получалось.
Но как правило если использовать более или менее вменяемые, комфортные решения, масштабирование до 20,000 — 40,000 пользователей в день вообще не вопрос (увы URL-ы реальных сайтов дать не могу, NDA подписывал).
Facebook сделан на PHP но специально для него был написали компилятор :-)
lib.rus.ec — друпал, но когда пользователи повалили — был поднят десяток шлюзов-прокси и острота проблемы снялась.
Я не говорю что нельзя сделать такое такое решение которое потом в разумные сроки нельзя будет отмасштабировать. «Совершенству» нет предела, увы. Сам делал аудит приложения где ВСЯ проверка прав доступа на ЛЮБОЙ чих делалась синхронно в триггере БД MySQL. Больше трех одновременных запросов оно не держало и поскольку там было густо замешано именно на правах доступа — малой кровью переписать не получалось.
Но как правило если использовать более или менее вменяемые, комфортные решения, масштабирование до 20,000 — 40,000 пользователей в день вообще не вопрос (увы URL-ы реальных сайтов дать не могу, NDA подписывал).
Вы таки намекаете что PHP не рулит?
Все-таки Facebook это единичный проект, и посмотрите сколько у него серверов… думаю, учитывая направленность, там изначально всё более-менее грамотно написали. Иначе бы денег не хватило на написание компилятора.
Все-таки Facebook это единичный проект, и посмотрите сколько у него серверов… думаю, учитывая направленность, там изначально всё более-менее грамотно написали. Иначе бы денег не хватило на написание компилятора.
Я ни на что не намекаю. Я просто говорю что если поперло, то менеджмент может довольно много чего поменять в приложении.
Случай 1: я менеджил проект где у заказчика было приложение на перле с базой 10к пользователей в день, переписали на .Net за четыре месяца три разработчика. Сейчас 30к пользователей (и в два раза меньше серверов), все морально сжались ждем окончания каникул когда еще пользователей попрет. Т.е. были бы пользователи а приложение можно и нуля переписать.
Случай 2: Приложение на Яве с не очень удачной структурой БД сделанное индусами, сейчас итерационно адаптируем его к наплыву посетителей. Не буду говорить что все ОК, но прогресс есть.
PS Если так сравнивать Java и PHP по производительности — мне кажется Ява будет быстрее, но
1. Я не готов в этом поклясться прямо сейчас
2. На самом деле чистая производительность CPU для веб приложений не то чтобы вообще не важна, но скажем так не на первом месте.
3. Тема для современного веба вообще больная — говоря без цифр в руках, рискую нарваться на град помидоров.
4. Отошлю к автору комментария на который я собственно отвечал ;-)
Случай 1: я менеджил проект где у заказчика было приложение на перле с базой 10к пользователей в день, переписали на .Net за четыре месяца три разработчика. Сейчас 30к пользователей (и в два раза меньше серверов), все морально сжались ждем окончания каникул когда еще пользователей попрет. Т.е. были бы пользователи а приложение можно и нуля переписать.
Случай 2: Приложение на Яве с не очень удачной структурой БД сделанное индусами, сейчас итерационно адаптируем его к наплыву посетителей. Не буду говорить что все ОК, но прогресс есть.
PS Если так сравнивать Java и PHP по производительности — мне кажется Ява будет быстрее, но
1. Я не готов в этом поклясться прямо сейчас
2. На самом деле чистая производительность CPU для веб приложений не то чтобы вообще не важна, но скажем так не на первом месте.
3. Тема для современного веба вообще больная — говоря без цифр в руках, рискую нарваться на град помидоров.
4. Отошлю к автору комментария на который я собственно отвечал ;-)
Растущая популярность — доказанная инвестиционная привлекательность. А значит деньги на пересмотр архитектуры и прочие вещи легко найдутся.
Только в этот момент проект ляжет, и как грибы после дождя вырастут клоны.
Да прям в момент. Если по общему поведению пользователей видно, как стартап растет по экспоненте, хотя бы месяц у него есть.
Конечно, если вообще не анализировать показатели, можно что угодно прохлопать.
Конечно, если вообще не анализировать показатели, можно что угодно прохлопать.
Есть куча случаев когда рост был за сутки с тысячи до десятков и сотен тысяч. Ведь есть вирусное распространение в Twitter, ICQ, всякие хабраэффекты, блоги, копипасты блогов…
Я уж не говорю о том что будет с проектом если о нем скажут в New York Times или покажут по CNN.
Я уж не говорю о том что будет с проектом если о нем скажут в New York Times или покажут по CNN.
Согласен, такое возможно, но скажем так десятки тысяч стартапов не показывают по CNN. Т.е. серьезно на это рассчитывать не вполне разумно.
Если стоит выбор потратить $100,000 на масштабируемость или на привлечение клиентов — решайте сами.
Можно рассуждать так:
«Давайте вложим кучу денег в масштабируемое решение, а не в удобство пользователей (см о чем говорится в статье), а то вдруг нас покажут по CNN и к нам придет миллион пользователей, мы будем не готовы и проект умрет. Ни к чем тратить эти деньги на юзабилити и устранение багов — после репортажа по CNN пользователи и так придут.»
В общем это вопрос — что вероятнее?
Если стоит выбор потратить $100,000 на масштабируемость или на привлечение клиентов — решайте сами.
Можно рассуждать так:
«Давайте вложим кучу денег в масштабируемое решение, а не в удобство пользователей (см о чем говорится в статье), а то вдруг нас покажут по CNN и к нам придет миллион пользователей, мы будем не готовы и проект умрет. Ни к чем тратить эти деньги на юзабилити и устранение багов — после репортажа по CNN пользователи и так придут.»
В общем это вопрос — что вероятнее?
Извините, но $ 100,000 на масштабируемость — бред. Достаточно нанять адекватного программиста, который будет писать используя популярные решения вроде MongoDB, HiveExt, распределенный PostgreSQL… Надо писать такие системы, куда можно легко добавить серверов и она сама расползется на них. Иначе система не стоит и ломанного гроша.
Согласен, возможно, на проектирование масштабируемой системы уйдет _чуть-чуть_ больше времени, однако это не принципиально.
Для меня ответ очевиден. Вероятнее всего — вы ошибаетесь относительно кучи денег на масштабирование, и в том что противопоставляете это удобству пользователя.
Согласен, возможно, на проектирование масштабируемой системы уйдет _чуть-чуть_ больше времени, однако это не принципиально.
Для меня ответ очевиден. Вероятнее всего — вы ошибаетесь относительно кучи денег на масштабирование, и в том что противопоставляете это удобству пользователя.
$100,000 на масштабируемость ни разу не бред в вполне реальная ситуация. Я не противопоставляю масштабируемость удобству пользования. Просто бюджет один и его можно пустить либо туда либо сюда.
Возьмем средних размеров интернет проект это скажем команда 5 программистов + 1 QA. Пусть средний рейт будет $30 в час, считаем 100,000 / $30 / 8 часов / 6 человек / 20 дней в мес = 3,5 месяца.
Не секрет, что работа с нереляционными СУБД сложнее чем с РСУБД и просто более трудоемка, если РСУБД дает нам ACID просто из коробки, то если верить теореме CAP, если мы хотим масштабируемости то одно из C. A. P нам придется делать руками. Думаю это нормальное допущение что это займет на 50% больше времени. Т.е. при сроке проекта в 6 месяцев займет как раз +3 месяца т.е. те самые 100,000.
Предоставить доказательство цифрам увы не могу, но думаю если если тут коллеги аутсорсеры — они подтвердят примерно так оно и получается по деньгам.
«Надо писать такие системы, куда можно легко добавить серверов и она сама расползется на них. Иначе система не стоит и ломанного гроша.» я думаю многие не согласятся с Вами. Для 99% интернет приложений которыми мы пользуемся и пользуемся успешно — это не так, я не думаю что эти системы не стоят ломанного гроша.
Опять же если почитать интервью с инженерами из Facebook — "… каждый уровень прироста количества пользователей приносит новые неожиданные проблемы" т.е. не надо думать что все просто и достаточно использовать несколько сильных заклинаний типа «MongoDB, HiveExt»
Вот тут vanyanet пишет — даже на GAE было все далеко не просто. А уж там storage более чем масштабируемый, а уж на сервера оно расползается вообще помимо вашего желания.
В общем зря я это наверное пишу, технических ниндзя нельзя переубедить :-(
Возьмем средних размеров интернет проект это скажем команда 5 программистов + 1 QA. Пусть средний рейт будет $30 в час, считаем 100,000 / $30 / 8 часов / 6 человек / 20 дней в мес = 3,5 месяца.
Не секрет, что работа с нереляционными СУБД сложнее чем с РСУБД и просто более трудоемка, если РСУБД дает нам ACID просто из коробки, то если верить теореме CAP, если мы хотим масштабируемости то одно из C. A. P нам придется делать руками. Думаю это нормальное допущение что это займет на 50% больше времени. Т.е. при сроке проекта в 6 месяцев займет как раз +3 месяца т.е. те самые 100,000.
Предоставить доказательство цифрам увы не могу, но думаю если если тут коллеги аутсорсеры — они подтвердят примерно так оно и получается по деньгам.
«Надо писать такие системы, куда можно легко добавить серверов и она сама расползется на них. Иначе система не стоит и ломанного гроша.» я думаю многие не согласятся с Вами. Для 99% интернет приложений которыми мы пользуемся и пользуемся успешно — это не так, я не думаю что эти системы не стоят ломанного гроша.
Опять же если почитать интервью с инженерами из Facebook — "… каждый уровень прироста количества пользователей приносит новые неожиданные проблемы" т.е. не надо думать что все просто и достаточно использовать несколько сильных заклинаний типа «MongoDB, HiveExt»
Вот тут vanyanet пишет — даже на GAE было все далеко не просто. А уж там storage более чем масштабируемый, а уж на сервера оно расползается вообще помимо вашего желания.
В общем зря я это наверное пишу, технических ниндзя нельзя переубедить :-(
Вы описали ситуацию когда надо спустить деньги в трубу за 3 месяца. Кстати, вы еще не учли налоги, больничные всякие и т.д. Но даже если всё это опустить, 5 программистов с зарплатой по 4800 USD в месяц плюс с такой же зарплатой тестировщик… это лютый распил бабла.
Тестировщика можно нанять на удаленку баксов за 800 в месяц. Плюс один серверный программист (вроде меня) шарящий в кластеризации с зарплатой пусть даже те самые 4800 USD/мес (это много), плюс один крутой верстальщик/js-ниндзя с зарплатой порядка 2000 USD.
4800+2000+800 = 7600. Итого 22,800 за три месяца.
Тестировщика можно нанять на удаленку баксов за 800 в месяц. Плюс один серверный программист (вроде меня) шарящий в кластеризации с зарплатой пусть даже те самые 4800 USD/мес (это много), плюс один крутой верстальщик/js-ниндзя с зарплатой порядка 2000 USD.
4800+2000+800 = 7600. Итого 22,800 за три месяца.
P.S. это я описал по максимуму, можно нанять людей и подешевле.
Вы опираетесь на личный опыт говоря о цифрах, найме удаленного QA и т.п.? Если есть позитивный опыт — было бы интересно Вас нанять в качестве менеджера, похоже есть возможность серьезно сэкономить.
Конечно. К сожалению (или к счастью), я программист, а не менеджер по подбору персонала, и к не питаю к этому занятию никакого интереса. Однако, это вовсе несложно, есть полно людей которые неплохо шарят в Интернет-технологиях (на уровне продвинутого пользователя) и готовы продать несколько часов свободного времени в день за вполне вменяемые и скромные деньги. Россия большая.
Ниндзя, сколько раз вас показывали на CNN в этом году?
+1. У нас только через два года начались заморочки по поводу масштабирования. Правда тут такое дело, мы не сильно на него оглядывались поначалу, поэтому было сложнее. Не стоит делать код, который будет поддерживать миллионы пользователей в первый же день, но стоит подумать об этом, чтобы было меньше заморочек в будущем.
я лично не гонюсь за аудиторией
закладываю сразу масштабируемость в проект, что увеличивает цикл разработки, но зато все работает как часы и постепенно развивается
стартап подразумевает же ыстрый старт и отбивание бабла, а что потом? вот тут и кто в лес кто подрова
проект нужно холить и лелеять с учетом мнения пользователей конечно и будет счастье
я никогда не гнался за большой аудиторией, предпочитаю медленно но без потерь :)
закладываю сразу масштабируемость в проект, что увеличивает цикл разработки, но зато все работает как часы и постепенно развивается
стартап подразумевает же ыстрый старт и отбивание бабла, а что потом? вот тут и кто в лес кто подрова
проект нужно холить и лелеять с учетом мнения пользователей конечно и будет счастье
я никогда не гнался за большой аудиторией, предпочитаю медленно но без потерь :)
Тут надо понимать что как правило в реалистичной бизнес модели т.е. когда деньги приходят от инвесторов у которых зелень не растет на грядке, «отбивание бабла» есть признак того что деньги вложены удачно и можно вложить еще. Если девелопер говорит "… отбивание бабла, а что потом?" это может встретить категорическое непонимание человека который на Вас поставил и таки да, хочет отбить свое бабло.
Понятно что можно сказать — щаз пока бабла не будет зато потом будет просто немеряно. Но это работает на ограниченном промежутке времени и будем честны сами собой — если бабла нет довольно долго — есть хорошие шанс что и не будет.
Понятно что можно сказать — щаз пока бабла не будет зато потом будет просто немеряно. Но это работает на ограниченном промежутке времени и будем честны сами собой — если бабла нет довольно долго — есть хорошие шанс что и не будет.
Подписываюсь под заголовком не читая поста!
Подписываюсь под заголовком и статьей трижды, теперь, прочитав пост
UFO just landed and posted this here
«позитивном опыте использования» – это называется «юзабилити»
А «customer» – это всё-таки потребитель сервиса/продукта/услуги. (т.к. о «заработке» идёт речь, а не об «удовольствии от коддинга :)»
// Ладно, умолкаю: больше никаких придирок.
// Ладно, умолкаю: больше никаких придирок.
Специально на это слово убил минут 10. В оригинале было user experience это не похоже на usability :-)
Попробуйте в тексте заменить пользователь на customer и перечитайте текст — на мой взгляд ерунда получается. Все таки статья для технических ниндзя — если им еще про потребителей сказать вместо пользователей — вообще полное отторжение будет.
Попробуйте в тексте заменить пользователь на customer и перечитайте текст — на мой взгляд ерунда получается. Все таки статья для технических ниндзя — если им еще про потребителей сказать вместо пользователей — вообще полное отторжение будет.
Sign up to leave a comment.
Стартапы умирают из-за малого количества пользователей, ХВАТИТ думать о масштабируемости