Привет.

Есть попытки создать сайтец.

Условия: есть БД (наполняется юзерами при регистрации и позднее)
Есть страничка пользователя (права посещения своей страницы только у него)
Сейчас есть понимание, что лучше писать на MSSQL (как самый распространенный). Но переуговариемо.

Надо: формировать странички web.

Страница состоит из блоков (фреймы). Каждый блок - это результат выборки из БД по определенным условиям. Всего-то. Но блоков на странице до 20. Страниц таких разных тоже до 20 у каждого юзера.

Результаты: тексты, картинки, может видео. НУ обычная нагруженная текстом и картинками из БД.
Отображать в каждом блоке надо на основании сортировки (например: первых 5 из выборки, отсортированных по такому-то индексу)

Как думаю сделать: формировать временную табличку с переменными и их значением
т.е. табличка - это результат 20-и выборок. (индекс или переменная и ее значение)
В html ссылаться на переменные, которые подсасываются из такой временной таблички.

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

Сомнения: временных табличек будет 20 штук (по одной на каждую страничку юзера) умноженное на количество юзеров = много очень. Итого: 20 выборок * 20 страниц * кол-во юзеров.

Реально? Или забить и делать стандартно: юзер вошел - запустились его 20 выборок - появилась страничка, перешел на другую страничку - опять запустились выборки - появилась страничка

Гуру, у меня не было опыта многопользовательских одновременных запросов на 20 выборок - не знаю справится ли сервачочек.

Спасибо, ребята, заранее

Mr MarmeladdidmeГуру, у меня не было опыта многопользовательских одновременных запросов на 20 выборок - не знаю справится ли сервачочек.

Коллега - там ещё много разных вопросов ....Ну и начинайте с архитектуры - для начала. это как я понимаю Зоводской Портал? А скока денег выделяют под конфигурацию (лицензии железо и так далеее)

Да. что-то вроде. Железа и лицензий сейчас никаких нет. Надо схему показать - посчитать и дать на рассмотрение.

Senya_L
Сильно сомневаюсь, что это поможет. Гораздо больше толку будет от размера ОЗУ.
за ОЗУ не против. Есть сомнения, что ОЗУ должно быть размером с дом, если в пик несколько тысяч запросов будут одновременными. Может все таки временные таблички, которые готовятся в свободное процессорное время? А кто в онлайн, они и будут с приоритетом пользоваться процессором и ОЗУ на свои запросы.

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

Да, наверное, важно. Изменением своей странички (ну текст, добавил что-то, изменил) - юзер меняет несколько переменных в времтабличках других. и по идее от одного изменения одного юзера "пострадают" таблички 200-300 других юзеров.

Вопрос: вы считаете бред да с табличками? Денег боюсь на расчетные мощности могут не дать

Senya_LdidmeПросто частый случай, что клиент заходит только на первую страницу посмотреть на изменения выборки. И дальше не ходит (т.е. не запрашивает выборок других). Многое зависит от содержимого запроса и "тяжести" их вытаскивания. От перекладывания данных "из одного кармана в другой" толку - ноль. На простых запросах типа select ... from можете скорее потерять, чем найти.

Ну запрос - это 20 разных выборок из БД. в БД несколько тысяч юзеров, у каждого до сотни картинок, до тысячи текстовых сообщений.

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

Скажите, а как делать временную табличку и хранить ее в www.companysite.ru/userid/ ?
т.е. не в ОЗУ. ОЗУ размером с дом - пока нет.

Senya_LавторСкажите, а как делать временную табличку и хранить ее в www.companysite.ru/userid/ ? У Вас, имхо, навязчивые мысли о "временных табличках". :) Неужели думаете, что это панацея от массового наплыва пользователей на веб-узел? Если все одновременно ломанутся, то один чорт провалится дисковый IO и никакие таблички не спасут.
И вообще - многое непонятно:

Если Вы хотите хранить все данные в БД, то тогда непонятно, зачем нужны профили пользователей в виде папок? Вы уж определитесь...

Друг! Временные таблички создаются в папке пользователя, не в ОЗУ ж их хранить. ночью сервер насобачил несколько тысяч табличек и сохранил их в папке пользователя. (это как почтальон ночью почту разнес, утром открыл дверь, а почта лежит)

авторНо чтобы юзеры не убивали сервер утром. придя на работу, он за ночь может подготовить скелеты (табличка результатов 20-ти выборок).Вам виднее предметную область, конечно, но вот я не понимаю какой "скелет" странички надо "подготовить". Причем всю ночь готовить.[/quot]

страница - это html, где данные подсасываются из папки(профиля) юзера, которые сформированы за ночь. Смотрите: в табличке

переменная 1, значение
переменная 2, значение
переменная 3, значение
переменная 4, значение

причем переменная 1 и 2 - это результаты выборки А,
3 и 4 - результаты выборки Б

Кифирчикdidme,
для веба, странички формируют обычно средствами php,perl или ASP
от этого во много зависит выбор платформы (или интерпритатор выбирается от платформы)
как правило php/perl... - это Linux|FreeBSD + Apache + MySQL/PostgreSQL/FireBird
а для asp - Windows, IIS + MSSQL
конечно могут быть и другие варианты(комбинации) и в обоих случаях в качестве СУБД также могут быть Oracle, DB2, Sybase

Пока нет железа. Вообще есть план, все это делать на чужом хостинге, на их мощностях.
Есть предпочтения личные: MSSQL + ASP (Ajax тоже будет нужен). Но переуговариваемо.

Кифирчик
по 20 выборок на страничку - это не так то и много... а если активно использоваться возможности СУБД (всяки представления, хранимые процедры), то ваще будет круто
крутятся же большие порталы... а там и бывает и не по 20 запросов на страничку... работают же, и пользователей там не мало.

я так понимаю там как раз схема: запрос-выборка-отобразить. и кучи порцессоров.

Кифирчик
хотите быстре?
1. оптимизируйте запроссы и алгоритмы, архитектуру
2. картинки, и вообще файлы, храните не в БД. разнесите на разные сервера СУБД, веб сервер, файл-сервер..
3. кластеризация

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

Кифирчик
и очень непонятна мысль про временные таблички которые должны готовиться ночью... а если данные днём в базе поменяются... пользователю ждать следующего дня чтобы увидеть обновлённую информацию?
я допускаю что могут быть случаи, когда нужны "временные" таблички с оперативными данными.. с которыми в течени дня будут работать, но уже точно не для каждого пользователя.
надо делать/оптимизировать так, чтобы всё срабатывало без ночных приготовлений

Давайте так: представьте что ваша юзерская страница это user12.html
она сформирована до того как вы вышли в онлайн. Т.е вы грузите просто готовую страницу (но уже именно с вашими выборками), и не грузите сервак.

Ночной подготовкой я называю "незапросное время". т.е. и днем может быть.

Показательный пример.

"спасение сервера"
1. У вас 100000 юзеров. у каждого должна быть своя страничка.
2. Ночью сформировалось 100000 разных html и раскидалось в папки юзеров.
3. Утром юзеры зашли - скачали свой html (процессорная загрузка 0)
4. Кто-то что-то изменил - (добавилась в базу запись, она меняет выборку у кучу других юзеров) - создалось 2 очереди:
а) для тех кто сейчас в онлайн - срочно обновить выборку-обновить страницу.(процессор загружен)
б) для тех кто в оффлайн - обновить выборку после очереди а) (в моем термине: "ночью") (процессор загружен, но не в ущерб юзерам)

"убийство сервера" (стандартная схема)
1. у вас 100000 юзеров. 10% зашли в 9.00-9.30. Плюс первые же, чего-то наменяли сразу же. Сервер умер для пользователей, так как у него очередь запросов на выборки.
Спасти это можно только купив "дом" серверов.

Думаю 10% это средняя одновременность юзеров.

Кифирчик
didme
>Скажите, а как делать временную табличку и хранить ее в www.companysite.ru/userid/ ?
это в форум по PHP... там много раз обсасывалось

а PHP зачем? не хватит SQL+asp?

Кифирчик
определитесь с тем, какие средства и "технологии" будете использовать, какое железо сможете получить... архитектура... а только потом уже нюансы типа www.companysite.ru/userid/ и временных табличек.

MSSQL + ASP + Если порекомендуете PHP.
Железо: пока сервак хостера. Если вообще это реально.

Итого: Есть ли возможность в SQL вывести таблички переменных (временными я их называю) в папки юзеров? Как? Табличка переменных - это результат нескольких выборок.

Кифирчикdidme
1. У вас 100000 юзеров.
....
Думаю 10% это средняя одновременность юзеров.
...

ага... 100тыс юзеров, и на чужом хостинге... из них 10тыс одновременно на сервере..
мож надо виртуальный, или отдельный арендованный сервер?
вы точно уверенны что будет такая нагрузка?
1. сначала нет. но предусмотрено расширение за счет клиентов продукции Зовода. а это хер знает сколько. причем клиент почти юзер для него просто другие выборки. Т.О. порядок числа юзеров может быть и такой.

Тут фишка как раз в том, что при моей схеме - "ночью готовим готовые (как мне подсказал Mr Marmelad) xml - таблицы переменных" - ночью сервак не загружен - пусть работает -схема тогда и для 1 млн не страшна.

2. Я предполагаю если не найду такого хостера будем покупать/арендовать свой. Но позже, когда докажу, что пользователей уже больше, чем разрешает хостер. Сейчас руководство уверено, что у хостера все равно мощности больше, чем сервер который они могут себе позволить.

didme... Про картинки вне БД вопрос: это же увеличивает время отображения страницы. Если картинки в БД, но в разделе, который в выборках не участвует (а участвую только индексы на картинки в БД). ..
в базе хранится только ссылка на картинку которая файлом лежит на диске
затраты базы - выдать эту ссылку
далее веб сервер выдаёт картинку клиенту это уже будет немного быстрее, и если это будет отдельные сервер, заточеный под "выдачу картинок" (без поддержки всяких дополнительных фенечек) это значительно быстрее чем всё в одной железке

Разумно. Спасибосы. Вопрос: если картинок больше 30 на странице - в твоем случае html будет запрашивать каждую отдельным минизапросиком - это вроде долго. Если картинки в базе - то вроде быстрее.
Причем в моей схеме в "ночную" таблицу переменных также уже вставлены эти 30 картинок (результат выборки).
Отсюда вопрос: в xml можно воткнуть картинку? только ссылку на картинку не устраивает. Если нельзя - то куда можно?
автор
didme
"спасение сервера"
...

didme, поделитесь рассчётами в которых вы определили что будет такая нагрузка


Юзеры (сотрудники) более 1000, клиенты - дофига.


didmeа PHP зачем? не хватит SQL+asp?
приехали...
php - скриптовый язык и интерпритатором который позволяет генерить веб странички
также как и ISS +asp. разные платформы со схожим функционалом
всё что будет от мелкософта - может быть проще в разработке и сопровождении, но нужно заведомо боле мощное железо чем с аналогичными решениями на open source
ну и соответственно деньги за сам софт.

Senya LЕсли Вы хотите хранить все данные в БД, то тогда непонятно, зачем нужны профили пользователей в виде папок? Вы уж определитесь...
Хранить всё в БД. профили юзеров нужны только для хранения результатов выборок, чтобы не при его заходе их расчитывать.

ИТОГО: Так понял, что запросы на выборки юзером в онлайн - это php
"ночные" выборки - это SQL
результаты выборок - это xml
у тех, кто в онлайн- их xml храним в ОЗУ.

а ASP - хуже php? он же по-моему тоже запросы формирует серваку от юзера онлайн.

didmeИтого: Есть ли возможность в SQL вывести таблички переменных (временными я их называю) в папки юзеров? Как?
как в вписать в файл 10 пустых бутылок пива?

По другому:
Как можно вывести результаты ночной выборки (текст и картинки) из SQL в файл (допустим xml), чтобы утром html мог оттуда показать страницу. Процессор утром в данном случае загружен 0%

Госпада! А Вы умные!

cms не подходит. надо писать свой сайт.

не рассматривать мелкомягких. аргументы? форум мелкомягких самый большой на этом сайте. Они все лузеры?

Госпада!
Спасибо за ответы.

Есть варианты архитектуры для медиа:

1. хранить картинки (фото) и видео внутри базы используя тип filestream.
плюсы:
а) вроде в выборках эти фото не крутятся, крутятся только ссылки-индексы на файлы.
б) в бекапах не участвуют
в) быстро

минусы: А) пока не знаю (википедия отказалась от этого варианта)
б) Если это не отдельный физический Жесткий диск, то при отображении фоток у пользователей, база постоянно будет обращаться к этому ЖД.

Не знаю, может Filestream можно хранить на отдельном ЖД?

2. хранить на файл сервере, а в базе выборкой крутятся только ссылки-индексы на эти файлы.
плюсы: не раздувается БД (но при Filestream вроде это и не является частью БД)
минусы: при отображении на странице N фоток надо сделать столько же минизапросиков файлсерверу, а это потеря скорости.

Впринципе, написав это я понял, что если хранить в Filestream то web запросы на отображение фоток будут постоянно грузить ЖД, где расположены фото. А это значит что ЖД будет разрываться между расчетами выборок для БД и запросами пользователей на отображение фоток.

В итоге вопрос: можно ли filestream БД хранить на отдельном физическом ЖД и доступ на чтение пользователями сделать без обращения к основной БД, напрямую?

didme,

ну госпада, ну подскажите

Итог:

Скажите Ваше мнение о придуманной архитектуре:
соцсеть. web проект.

Предполагаю:
1) 2 сервера: один для оnline юзеров, второй для офлайн юзеров.
2) архитектура такая:
а) у каждого юзера есть своя папка, где хранится файл data.xml с переменными и значениями (значениями могут быть текст, системные данные (дата, время, "выделить", "new" и т.д., индексы на других юзеров, фото)
б) при залогинивании юзер грузит страницу index.html, где есть переменные, которые подкачиваются НЕ ИЗ БАЗЫ,а из файла data.xml
в) таких xml файлов может быть несколько для index2.html index3.html

3) сервер онлайн работает только для online юзеров: при добавлении любой записи юзером запускается некий процесс, который 3.1. обновляет юзерский xml и 3.2. отправляет этот новый текст в базу (ставит в очередь, так как многим друзьям юзера теперь надо обновить их xml

4) офлайн сервер ставит в очередь (обновление xml файлов) всех кто в офлайне. и готов спокойненько обновленные xml для всех.

Вообще такое решение живое? Оценку тоже можно.