- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Предполагается большая часто обновляющаяся информационная база данных с большим количеством пользователей. Задача - выбрать оптимальный способ работы с сервисом.
Хотелось бы услышать комментарии относительно плюсов и минусов того или иного метода в плане устойчивости, удобства, трудо- и ресурсозатрат, и прочих нюансов. От себя начну с таких:
Web-сайт:
+ Экономия трафика с обеих сторон: пользователь и сервис;
- Уязвимости движка (кода);
- Большая нагрузка на сервер;
ПО Клиент-Сервер:
+ работа в оффлайн с ранее обновленными данными (высокая скорость обработки, возможность получение обновлений только на интересующую тематику посредством обращения к скриптам на сервере или автоматически по команде от сервера);
- Необходимость синхронизации данных с сервером на предмет актуальности информации - трафик(хотя, возможна частичная загрузка интересующих тем);
Ну и так далее... Надеюсь, понятно.
Если кто-то ранее разбирал похожую задачу, к чему пришли?
ЗЫ, в подобных вопросах не профи, поэтому на перечисленных +- не настаиваю.
Спс.
Сайт ИМХО лучше, т.к. один плюс - доступность из любой точки мира, перекрывает все минусы.
А Вы не рассматривали и то и то? Я например для своих задач делал на php+mysql, работать такая штука может и на локальном сервере в офисе и на глобальном, т.е. через Инет.
Предполагается большая часто обновляющаяся информационная база данных с большим количеством пользователей.
Число пользователей?
Квалификация пользователей?
Как юзеры распределены географически?
Как юзеры распределены по типам подключений: ADSL, выделенка и dial-up?
Объём изменяющихся данных (часто меняется лишь малая доля документов)?
Тяжесть запросов к базе?
Количество запросов в минуту?
Нужна ли необходимость масштабирования и до каких пределов?
Как часто планируется изменять логику/дорабатывать код (и мучаться с переустановкой ПО)?
spideful, ПО можно скачать с сайта из любой точки мира, а ранее полученные данные можно например перенести флешкой.
Вариант два в одном рассматривали, но на данном этапе это неосуществимо. Иначе не было бы этого топика :)
Слава Шевцов,
Число пользователей? - на первоначальном этапе планируеся несколько тысяч зарегистрированных. Одновременных в онлайн - сложно сказать. По большому счету, там нет необходимости в более 1 синхронизации в 2-3 дня. В случае с автоматическим обновлением - чаще, но процент подписок на всю базу целиком - значительно меньше.
В случае с сайтом - посетителей конечно больше.
В дальнейшем возможно развитие направлений.
Квалификация пользователей? - Это имеет значение?)
Как юзеры распределены географически? - В пределах СНГ - достаточно)
Как юзеры распределены по типам подключений: ADSL, выделенка и dial-up? - Основная часть - из больших городов. Если кто-то не пробился по диалапу - скорее "отряд не заметил потери бойца".
Объём изменяющихся данных (часто меняется лишь малая доля документов)? - Не менее 70% базы - то, что уже не будет меняться. Однако, база будет расти. При этом соотношение сохраняется..
Тяжесть запросов к базе? - Наверное, не легко)
Количество запросов в минуту? - Тоже затрудняюсь ответить.
Нужна ли необходимость масштабирования и до каких пределов? - Вообще не понимаю о чем речь)
Как часто планируется изменять логику/дорабатывать код (и мучаться с переустановкой ПО)? - Логика принята изначально, хотя на тестах/в процессе посмотрим. Код - будет дорабатываться, возможно постоянно, независимо от варианта (есть много идей). Переустановка ПО на сервере - проходит почти незаметно для пользователя, клиентское ПО - умеет автообновляться.
Тяжесть запросов к базе? - Наверное, не легко)
Количество запросов в минуту? - Тоже затрудняюсь ответить.
Нужна ли необходимость масштабирования и до каких пределов? - Вообще не понимаю о чем речь)
Это - краеугольные камни для серьезного проекта. Все остальное - били-мили-тристика для чайников.;)
Квалификация пользователей? - Это имеет значение?)
Как юзеры распределены географически? - В пределах СНГ - достаточно)
Тяжесть запросов к базе? - Наверное, не легко)
Количество запросов в минуту? - Тоже затрудняюсь ответить.
Нужна ли необходимость масштабирования и до каких пределов? - Вообще не понимаю о чем речь)
Смотрите. Квалификация пользователей не известна. Значит веб предпочтительнее (быстрее обучаться). Юзеры распределены фиг знает как. Значит много диалапа. Это сильный аргумент за софт на стороне клиента. Тяжёлые запросы - тоже за софт. Если тяжёлые запросы одинаковые, то появляется возможность использовать memcached и снять нагрузку. Если число пользователей будет расти (при тяжёлых запросах) - софт. Иначе замучаетесь с серверами и репликацией.
Число пользователей? - на первоначальном этапе планируеся несколько тысяч зарегистрированных. Одновременных в онлайн - сложно сказать.
А чего сложного-то? Если бизнес-софт, то все утром пришли на работу и в период 8:00-11:00 сели выкачивать свежее обновление. Или все полезли в это время на сервер. Считайте нагрузку ;) Если софт более редко используется, то всё равно есть просчитываемые варианты основных вариантов его использования и пиковых нагрузок. Там могут быть реальные узкие места: в один час двукратная перегрузка, в другой загрузка лишь на четверть средней мощности.
Объём изменяющихся данных (часто меняется лишь малая доля документов)? - Не менее 70% базы - то, что уже не будет меняться. Однако, база будет расти. При этом соотношение сохраняется..
Итого, 30% данных таскать в сжатом виде по нескольким тысячам юзеров каждое утро. Если база 10 мег, то это 5-10 Гб за пару-тройку утренних часов. Если 100 мег, то 100Мбит канала уже заведомо не хватило. Решается постановкой нескольких отдающих файловых серверов.
Как часто планируется изменять логику/дорабатывать код (и мучаться с переустановкой ПО)? - Логика принята изначально, хотя на тестах/в процессе посмотрим. Код - будет дорабатываться, возможно постоянно, независимо от варианта (есть много идей). Переустановка ПО на сервере - проходит почти незаметно для пользователя, клиентское ПО - умеет автообновляться.
Если изменения не чаще раза в пол года, то можно и софт. Практика показывает, что если код обновляется регулярно, то серверный вариант значительно лучше. Во-первых, это технически проще. Во-вторых, ошибок и багов меньше. В-третьих, всегда найдётся 3-5% людей, у которых возникнут проблемы с автоматической переустановкой софта. Они будут звонить, писать на форумах, ругать. Оно надо?
Это - краеугольные камни для серьезного проекта. Все остальное - били-мили-тристика для чайников.;)
Это понятно.
Serboy добавил 24.05.2008 в 18:10
Смотрите. Квалификация пользователей не известна.
Да справятся. Им можно помочь.
Все же диалапа скорее не будет.
Это сильный аргумент за софт на стороне клиента. Тяжёлые запросы - тоже за софт.
Спасибо за мнение, как раз это интересует.