подскажите с чего начать?
прочитал, и сам себя не понял.
переформулирую вопрос: что нужно начать изучать, чтобы сделать свой авто.ру?
переформулирую вопрос: что нужно начать изучать, чтобы сделать свой авто.ру?
маркетинг?
какие могут быть "сложные расчеты" в авто.ру
какие могут быть "сложные расчеты" в авто.ру
маркетингне, не маркетинг.
авто.ру и exist - пример пользовательского функционала и не более.
просто между пользователем и базой даных будет движок, который умеет кое-что вычислять в соотвествии с настройками клиента.
с чего начать построение?с архитектуры. там и выделятся компоненты, станет понятно, с чего начать.
с архитектурытак в этом то, на мой взгляд, и заключается проблема.
Не знаю как вообще выглядит построение подобных систем.
Расскажи о своем опыте/знаниях в программировании. Иначе непонятно, с чего начинать рисовать план.
И будь готов, что если знаний примерно нуль, то чутка свободного времени никак не хватит.
И будь готов, что если знаний примерно нуль, то чутка свободного времени никак не хватит.
Имхо, стоит начать с оценок:
1. Сколько примерно планируется пользователей, особенно одновременно обращающихся - единицы, сотни, тысячи, миллионы?
2. Насколько ресурсоемкие будут это расчеты, с какой известной задачей можно их сравнить для оценки?
3. Какие требования к системе более важны: скорость отклика, максимальная доступность (отсутствие или минимизация промежутков времени, когда система недоступна) или согласованность данных между обращениями (в некоторых системах обновления происходят не сразу)?
1. Сколько примерно планируется пользователей, особенно одновременно обращающихся - единицы, сотни, тысячи, миллионы?
2. Насколько ресурсоемкие будут это расчеты, с какой известной задачей можно их сравнить для оценки?
3. Какие требования к системе более важны: скорость отклика, максимальная доступность (отсутствие или минимизация промежутков времени, когда система недоступна) или согласованность данных между обращениями (в некоторых системах обновления происходят не сразу)?
вот вот а то ведь инвесторы наверное в авто ру не один миллион вложили. В одиночку такое не создать
опыт в программировании - С++, VB, .net. Простые SQL запросы.
В принципе, легко даются языки, поэтому могу изучить любой.
к тому же есть желание.
В принципе, легко даются языки, поэтому могу изучить любой.
к тому же есть желание.
Имхо, стоит начать с оценок: 1. Сколько примерно планируется пользователей, особенно одновременно обращающихся - единицы, сотни, тысячи, миллионы?одновремнно - единицы. Сотни, если сервис будет востребован и хорошо раскручен. тысячи - недостижимый предел для подобных услуг в масштабах РФ.
2. Насколько ресурсоемкие будут это расчеты, с какой известной задачей можно их сравнить для оценки?Ресурсоемкость зависит от настроек "движка" клиентом. У всех разные потребности.
Для сравнения (из экселя) - 10 -100 ВПР по массиву в 10 000 строк - обыный десктоп вешается на пару минут.
3. Какие требования к системе более важны: скорость отклика, максимальная доступность (отсутствие или минимизация промежутков времени, когда система недоступна) или согласованность данных между обращениями (в некоторых системах обновления происходят не сразу)?Самое важное - скорость работы\отклика. Хотя важнее, чтобы работало
. Т.к. все заинтересованы в результате и готовы будут посидеть лишних 5 минут ради него.вот вот а то ведь инвесторы наверное в авто ру не один миллион вложили. В одиночку такое не создатьсначала была первичная реализация, когда проект заработал - подтянулись инвесторы (по-моей информации именно так развивалось авто.ру).
в одиночку можно создать. хотя это займет очень много времени.
Мой миллион в качестве инвестиций - время, желание и упертость.
а что такое ВПР?
а что такое ВПР?впр ищет значение в первом столбце массива таблица и возвращает значение в той же строке из другого столбца массива «таблица».
ссылка для детального изучения
Кто работает с экселем, тот обязательно с ней сталкивался.
Видимо, я не очень удачный пример привел с впр.
А веб-ориентированное что-нибудь раньше писалось?
Конкретно ВПР на 10000 строках должен летать. На вшивом ноуте такой запрос должен успевать отрабатывать примерно 10000 раз в секунду. Excel правда так тормозит?
А веб-ориентированное что-нибудь раньше писалось?к сожалению, нет.
был опыт только проганья монте-карло для физики высоких энергий.
По теме: учи что нить наподобие Питона+Джанго, ну и вообще общие принципы разработки веб-приложений.читаю про это сейчас.
может кто посоветует где можно почитать про ПРИНЦИПЫ разработки веб-приложений?
PHP
Отлично, тогда стоит еще такими вопросами задаться:
Много ли данных участвует в расчетах для одного пользователя и насколько данные разных пользователей независимы? Зависят ли ответы одному пользователю от активности его соседа?
Это важно для выбора базы данных.
Еще: что важнее - быстро выполнять расчеты или уметь быстро менять их схему, подстраиваясь под пользователя? Это поможет в выборе языка.
Дальше стоит реализовать сами расчеты на том языке, который лучше всего знаешь, и оценить скорость: сколько их получится провести за секунду на одной машине, сколько машин потребуется для сотни пользователей. Там уже смотреть, стоит ли их реализовывать на С/С++ (или даже экзотике вроде CUDA или подойдет что-нибудь попроще.
Много ли данных участвует в расчетах для одного пользователя и насколько данные разных пользователей независимы? Зависят ли ответы одному пользователю от активности его соседа?
Это важно для выбора базы данных.
Еще: что важнее - быстро выполнять расчеты или уметь быстро менять их схему, подстраиваясь под пользователя? Это поможет в выборе языка.
Дальше стоит реализовать сами расчеты на том языке, который лучше всего знаешь, и оценить скорость: сколько их получится провести за секунду на одной машине, сколько машин потребуется для сотни пользователей. Там уже смотреть, стоит ли их реализовывать на С/С++ (или даже экзотике вроде CUDA или подойдет что-нибудь попроще.
почитать про ПРИНЦИПЫ разработки веб-приложений?
В небольшом масштабе достаточно почитать книжки/доки про джанго, рельсы или другой MVC фреймворк, основные принципы организации там должны быть описаны. Важно понимать, как работает веб-сервер и СУБД (что на входе, что на выходе, что делается независимо и параллельно, а что нет, как организуются сессии и чем это чревато). Это принципиальные вещи, остальное лишь детали, варьирующиеся от фреймворка к фреймворку.
Дальше можно почитать разные примеры с highload.org и других сайтов, где рассказывают об архитектуре крупных сайтов, вроде амазона, твиттера, дигга и пр. Фишка в том, что все делают очень по-разному, на очень разных технологиях, но есть некоторые общие принципы, вроде шардинга данных, load balancer'ов и т.д.
PS. Я в этой теме не настоящий сварщик, но надеюсь своими вопросами и твоими ответами спровоцировать местных спецов на более конкретные рекомендации.
ПРИНЦИПЫ разработки веб-приложений?http://apparchguide.codeplex.com/ , глава 21 — это, скорее, для больших приложений, но написано довольно внятно. Далее копать в нужную сторону (высокая нагрузка, rich ui, …).
Начни с начала, - важно ответил Король, - продолжай, пока не дойдешь до конца.
с чего начать построение?Перво-наперво надо забить на highload. Тебе это сейчас сто лет не надо.
Во-вторых забить на "технически грамотную реализацию".
Делай минимумом усилий.
Главная проблема любой подобной штуки не в технической реализации, а в том откуда пойдут деньги и клиенты.
Как будет четкое понимание сколько клиентов и почем найти можешь, так и можно будет обсудить сколько сил и денег надо на разработку и имеет ли она вообще смысл.
+1, париться по поводу хайлоада, или какую базу выбрать чтоб было щастье, сейчас бесмысленно.
вероятность правильно идентифицировать и правильно оптимизировать будущий затык на стадии планирования стремится к нулю. при близком к нулю опыте в разработке это безнадежно. "эксперты" посоветовать что-то разумное без детального описания алгоритмов тоже не смогут, кроме самых общих советов.
общие советы - не париться, изучать что-то общеупотребительное из самого знакомого языка, или языка знакомого гуру. что-то выше уже советовали.
если до соплей хочется масштабируемости - смотри в сторону энтерпрайзнутых кластеризуемых вширь технологий типа j2ee. заморачиваться сильно не надо, просто напиши код на этом фреймворке. потом, когда появится нагрузка, уже будет понятно пригодилось/непригодилось.
еще посмотри на облачную платформу google app engine. достаточно простой кик-старт, что есть огромный для тебя бонус, ибо переварить энтерпрайзнутый стек технологий с нуля нереально.
но в не-бизнес-варианте нету привычной реляционной бд. зато апи построено так, что написать хреново масштабируемое приложение будет гораздо тяжелее, чем в случае того же j2ee.
вероятность правильно идентифицировать и правильно оптимизировать будущий затык на стадии планирования стремится к нулю. при близком к нулю опыте в разработке это безнадежно. "эксперты" посоветовать что-то разумное без детального описания алгоритмов тоже не смогут, кроме самых общих советов.
общие советы - не париться, изучать что-то общеупотребительное из самого знакомого языка, или языка знакомого гуру. что-то выше уже советовали.
если до соплей хочется масштабируемости - смотри в сторону энтерпрайзнутых кластеризуемых вширь технологий типа j2ee. заморачиваться сильно не надо, просто напиши код на этом фреймворке. потом, когда появится нагрузка, уже будет понятно пригодилось/непригодилось.
еще посмотри на облачную платформу google app engine. достаточно простой кик-старт, что есть огромный для тебя бонус, ибо переварить энтерпрайзнутый стек технологий с нуля нереально.
но в не-бизнес-варианте нету привычной реляционной бд. зато апи построено так, что написать хреново масштабируемое приложение будет гораздо тяжелее, чем в случае того же j2ee.
смотри в сторону энтерпрайзнутых кластеризуемых вширь технологий типа j2eeкстати, много ли действительно высоконагруженных проектов работают на j2ee? его надо знать очень хорошо, скорее это для тяжелой бизнес логики.
j2eeсразу лесом
неа, не очень много, потому что после какого-то не очень большого предела оно хреново масштабируется.
если смотреть на хайлоад, то все решения там специализированы, и сильно отступают от традиционной парадигмы/архитектуры веб-приложений, из которых выросла j2ee.
если смотреть на хайлоад, то все решения там специализированы, и сильно отступают от традиционной парадигмы/архитектуры веб-приложений, из которых выросла j2ee.
Необоснованное (читай глупое) мнение, особенно в случае топикстартера.
Это вполне добротный базис, с которого можно начать. Заметь, я не утверждаю, что надо обязательно заюзать весь стек технологий. С моей точки зрения оптимально иметь сервлет-контейнер + ручное jpa. Аппликейшен сервер - уже лишнее. EJB с CMT, JAAS, ... - подавно.
Не надо на j2ee зацикливаться, и все свои проблемы пытаться через него решить. Как только видите, что дял дальнейшей правки производительности надо, к примеру, править сурс-код сторонних либ - отказываетесь от них в пользу специфичных "хайлоад" решений.
Это вполне добротный базис, с которого можно начать. Заметь, я не утверждаю, что надо обязательно заюзать весь стек технологий. С моей точки зрения оптимально иметь сервлет-контейнер + ручное jpa. Аппликейшен сервер - уже лишнее. EJB с CMT, JAAS, ... - подавно.
Не надо на j2ee зацикливаться, и все свои проблемы пытаться через него решить. Как только видите, что дял дальнейшей правки производительности надо, к примеру, править сурс-код сторонних либ - отказываетесь от них в пользу специфичных "хайлоад" решений.
надо, к примеру, править сурс-код сторонних либ - отказываетесь от них в пользу специфичных "хайлоад" решений.т.е. потом всё надо будет переписать?
т.е. потом всё надо будет переписать?Да. И это имхо нормальный для хайлоада путь развития, который будет дешевле, нежели попытки сразу написать "правильно".
не, не маркетинг.формулировка, конечно, может выражать нечто иное, но самое очевидное прочтение того,
авто.ру и exist - пример пользовательского функционала и не более.
просто между пользователем и базой даных будет движок, который умеет кое-что вычислять в соотвествии с настройками клиента.
что ты написал, сообщает нам, что ты идиот, вернее, что у тебя не получится авто.ру.
причем, характерно, что у дрюхи, к которому ты
не хочешь прислушаться, своего рода свой авто.ру есть.
и у __но__ такая же ситуация.
и у алепара наверное, просто он как обычно на джаве ответил,
поэтому я не вчитывался.
не хочешь прислушаться, своего рода свой авто.ру есть.
и у __но__ такая же ситуация.
и у алепара наверное, просто он как обычно на джаве ответил,
поэтому я не вчитывался.
формулировка, конечно, может выражать нечто иное, но самое очевидное прочтение того,что ты написал, сообщает нам, что ты идиот, вернее, что у тебя не получится авто.ру.друг, выдыхай!
и вообще, откуда столько желчи?
хочу поблагодарить всех отметившихся за советы.
Многое из вышесказанного обдумывал неоднократно, но не был уверен до конца.
начну построение из того что знаю. именно так и ни как иначе, т.к. существует большая вероятность, что ни чего вообще не заработает.
всем спасибо!
всем плюсики
Многое из вышесказанного обдумывал неоднократно, но не был уверен до конца.
начну построение из того что знаю. именно так и ни как иначе, т.к. существует большая вероятность, что ни чего вообще не заработает.
всем спасибо!
всем плюсики
Начни с PHP + VB Express Edition (ибо бесплатно) ну и код Авто.ру тебе в помощь.
Оставить комментарий
Mufy
Предыстория: есть чуток свободного времени и идея. Есть пытливый ум и желание реализовать идею. Нет только стратегического плана. Собственно с ним и прошу помочь.Идея заключается в создании сервиса (что-то вроде В2В) на основе бизнес-модели SAAS.
Сервис будет заключаться в том, что клиенту будет предоставлен "движок", который выполняет достаточно сложные расчеты. Пользователь будет с помощью веб-интерфейса посылать данные в "движок", движок рассчитывать + обращаться к базе данных, затем возвращать ползователю ответ.
Собственно, идея заключается в создании что-то похожего на авто.ру или exist, за исключением того, что помимо обращения к базе данных будут производиться достаточно громоздкие расчеты.
Теперь сам вопрос: с чего начать построение?