Оцените цену работы по созданию портала

1 23
md5by
На сайте с 30.12.2011
Offline
68
#21
yozik13:
А то что вам сделают неважно где под заказ это будет просто кака.

На заказ да, такое делать только силами сплоченной команды ... один прогер тут не спляшет ☝

melkozaur
На сайте с 06.04.2010
Offline
532
#22

В создании таких сайтов все упирается в качество в итоге.

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

Но скорее всего все это будет работать не так, как хочется. В боевых условиях будут тормоза, независимо от хостинга. Кстати, под такой проект потребуются серьезные мощности, так что траты в любом случае будут значительные.

А так вообще, чисто по функционалу, можно посмотреть в сторону китайских движков - у них есть готовые разработки, которые стоят недорого. Можете начать с этого, потратить пару сотен баксов, покрутить, подпилить, поиграться и проверить функциональность и вообще - стоит ли этим заниматься. Может отпустит.

Если интересно - гляньте например вот это и там еще в разделах посмотрите.

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

B
На сайте с 13.02.2008
Offline
262
#23

Я бы меньше 100 тысяч долларов суммы даже не рассматривал бы.

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

nezabor
На сайте с 19.07.2010
Offline
152
#24

cayman_s, делал что-то вроде этого с бекофисом в 5000$-7000$

ну это как-бы не дорого

---------- Добавлено 21.11.2013 в 12:49 ----------

melkozaur:
китайских движков

это какие такие?

Чудес не бывает...
Solmyr
На сайте с 10.09.2007
Offline
501
#25

Уважаемые господа. Вы сильно преувеличиваете уровень проблем связанных с высокой нагрузкой.

Нагрузки порядка ~1 000 000 хитов в сутки вполне нормально обрабатываются за счет правильно организованной серверной инфраструктуры, стандартным серверным программным обеспечением, типа nginix, mysql, php и т.п. без использования специальных решений на уровне логики приложения. И чуть посвыше одного миллиона можно еще подняться, без особых программных решений.

melkozaur
На сайте с 06.04.2010
Offline
532
#26

nezabor,

Ну ссылка у меня есть в посте выше. Почитайте тамошний форум, он как раз по теме.

RL
На сайте с 19.06.2013
Offline
19
#27
Solmyr:
Уважаемые господа. Вы сильно преувеличиваете уровень проблем связанных с высокой нагрузкой.

Нагрузки порядка ~1 000 000 хитов в сутки вполне нормально обрабатываются за счет правильно организованной серверной инфраструктуры, стандартным серверным программным обеспечением, типа nginix, mysql, php и т.п. без использования специальных решений на уровне логики приложения. И чуть посвыше одного миллиона можно еще подняться, без особых программных решений.

И я полностью согласен. А вопрос про организацию «поиск неявных дублей в миллионах записей» я вообще считаю быссмысленным — всё решается на месте (хотябы правильной организацией индексов, как вы написали).

Возвращаясь к «пропасти между тысячей и миллионами записей», то SQL Server Express (бесплатный!) выполняет сложнейшие операции с миллионами записей за миллисекунды, потому, что «при правильной организации индексов» количество оперирумых записей уменьшается в разы (тысячи раз).

И опять-же, толковый инженер ПО не допустит (минимизирует) ситуацию когда ЦПУ нужно будет выполнять тяжелые операции поиска — всё упирается в конкретную ситуацию. Если мыслить вашими мерками, то Вконтакте, Facebook и Google вообще не должны существовать, потому, что еще не изобрели аппаратные рессурсы способные обрабатывать ежесекундно такое количество обращений. Но, ввиду грамотной организации, распределение нагрузок, кеширования и ухищрений — всё работает и работает быстро. Так, что не нужно — нет нерешаемой задачи, даже при ограниченном бюджете.

B
На сайте с 13.02.2008
Offline
262
#28
roman_lenko:
Возвращаясь к «пропасти между тысячей и миллионами записей», то SQL Server Express (бесплатный!) выполняет сложнейшие операции с миллионами записей за миллисекунды, потому, что «при правильной организации индексов» количество оперирумых записей уменьшается в разы (тысячи раз).

Вы хоть пробовали сами работать с таблицами в сотни миллионов строк? А несколько миллионов товаров дадут именно такие объемы. Простейшие запросы да - будут работать быстро (на чтение), но более-менее сложные запросы надо будет тщательнейшим образом проектировать и оптимизировать. Да вот вам простейший пример: имеется таблица обратного поискового индекса из 100 миллионов строк (слово-документ). Надо по этой таблице сделать выборку документов, содержащих одновременно три (четыре/пять/...) слова запроса. И эту выборку отсортировать по какому-либо параметру и опубликовать первую десятку. Если на маленьких объемах решение тривиально, то попробуйте сделать такую выборку на больших объемах.

roman_lenko:
Если мыслить вашими мерками, то Вконтакте, Facebook и Google вообще не должны существовать, потому, что еще не изобрели аппаратные рессурсы способные обрабатывать ежесекундно такое количество обращений.

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

roman_lenko:
Но, ввиду грамотной организации, распределение нагрузок, кеширования и ухищрений — всё работает и работает быстро.

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

yozik13
На сайте с 03.11.2012
Offline
84
#29
roman_lenko:
И опять-же, толковый инженер ПО не допустит (минимизирует) ситуацию когда ЦПУ нужно будет выполнять тяжелые операции поиска — всё упирается в конкретную ситуацию. Если мыслить вашими мерками, то Вконтакте, Facebook и Google вообще не должны существовать, потому, что еще не изобрели аппаратные рессурсы способные обрабатывать ежесекундно такое количество обращений. Но, ввиду грамотной организации, распределение нагрузок, кеширования и ухищрений — всё работает и работает быстро. Так, что не нужно — нет нерешаемой задачи, даже при ограниченном бюджете.

Вот какраз в этом случае меньше чем с милионом не стоит и думать. Ибо нужна команда спецов, сеть серверов, но и главное время, не меньше года точно.

Проще но не дешевле купить готовую, если кто будет продавать 😂, но это уже не лимон а намного больше. Но и в этом случае, если вещь хорошая, Гугли МСофты и прочие акулы перебьют вашу ставку.

RL
На сайте с 19.06.2013
Offline
19
#30

Ну, ребят — это спор ни о чём, я считаю. Реализация зависит от задачи, особенно в таких масштабах — мы сейчас говорим о чём-то не существующем, которое, как я говорил, возможно решается не только рессурсами компьютеров, но и человеческой помощью. Поэтому, я не говорю, что, или я там прав стопудов, или вы правы, что «ты не шаришь» — если мне поставят задачу и бюджет — я постараюсь её выполить и уложиться в деньги, но чисто по опыту, считаю, что стоимости для НЕ специалистов (пускай, технических) везде очень и очень завышены — потому, что это всеобщая политика.

1 23

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий