Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
execoma
Member

Откуда:
Сообщений: 23
Здравствуйте уважаемые форумчане! Помогите разобраться с архитектурой системы.

Вариант 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), которое было сделано?
11 ноя 11, 16:33    [11583269]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
vvm
Member

Откуда: Не помню
Сообщений: 9968
execoma,
только оракул. :)
11 ноя 11, 16:46    [11583412]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Надеюсь вы в курсе, что SQLite блокирует БД целиком на каждую пишущую транзакцию?
11 ноя 11, 16:47    [11583418]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
execoma
Member

Откуда:
Сообщений: 23
Gluk (Kazan)
Надеюсь вы в курсе, что SQLite блокирует БД целиком на каждую пишущую транзакцию?


Поэтому ту БД, что многопользовательская мы заменили на FireBird. Но систему теперь сложно развивать, тесты хранятся в отдельных SQLite, результаты тестирования тоже в отдельных SQLite, а общая база FireBird. Все разрозненно. Ещё намудрили с этими сессиями. Хотя тут не ясно, т.к. может и правильно сделали, т.к. нагрузки в процессе тестирования на жесткий диск вообще нет! Но зато память жрется. Мы хотим сделать, чтобы админ мог через Windows-приложение коннектица к БД удаленно. С общей базой нет проблем (FireBird), а то, что каждый тест в отдельной SQLite - тут сложности, т.к. нужно удаленно передавать весь файл, а потом его возвращать. Для нужно какое-то средство самому писать, либо задействовать Apache и PHP. Поэтому возникла мысль, что мы ну слишком все усложням, т.к. при классической схеме таких проблем вообще бы не было, одна база и все на мази, но может по нагрузке все провалилось бы ...
11 ноя 11, 17:01    [11583558]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
BlackEric
Member

Откуда:
Сообщений: 759
execoma,

сколько у вас клиентов?
Объем данных, число запросов в секунду?
11 ноя 11, 17:17    [11583743]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
execoma
Member

Откуда:
Сообщений: 23
BlackEric
execoma,
сколько у вас клиентов?
Объем данных, число запросов в секунду?


Как я писал, система должна работать, при максимальной нагрузке:

200 активнейший подключений - каждое 2 select и 1 update в 1-2 секунды на таблицы до 10000 записей - и это в процессе тестирования, т.к. при запуске тестов возникает вообще множество select-ов, а по окончанию множество insert-ов и update-ов. Я не знаю, вообще тут возможно дать ответ на мой вопрос, скорее всего нужно проводить испытания. Я просто подумал, что может у кого-нибудь уже есть опыт, который позволяет оценить производительность клиент-серверных СУБД на обычных ПК, и сможет дать ответ на вопрос - (не)потянет.
11 ноя 11, 17:26    [11583882]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
BlackEric
Member

Откуда:
Сообщений: 759
execoma,

На FB должна потянуть. Хотя в итоге все будет зависеть от структуры таблиц, сложности запросов и правильности индексов
11 ноя 11, 17:29    [11583916]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
execoma
Поэтому возникла мысль, что мы ну слишком все усложням, т.к. при классической схеме таких проблем вообще бы не было, одна база и все на мази, но может по нагрузке все провалилось бы ...


С чего бы? Ни у кого не валится
11 ноя 11, 17:32    [11583963]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
execoma
Потянет ли самая классическая немудренная схема следующую максимальную нагрузку:
200 подключений, каждое из которых делает каждую секунду 2 запроса select (читает вопрос и варианты ответа) и 1 update (пишет ответ) на таблицы до 10000 записей.
Компьютер средний 2-4 гига ОЗУ, средний процессор, HDD 7200 оборотов.
Опытные администраторы СУБД скажите, пожалуйста, PostgreSQL или FireBird потянут 200 update-ов и 400 select-ов в секунду на такой машине
Если эти 400 селектов не являются "тяжелыми выборками всего на свете", то Firebird потянет.
Но только как SuperClassic (начиная с 2.5), ибо памяти мало совсем.
Также не забудьте сразу увеличить в firebird.conf'e значение DefaultDBCachePages до 512 или даже 1024. При числе подключений 200 и размере страницы в 8К общий кеш займёт 838 Мб или 1.66 Гб соотв-но.
Также задайте в firebird.conf значения для параметров MaxUnflushedWrites = -1 и MaxUnflushedWriteTime = -1 (чтобы запись на диск не стала узким местом).
Ознакомьтесь с тестами: раз, два, три.
Ну и сами попробуйте потестировать на своём железе - это надёжнее всего.
11 ноя 11, 19:39    [11584953]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
При запуске пользователем тестирования, весь тест целиком загружается в сессию PHP (массив $_SESSION).

автор
каждые 7 секунд каждый браузер JavaScript-ом

рыдалЪ.
налицо полное непонимание работы php.
Бери ужо Memcached DB и не парься.
11 ноя 11, 21:37    [11585337]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
а, еще mongobd можно. оно тоже все в памяти держит.
а по хорошему меняй архитектуру. на каждый аякс запрос подсасывать только в сессию по 3 метра - это жесть. вали то что не нужно в каждом чихе в память/файлы и читай оттуда по мере надобности.
11 ноя 11, 21:40    [11585346]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
execoma
Member

Откуда:
Сообщений: 23
Таблоид, спасибо за ценную информацию!

ScareCrow
автор
При запуске пользователем тестирования, весь тест целиком загружается в сессию PHP (массив $_SESSION).

автор
каждые 7 секунд каждый браузер JavaScript-ом

рыдалЪ.
налицо полное непонимание работы php.
Бери ужо Memcached DB и не парься.


А что там может быть не понятного? А Memcached это гамно. Memcached не позволяет загружать большие объекты (вроде больше метра, т.к. у них какие-то сложности с индексами возникли) и ещё к тому же падает при большой нагрузке и сильном расходе памяти теряя все данные без возможности восстановления. А также когда ему не хватает памяти, то он начинает удалять наиболее старые данные, а тут ничего удалять нельзя. Все это проверенно как раз на этой системе. У redisa пока такого не было замечено, тем более он умеет сливать данные на хард (например, регулярно по времени) и после сбоя их восстанавливает.

ScareCrow
а, еще mongobd можно. оно тоже все в памяти держит.
а по хорошему меняй архитектуру. на каждый аякс запрос подсасывать только в сессию по 3 метра - это жесть. вали то что не нужно в каждом чихе в память/файлы и читай оттуда по мере надобности.


Хочется, чтобы все хранилось красиво в одном месте одной базе, а не в куче баз двух разных СУБД, сессиях, кеше и т.д. Т.к. проект невозможно развивать дальше, наращивать функционал и т.д. Поэтому и возникли такие вопросы..
12 ноя 11, 00:06    [11585903]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Cудя по описанию, узкое место - php, используемый в не подходящем для него режиме. Переход к многопользовательской СУБД и минимизация запрашиваемого "на каждое движение пользователя" должны значительно улучшить дело, но, возможно, стоит не реанимировать труп, а отказаться от архитектуры, требующей "загрузки по запросу".
13 ноя 11, 12:13    [11588598]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
Таблоид
Но только как SuperClassic (начиная с 2.5), ибо памяти мало совсем.

можно попробовать применить db pool
если запросы легкие, это может дать результат
13 ноя 11, 15:02    [11588855]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
фича
Guest
alex_k
Таблоид
Но только как SuperClassic (начиная с 2.5), ибо памяти мало совсем.

можно попробовать применить db pool
если запросы легкие, это может дать результат

Это какая-то firebird-ная фича, что-то типа pg pool II для PostgreSQL?
13 ноя 11, 15:10    [11588870]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
фича,

нет, я имел в виду архитектуру в общем. не держать на каждого пользователя соединение, а брать для каждой транзакции свободное соединение из общей кучи соединений, а затем освобождать его.
13 ноя 11, 15:55    [11588936]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
фича
Это какая-то firebird-ная фича

это фича php.
14 ноя 11, 00:40    [11590692]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
фича
Guest
kdv
фича
Это какая-то firebird-ная фича

это фича php.

Хм, чето и в php такой фичи не знаю.
Есть отдельные модули подобные под php, но знаю только socket handler под mysql. А как такой под Firebird называется?
14 ноя 11, 00:50    [11590726]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
Memcached не позволяет загружать большие объекты (вроде больше метра, т.к. у них какие-то сложности с индексами возникли) и ещё к тому же падает при большой нагрузке и сильном расходе памяти теряя все данные без возможности восстановления. А также когда ему не хватает памяти, то он начинает удалять наиболее старые данные

количество граблей позволяет сказать что это клиника.
14 ноя 11, 02:14    [11590861]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
фича
Хм, чето и в php такой фичи не знаю.

вы тогда ничего о php не знаете. пул в p_connect, как минимум
http://www.php.net/manual/en/features.persistent-connections.php
14 ноя 11, 02:21    [11590865]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
фича
Guest
kdv
фича
Хм, чето и в php такой фичи не знаю.

вы тогда ничего о php не знаете. пул в p_connect, как минимум
http://www.php.net/manual/en/features.persistent-connections.php

Кстати, пул в p_connect http://www.php.net/manual/en/features.persistent-connections.php работает только под FastCGI-PHP или так же под mod_php?
18 ноя 11, 12:31    [11619523]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
execoma
Здравствуйте уважаемые форумчане! Помогите разобраться с архитектурой системы.

Вариант 1


Очень плохо.

execoma
Вариант 2


Очень плохо.

execoma
Вариант 3


Все равно очень плохо.

1) Избавиться от SQLite совсем.
2) Перепроектировать архитектуру БД и приложения

С указанной нагрузкой справиться любая БД как Firebird, так и PostgreSQL
18 ноя 11, 13:08    [11619923]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
А я знаю точно что очень многое зависит не от конкретной СУБД, а от навыков разработчика... надобы понять сначало почему у ТСа возникли столь большие нагрузки - а потом искать\советовать решение проблемы...

ps На мой взгляд с задачей SQL Express справится в легкую - ток писать запросы надо хорошо :)
21 ноя 11, 08:49    [11629406]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос архитектуры. Потянет ли СУБД нагрузку?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
SanyL
А я знаю точно что очень многое зависит не от конкретной СУБД, а от навыков разработчика... надобы понять сначало почему у ТСа возникли столь большие нагрузки - а потом искать\советовать решение проблемы...


Проблемы у ТС возниклы из-за не правильного подбора инструментов для работы.
Сам на это натолкнулся, когда разрабатывали веб-приложение на FoxPro.
Можно и даже можно использовать DBF, но работает все это мягко скажем не лучшим образом.

SanyL
ps На мой взгляд с задачей SQL Express справится в легкую - ток писать запросы надо хорошо :)


Думаю использовать SQLite где либо кроме как в однопользовательских приложениях не эффективно.
Можно, но есть шанс нарваться на трудно преодолимые ограничения платформы.
21 ноя 11, 13:17    [11631323]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить