Добрый день. 
Есть необходимость использовать мускул в многопоточном приложение. разобравшись в С++ АПИ для мускула, завернув его в свои классы обертки, и локализовав это в отдельном потоке, который ждет запрос и отдает ответ всем остальным потокам, скорость приложения уперлась в производительность БД, т.е. в скорость потока работающего с БД.
мне кажется я как-то криво пишу на плюсах что ли.. но с другой стороны.. не размазывать же запросы по всему проекту, кроме того мне кажется там что-то лимитируются сессии.. или что то ещё.. т.к. я экспериментально создал 1000 потоков с запросами в БД, 
и как то оно не празднично работает.

кароче говоря, кто как интегрирует БД в проекты. и не могли бы вы наспамить ссылок на листинги, и т.п. материалы. 

з.ы. прошу простить за оффтоп, но пост ближе к плюсам и архитектуре чем к БД.

Добавлено @ 00:28
у меня кроме как создать пул потоков работающих с БД умнее не получается придумать ничего, но там какие-то грабли.. и лениво их выкупать.
помогите плиз. сроки(((

Это сообщение отредактировал(а) boost0klr - 3.2.2012, 00:29

да ты че?! жесть 
т.е. все потоки лочатся на одном мьютексе?

Добавлено через 1 минуту и 12 секунд
и объясни задачу. откуда необходимость в более чем одном потоке? чем обусловлено?

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


ну и конечно 1000 потоков не будет уменя, но будет много потоков, и хотелось бы максимально производительность приложения с БД ..приблизить к как будто бы она без БД))

ладно ..есть другой вариант. например при загрузке подгружаем из БД всё переменные в кучу, и потом работаем сней, по сигналу заново перечитываем настройки. При таком раскладе плевать на эти тормоза, и оставляем пул потоков для записи данных в базу. Мне так даже нравится. Доброе утро

путаешь переменные с константами?  


зачем каждому потоку получать константы из БД с учетом того, что они идентичны для каждого потока? или что?


кешировать данные из БД в какой-нить объект, не пробовал?


зачем пул потоков? БД - синглтон! т.е. все запросы в любом случае обрабатываются последовательно. тут нет смысла в пуле.

ну наконецто.
т.е. самое главное.. что?
запросы к БД не распаралелить?

распаралелить можно. но какого-либо повышения производительности это не даст. а даже наоборот.
еще, распаралеливание запросов можно использовать чтоб эмитировать асинхронность. но опять же, никакого повышения скорости выборки это не даст.

если я правильно Вас понимаю, один поток, пул потоков, ..запросы БД выстраивает в очередь внутри себя???? и тут уже без вариантов.да?

да.


мне не известны многопоточные БД... может кто-то подскажет.

boost0klr

Создавай по одному MySQL соединению на каждый поток, синхронизацию СУБД сама обеспечит.

мне кажется при таких раскладах, когда из под одного процесса много запросов к базе.. через одно АПИ С++Мускл ..как то тупит оно.. не, не может такого быть?

Я честно говоря ничего не понял из вопроса, это кому предназначалось?

тут два тупика:
1. тупик производительности ФС. как правило, производительность БД ограничивается в первую очередь этим.
2. при работе с одной_БД/одним_сервером_БД - это не имеет смысла.

Добавлено через 10 минут и 20 секунд

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

Добавлено через 11 минут и 11 секунд
и не плохо бы узнать, какая именно БД используется.

Во первых не все и всегда читается с диска, а во вторых выполнения запроса это далеко не только чтение самих данных, есть и много чего другого, что вполне можно выполнить параллельно. Если интересно, можешь посмотреть в профайлере на что было потрачено время при выполнении запроса, и далеко не всегда основное время тратится на чтение данных с диска.
К тому же в базе может быть бизнес логика описанная в процедурах, чтения и запись данных вполне можно распаралеллить на нулевом рейде, я уже не говорю про кэширование.

Другое дело, что оптимальное количество потоков для приложения не обязательно равно оптимальному количеству потоков в СУБД, но хуже от этого не будет, все равно где-то надо синхронизировать, пусть этим займется СУБД.





Это сообщение отредактировал(а) azesmcar - 3.2.2012, 18:17

Парни, это всё понятно, вопрос в том ..имеет и смысл делать несколько потоков работающих с БД.. или один?
вот смотрите, есть десять потоков, всем им нужно потреблять/производить данные для/в БД.. можно к ним добавить 11й поток.. в который первые десять отправляют запросы и ждут, либо 11й, 12й, 13й, 14й, 15й поток.. для обработки данных в/для БД т.е. пул из (например) 5ти потоков...
пул работает на C++ MySQL API.. возникают сомнения что из под одного процесса и одного АПИ, весь пул будет работать корректно, и так же сомнения по поводу производительности пула, т.к. если всё встают в очередь, какая разница.. мне интересно кто как пишет.. кто как интегрирует БД в приложение.

к примеру.. вам надо раздать 200 клиентам инфу с вашего сервера_приложения, которое берет инфу из базы, вы напишите пул? или один главный поток, который будет работать с очередями от клиентов?
кэширование понятно, файловая система тоже понятно.. вопрос исключительно по архитектуре ПО. спасибо.

я никогда не использовал несколько потоков для работы с БД. при том, с БД работаю. в одном из проектов, БД используют ~4000 юзеров.
архитектура такая: сервер. юзеры коннектятся к серверу. сервер работает с БД в одной сессии. запросы в БД выполняются асинхронно по отношению к запросам со стороны юзеров, при помощи одного потока и boost::io_service::post().

Добавлено через 1 минуту и 55 секунд
я не проверял БД на предмет выполнения запросов из нескольких потоков.
напиши микротест (код выложи), любопытно.