powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Вопрос архитектуры. Потянет ли СУБД нагрузку?
2 сообщений из 2, страница 1 из 1
Вопрос архитектуры. Потянет ли СУБД нагрузку?
    #37522555
execoma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте уважаемые форумчане! Помогите разобраться с архитектурой системы.

Вариант 1

Имеется система тестирования знаний, которая делится на два интерфейса: web-интерфейс (для пользователей) и windows-приложение (для админа). Web-интерфейс работает на Apache+PHP. Каждый тест представляет отдельный файл, который является отдельной SQLite базой, а также есть общая база данных SQLite, где хранится общая информация (тесты, пользователи, результаты). При запуске пользователем тестирования, весь тест целиком загружается в сессию PHP (массив $_SESSION). Сами сессии хранятся в виде файлов. В процессе тестирования все данные читаются и пишутся в сессии, а после окончания тестирования сохраняются в базы SQLite. Кроме этого, каждый ответ пользователя фиксируется в SQLite и каждые 7 секунд каждый браузер JavaScript-ом посылает запрос, который пишет в общую базу информацию, которая нужна, чтобы проинформировать систему о своем присутствии, чтобы система знала, кто ещё жив, а кто отвалился (например, закрыл браузер).

Результат использования:
Уже при небольшом числе подключений (~10-20) на среднем компьютере возникла огромная нагрузка на процессор, память и жесткий диск. Задержки при переключении между вопросами стали недопустимо большими.
После этого были внесены изменения:

Вариант 2
Была убрана фиксация ответов пользователя в процессе тестирования в базу SQLite. Все данные сохраняются разом после завершения тестирования. Информационное сообщение браузерами теперь отправляется не каждые 7 секунд, а каждые 45 секунд. Фактически при запуске тестирования данные загружаются из SQLite в сессию PHP и затем вся работа идет только с этими сессиями, там хранится все (вопросы, варианты ответов, ответы).

Результат использования:
Большая нагрузка на жесткий диск, т.к. файлы сессий хранятся на жестком диске, и порой могут весить до 3 Мб. Причем каждый раз, когда пользователь дает ответ или переключается между вопросами, то вся сессия из файла загружается PHP в память, а затем пишется обратно в файл. Насилие жесткого диска огромно, а также он тянет за собой процессор, но там ещё допустимая нагрузка и память допустимо расходуется. Также имеется проблема когда несколько пользователей пишут в SQLite свои результаты. При работе из PHP проблема не заметна, т.к. там выстраивается очередь, а вот когда админ работает в Windows-интерфейсе, то у него могут возникать сообщения о том, что база заблокирована, т.к. SQLite на самом деле не подходит для многопользовательской работы!
После этого были внесены изменения:

Вариант 3
В качестве базы для хранения общих данных вместо SQLite была выбрана FireBird. Сессии PHP теперь журналируются в redis (кешируются в ОЗУ), а не хранятся на жестком диске.
Результат использования:
Нагрузка на жестак только при запуске тестирования и окончании (запросы в базы тестов SQLite). Общие данные теперь в FireBird поэтому проблем блокировок нет. Нагрузки на жесткий диск теперь нет, т.к. работает redis. Увеличился расход ОЗУ, но допустимо

Т.е. система услажнилась от первоначального варианта. Было Apache+PHP+SQLite, теперь Apache+PHP+SQLite+FireBird+redis.
При этом каждый тест остается в отдельном SQLite. Сделать приложение администратора с возможностью работать удаленно сложно. А такие требования возникли. Конечно можно извратиться и усложнить все ещё сильней.
Но возникает мысль – Зачем все так было усложнять?! Может быть можно было использовать классическую схему, когда все всегда читается и пишется в клиент серверную СУБД FireBird или PostgreSQL. Но тогда будут постоянные SQL запросы на чтение и запись.
Если хранить все только в одной БД на PostgreSQL? Каждый раз когда пользователь читает вопрос, то загружать его несколькими SELECT, а когда дает ответ делать UPDATE и не париться с этими SQLite, сессиями и т.д. Т.е. вопрос в следующем: Потянет ли самая классическая немудренная схема следующую максимальную нагрузку:
200 подключений, каждое из которых делает каждую секунду 2 запроса select (читает вопрос и варианты ответа) и 1 update (пишет ответ) на таблицы до 10000 записей.
Компьютер средний 2-4 гига ОЗУ, средний процессор, HDD 7200 оборотов.
Опытные администраторы СУБД скажите, пожалуйста, PostgreSQL или FireBird потянут 200 update-ов и 400 select-ов в секунду на такой машине или лучше оставить то извращение (сессии, redis), которое было сделано?
...
Рейтинг: 0 / 0
Вопрос архитектуры. Потянет ли СУБД нагрузку?
    #37522580
execoma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Извените, я выбрал не тот раздел форума. Тема перемещена в другой раздел: http://www.sql.ru/forum/actualthread.aspx?tid=894648
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Вопрос архитектуры. Потянет ли СУБД нагрузку?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]