Какое техническое решение подобрать для создания сайта?

Question

[AlexKarev]

Добрый день, уважаемые коллеги!

Планируется разработка специализированного сайта для ведения оперативной деятельности строительно-инжиниринговой компании.
Упрощённо деятельность выглядит так:

• пользователи-проектировщики создают и поддерживают каталог Строительных объектов (1М+ объектов)
  
• пользователи-инспекторы создают и поддерживают реестр Плановых инспекций объектов (10М+ работ)
  
• среднее число активных пользователей в пике 1000+
  

Прошу Вас подсказать, на основе каких технических параметров было бы оптимальнее разработать сайт, способный устойчиво поддерживать указанную функциональность? С какими параметрами необходимо определиться заранее и раз и навсегда, чтобы со временем не прийти к необходимости глобальной переделки?
И вопрос №2 - что посоветуете: заказывать сайт с нуля или подойдёт ориентация на доработку шаблона интернет-магазина - ведь можно найти шаблон с реализацией личных кабинетов пользователей и каталогами объектов, подстроив их под цели задачи?

Под техническими параметрами я понимаю обоснованный комплект решений, включающий стек технологий, CMS, вид СУБД, варианты реализации дизайна, применимости шаблонов, а также диапазоны сроков и стоимости разработки проекта под ключ + Ваш бесценный опыт по реализации подобных проектов.

Благодарю всех заранее и буду признателен за комментарии и возможные ссылки!

Comments

[Дмитрий Энтелис]

10М+ объектов и 1000 реально активных пользователей (одновременно работающих с системой) - это не highload конечно, но и не шаблонные движки. Если есть бюджет - пишите, пообщаемся. Контакты в профиле.

[AlexKarev]

Дмитрий Энтелис: Дмитрий, спасибо за участие и предложение. Бюджета нет, ибо пока находимся на стадии прикидки цен и сроков, изучаем потребности системы и, соответственно, необходимые ресурсы. Контакты буду иметь ввиду.

Answer 1

[Philipp]

Поскольку я сталкивался с подобными задачами, сразу скажу, что нужно писать систему готовую к горизонтальному масштабированию.
Сразу выкиньте из головы готовые CMS и прочую шелуху, когда вы засунуте в базу под лям объектов, вы начнете топить печь деньгами, чтобы обеспечить должный уровень отклика.
Базу следует брать SQL, начинать с mysql и изначальной настройкой мультимастер шардинга+репликации+failover. Здесь очень долго посидеть над анализом документации, поиска по параметрам и т.д. На первичном этапе это не требуется, но потом часто выливается в гемор.
На бэкэнд следует брать Go (Gorm для работы с базой). Он легко деплоится и просто масштабируется c помощью примитивной балансировки.
Строительную документацию и картинки сразу хранить в S3-подобном хранилище.
На фронтэнд берите последний AngularJS. Можете поиграться с Vue, но потом вам все равно прийдется это переписывать.

Для такой работы вам потребуются следующие специалисты: дизайнер (фринлансер), devops-чел (проверенный, на удаленке), 2 программиста (frontend + backend) на полный рабочий день (они тоже могут работать удаленно) и руководитель проекта (технический директор).

Не экономьте на специалистах, иначе получится неюзабельное говно.

Не думайте о такой системе, как о сайте. Вам нужно веб-приложение.

Comments

[AlexKarev]

Philipp, большое спасибо за подробный ответ!

[sim3x]

AlexKarev: "golang - брать не обязательно, но желательно

СУБД лучше брать сразу postgresql

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

[Philipp]

sim3x говорит по делу, postgresql тоже будет отлично работать.
Go Lang из соображений возможной необходимости веб-сокетов, т.к. людей работающих с одними и теми же данными может быть много и могут потребоваться данные в режиме реального времени.

[AlexKarev]

sim3x: Philipp: благодарю Вас за ценные дополнения и новую (для меня) информацию.

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

Вот что в итоге получилось:

• требуется создать быстрое и полномасштабное SPA-приложение с динамической загрузкой данных для работы аудитории пользователей 1К+
• система пишется с нуля, шаблонная CMS не подходит
• фронтэнд: AngularJS/Bootstrap/UIKit/JQuery и т.п.
• бекэнд: Go + (php) Symphony/Laravel/YII/Zend/Django или Ruby'On'Rails
• хранение BigData: платные сервисы Amazon S3, Microsoft Azure и т.п.
• СУБД: нереляционная (MongoDB, PostgreSQL и т.п.) или реляционная (MySQL/SQL Server) + настройка шардинга и/или репликации
• (не моё, но нужно, оказывается) deploy - Capifony/Capistrano/Deployer и пр.

Технологии указаны в порядке убывания предпочтительности.

Скажите, есть логика в такой систематизации?

[sim3x]

AlexKarev:

СУБД: нереляционная

чисто нереляционная (монгодб) не нужна
Postgresql умеет все тоже, что и монга, но лучше и с sql

• бекэнд: Go + (php) Symphony/Laravel/YII/Zend/Django или Ruby_On_Rails (ruby)

джанго = питон. Ищите CTO - пусть он уточняет стек и языки программирования

• хранение BigData: платные сервисы, Amazon S3, Microsoft Azure и т.п.

ето не бигдата. Просто хранение данных

• (не моё, но нужно, оказывается) deploy - Capifony, Deployer, Capistrano и пр.

деплой тоже на CTO. Обратите внимание на ansible, chef

[Philipp]

Под вашу задачу нереляционная БД не нужна. Тут у вас выбор из PostgreSQL или MySQL.
Django или Ruby On Rails будут плохо масштабироваться.
Backend: Go или PHP.
Frontend: AngularJS или Vue.js или React.
Деплой то, что удобно. Сейчас модно Docker+Compose+Convox.

[AlexKarev]

sim3x:, Philipp: отлично, спасибо! очень важная для меня информация про выбор БД и про масштабируемость Djando и RoR, теперь основа чётко конкретизирована: PostgreSQL + AngularJS + Go/PHP.

[Unicom]

По технологиям: RoR - скорее мертв / Python Django будет давать плюс в скорости запуска, потом может возникнуть проблема масштабирования / Go - скорее всего оптимум / PHP - забудьте (никакого выигрыша вначале и ужасы в обслуживании потом), а то, что на рынке полно дешевых "специалистов" скорее еще один жирный минус для HR. Про БД, непонятно, зачем в явно документноориентированную систему советчики с пеной у рта пытаются втиснуть SQL. Вероятно, при оптимизации, даже MySQL сможет выдерживать заявленную нагрузку. А зачем? Документная база сделает это легко и непринужденно.
А вообще наймите СТО с опытом работы в вашей сфере, иначе благодаря некоторым советам, потом придется переделывать.

[AlexKarev]

Unicom, спасибо! обратим внимание на NoSQL-подход к хранению документов, насколько я знаю, именно такие БД составляют основу архитектуры сайтов vk.com, facebook.com, помимо MySQL.

[Альберт Рашитов]

Philipp: а почему в качестве бэкенда не подойдёт nodejs?

[Philipp]

Альберт Рашитов: node подойдет, только она больше ресурсов будет потреблять, опять же нужно заниматься организацией кластера, бесшовных обновлений и т.д. Есть определенные ньюансы.

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

[Unicom]

Philipp: просто нужно уметь их готовить. Как правило, все подобные кейсы предсказуемы и вполне возможно держать или их индексы или специальные документы под них. Ничего не мешает сформировывать такие выборки и по каждому городу и по любым другим полям. Да, на это нужно больше хранилища, а черт возьми сколько стоит сейчас память, чтобы заморачиваться с хранением в ней текста? Одна машина с чуть большим количеством RAM или непонятный кластер вертикально-горизонтально-оптимизированных SQL, у которых вся база будет всего 1Гб, но которые при каждом запросе будут ее вдоль и поперек вспахивать. 1000 человек в пике, при 11 млн записей - довольно много для MySQL, старушка может и не сдюжить, если ее не обвешать сверху кэшами вроде Redis/Memcache, что смысл тот же NoSQL. В результате, просто плохую работу архитектора закрыли автоматическими кэшами и потеряли на всём, зато все как мы любим - денормализовано.

[Philipp]

Unicom: да, MySQL будет тяжковато.
Но тут сложно сказать. Зависит от приложения и от архитектуры очень сильно.
Если приложение будет в простом варианте, то монга потянет на ура. Будет и обслуживать просто и работать относительно быстро.
У меня в эксплуатации были оба варианта. MongoDB с большим количеством данных работает гораздо лучше. Вот сейчас база полтора терабайта и ей хоть бы хны, но и ошибок в коде не прощает. Надо заранее думать о полях, доставать и аггрегировать данные с проекциями и т.д. Нужно заранее продумать, что именно хотят получить от этой системы, проработать пару итераций, тогда будет легче определиться.
В описанном варианте огромного журнала MongoDB несомненно будет намного лучше MySQL и вполне поместится на один сервер. Но если ребятам захочется статистику навороченную, то станет весело.

[alex-1917]

ой, да ладно, ексель попрет за милую душу!!..
)))

Answer 2

[vkdv]

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

Я это вижу примерно так :

1) Наймите Дизайнера / UХ-дизайнера и менеджера проекта. Начните разрабатывать интерфейсы, затрачивая на это по 3 - 4 часа вашего личного времени , все время менеджера и дизайнера.

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

Задачи дизайнера - понятны , он может начать с uikit и стилизации и переходить к самому сложному , как только менеджер подготовит тз для основным моментов(именно с самого главного я бы и начинал, например форм личного кабинета по объектам и коммиссии)

2) Как только будет появляться готовый дизайн (1-2 месяц) , вводите в работу верстальщика , Верстка должна быть сразу адаптивной . Скорее всего bootstrap. Первым делом верстальщик должен создать стили для UIKIT, после чего приступить к верстки страниц

3) Когда будет готова верстка страниц ЛК , нанимайте backend и front-end(при необходимости) разработчиков(например php - laravel и javascript/vue.js) Верстальщик пусть переходит к общим страницам и главной . Бэкенд и фронтенд разработчик бдут работать в паре несколько месяцев

Даже если вы решите использовать CMS или Bitrix - первые два пункта придется сделать заранее . К этому моменту будет примерно понятно , как лучше поступить с 3-м пунктом. И самое главное для исполнителя будут подготовленны все материалы , а вы сможете отвлечься на подготовку промо материалов

Comments

[AlexKarev]

vkdv, благодарю за подробные профессиональные комментарии, был востребован именно такой ответ!

Answer 3

[blugamire]

Для современных СУБД ваши 10 миллионов объектов и 1000 человек (надо полагать они не будут работать одновременно со всеми 10 миллионами объектов - просто смешная нагрузка.
Конечно, новичок-программист может и это убить неверной архитектурой.
Но в целом - нагрузка так себе.
Любые самые обычные технологии годятся, что лучше знает конечный исполнитель - от MySQL+PHP до 1С+PostgreSQL

Answer 4

[xmoonlight]

1. Никогда не пересекайте между собой основную базу объектов с CMS! Должна быть интеграция по ID-шникам.

2. Выбирайте удобную, гибкую и с большим комьюнити CMS. (Я бы выбрал CMS Joomla!)

3.

И вопрос №2 - что посоветуете: заказывать сайт с нуля или подойдёт ориентация на доработку шаблона интернет-магазина - ведь можно найти шаблон с реализацией личных кабинетов пользователей и каталогами объектов, подстроив их под цели задачи?

Вот это то, что бесит больше всего...
Поймите: САЙТ - это НЕ ШАБЛОН!
Каждый проект - УНИКАЛЕН!
ТОЛЬКО с НУЛЯ!

4. Стоимость и сроки - после ТЗ (оплачивается отдельно), ТЗ - после ФТ.
(ТЗ - техническое задание, ФТ - функциональные требования)

этапы создания сайта и прочее

Comments

[Дмитрий Энтелис]

Joomla и 10кк записей звучит несколько смешно)

[xmoonlight]

Дмитрий Энтелис: ну смейтесь наздоровье) А я - буду зарабатывать)

[Volodimir Babeshko]

xmoonlight: а клиенты - мучаться

[xmoonlight]

Konstantin Abaiev: из-за чего?! из-за того, что кто-то решил делать всё на жумле и прочитал ответ не понимая смысла?!

[Volodimir Babeshko]

xmoonlight: я обычно не вступаю в полемику с людьми, которые могут на сложных или как минимум ресурсо-затратных ресурсах предлагать джумлу или не дай бог вп, да ещё и тыкают незнакомым людям, но Вам отвечу (я понимаю прекрасно что Ваше предложение обусловлено опытом, а не его отсутствием): я прочитал все и понял и поверьте, я видел в действии Ваш совет, как наверное и каждый, кто регулярно читает тостер, и Вы сами это видели и скорее всего приходилось скрипя зубами заменять гавнокод на что-то приличное и поверьте на слово, мне как ПМ в продуктовой компании гораздо более заметны последствия необдуманного выбора того или иного компонента/ресурса в проекте. Цмски подходят для MVP или для сайтов с малой кодовой базой и это либо заранее известно или планируется или недостатка бюджета или обращения к людям, которые дают похожие совета.

[xmoonlight]

да ещё и тыкают незнакомым людям

отсюда по-подробнее: где именно?!

поверьте на слово, мне как ПМ в продуктовой компании гораздо более заметны последствия необдуманного выбора того или иного компонента/ресурса в проекте. Цмски подходят для MVP или для сайтов с малой кодовой базой и это либо заранее известно или планируется или недостатка бюджета или обращения к людям, которые дают похожие совета.

Вы ничего не поняли (и не собираетесь), к сожалению...

Answer 5

[Сергей Горячев]

С такими параметрами:

пользователи-проектировщики создают и поддерживают каталог Строительных объектов (1М+ объектов)
пользователи-инспекторы создают и поддерживают реестр Плановых инспекций объектов (10М+ работ)

ни о какой готовой системе и речи быть не может.

Тут у меня два варианта:
1) Либо бы слишком переоценили свои силы, и такого у вас никогда не будет. Для CMS норм.
2) Либо будет, но тогда возникнет вопрос расширяемости / монетизации, и любая CMS сдохнет от хотелок.

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

Comments

[xmoonlight]

Сергей Горячев:
1. про посещаемость: база линкуется с "мордой" через ID-шники и таким образом в разы снижается нагрузка.
2. про взлом:
2.1. регекс - наше всё: фильтруем все "кривые" запросы к серверу,
2.2 правильно ограничиваем права на файловую систему,
2.3 следим за контрольной суммой каждого запускаемого файла перед непосредственным исполнением.

Answer 6

[Sanes]

Битрикс Enterprise + агентстсво с опытом реализации такого проекта. Самый дешевый вариант.