Как организовать многопоточный доступ к бд?

@fedwq · Регистрация: 24.06.2012

Студворк — интернет-сервис помощи студентам

Дано: Сервер на C#, подразумевает обслуживание большого количества клиентов(соединений) и каждый в своем потоке. Бд одна и каждый клиент время от времени хочет либо получить данные из бд, либо записать данные в бд. Для чтения использую DataAdapter, но иногда выскакивает ошибка "There is already an open DataReader associated with this Connection which must be closed first". Я так понимаю, 2 потока не могут одновременно читать данные. Приложение сервера использует одно соединение к MySQL на всех. Как можно сделать многопоточный доступ к базе данных? Или многопоточность MySQL - это ложь и провокация? Можно ли организовать многопоточный доступ путем присвоения каждому клиенту своего соединения с бд. Какое максимальное количество соединений с MySQL и как его изменить?

@lawliet93 · 27.06.2013, 13:54

Такая же проблема, так и не нашел решения. Максимальное количество подключений к бд вроде устанавливается при установке мускула, ну и изменить его легко, но сам подумай, если клиентов будет много, вот я, например, хочу попробовать запилить небольшую ммо рпг, а там может быть и 1000 и больше клиентов и каждому нужен доступ к бд, эт уже слишком. НО! Ведь веб-серверы тоже обслуживают большое количество пользователей и юзается 1 бд и как-то оно работает же.

@Dolphin · 27.06.2013, 14:06

Максимальное количество соединений к базе, определяется в настройках, в файле my.ini
Где то там должна быть строка типа

Code
1
max_connections = 50

Добавлено через 1 минуту

Не по теме:

Блин, тема за 2012 год... И я не посмотрел...

@lawliet93 · 27.06.2013, 15:29

Сообщение от Dolphin

Максимальное количество соединений к базе, определяется в настройках, в файле my.ini
Где то там должна быть строка типа

Code
1
max_connections = 50

Добавлено через 1 минуту

Не по теме:

Блин, тема за 2012 год... И я не посмотрел...

да все чики-пуки. А для мморпг такая штука поможет? ну запилить max_connections=999999, это норм?

@Dolphin · 27.06.2013, 16:47

Сообщение от lawliet93

ну запилить max_connections=999999

Сервер может упасть если не выдержит нагрузки

@lawliet93 · 27.06.2013, 17:01

Сообщение от Dolphin

Сервер может упасть если не выдержит нагрузки

значит все так делают, но надо сервер сильный?

@sKotenok · 28.06.2013, 01:31

Сообщение от lawliet93

значит все так делают, но надо сервер сильный?

Вообще-т для этого и придумали кластеры и пулы соединений. мускуль - не лучший выбор для мморг, но небольшие объемы (вроде 1000 клиентов) вполне потянет.

@lawliet93 · 28.06.2013, 01:36

Сообщение от sKotenok

Вообще-т для этого и придумали кластеры и пулы соединений. мускуль - не лучший выбор для мморг, но небольшие объемы (вроде 1000 клиентов) вполне потянет.

да эт я для начала на мускуле сделаю, а потом буду юзать NoSQL, оно же вроде самое быстрое и крутое

@sKotenok · 28.06.2013, 02:05

@lawliet93, NoSQL - это общее название СУБД, не использующих язык запросов SQL. SQL не очень хорош, точнее - совсем плох при очень частых и мелких выборках/вставках. Но, допустим, на Mongo всё хоть и может быть быстрее, чем на мускуле (раза в 2) - проблема будет та же.
Хм.. Возможно я не понимаю назначение БД. Лучше поставить вопрос по другому - что именно вы собрались хранить в БД? не синхронизацию координат персонажей же..

А раз так и будет какой-никакой бэкенд - в сотнях потключений нет смысла (разве что БД на 100 ядрах суммарно крутится), делаете пул, возможно с внутренним кэшем, 50 одновременных коннектов на 1000 клиентов вполне хватит (вы в проблемы с железом раньше упрётесь).

@lawliet93 · 28.06.2013, 12:15

Сообщение от sKotenok

@lawliet93, NoSQL - это общее название СУБД, не использующих язык запросов SQL. SQL не очень хорош, точнее - совсем плох при очень частых и мелких выборках/вставках. Но, допустим, на Mongo всё хоть и может быть быстрее, чем на мускуле (раза в 2) - проблема будет та же.
Хм.. Возможно я не понимаю назначение БД. Лучше поставить вопрос по другому - что именно вы собрались хранить в БД? не синхронизацию координат персонажей же..

А раз так и будет какой-никакой бэкенд - в сотнях потключений нет смысла (разве что БД на 100 ядрах суммарно крутится), делаете пул, возможно с внутренним кэшем, 50 одновременных коннектов на 1000 клиентов вполне хватит (вы в проблемы с железом раньше упрётесь).

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

Новые блоги и статьи Все статьи Все блоги /
Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .
SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .	SDL3 для Web (WebAssembly): Работа со звуком через SDL3_mixer 8Observer8 08.02.2026 Содержание блога Пошагово создадим проект для загрузки звукового файла и воспроизведения звука с помощью библиотеки SDL3_mixer. Звук будет воспроизводиться по клику мышки по холсту на Desktop и по. . .

@fedwq 2 / 2 / 0 Регистрация: 24.06.2012 Сообщений: 56

	Как организовать многопоточный доступ к бд? 20.07.2012, 22:41. Показов 5111. Ответов 9 Метки нет (Все метки) Дано: Сервер на C#, подразумевает обслуживание большого количества клиентов(соединений) и каждый в своем потоке. Бд одна и каждый клиент время от времени хочет либо получить данные из бд, либо записать данные в бд. Для чтения использую DataAdapter, но иногда выскакивает ошибка "There is already an open DataReader associated with this Connection which must be closed first". Я так понимаю, 2 потока не могут одновременно читать данные. Приложение сервера использует одно соединение к MySQL на всех. Как можно сделать многопоточный доступ к базе данных? Или многопоточность MySQL - это ложь и провокация? Можно ли организовать многопоточный доступ путем присвоения каждому клиенту своего соединения с бд. Какое максимальное количество соединений с MySQL и как его изменить? 0

@lawliet93 17 / 5 / 3 Регистрация: 22.03.2011 Сообщений: 329
	27.06.2013, 13:54
	Такая же проблема, так и не нашел решения. Максимальное количество подключений к бд вроде устанавливается при установке мускула, ну и изменить его легко, но сам подумай, если клиентов будет много, вот я, например, хочу попробовать запилить небольшую ммо рпг, а там может быть и 1000 и больше клиентов и каждому нужен доступ к бд, эт уже слишком. НО! Ведь веб-серверы тоже обслуживают большое количество пользователей и юзается 1 бд и как-то оно работает же. 0

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	28.06.2013, 02:05
	@lawliet93, NoSQL - это общее название СУБД, не использующих язык запросов SQL. SQL не очень хорош, точнее - совсем плох при очень частых и мелких выборках/вставках. Но, допустим, на Mongo всё хоть и может быть быстрее, чем на мускуле (раза в 2) - проблема будет та же. Хм.. Возможно я не понимаю назначение БД. Лучше поставить вопрос по другому - что именно вы собрались хранить в БД? не синхронизацию координат персонажей же.. А раз так и будет какой-никакой бэкенд - в сотнях потключений нет смысла (разве что БД на 100 ядрах суммарно крутится), делаете пул, возможно с внутренним кэшем, 50 одновременных коннектов на 1000 клиентов вполне хватит (вы в проблемы с железом раньше упрётесь). 0