Как лучше (потенциально) сотням мобильных клиентов получить доступ к базе данных MySQL? - PullRequest
5 голосов
/ 09 июня 2011

Итак, вот сделка. Я разрабатываю приложение для Android (хотя это может быть и любая другая мобильная платформа), которое иногда отправляет запросы на сервер (который написан на Java). Затем этот сервер будет искать запрос в базе данных MySQL и отправлять результаты обратно в Android. Хотя это звучит довольно обобщенно, вот некоторые особенности:

  1. Android будет устанавливать новое TCP-соединение с сервером при каждом запросе. Сервер находится географически близко, Android потенциально может много перемещаться, и, поскольку приложение Android может работать часами, отправляя только несколько запросов, это казалось наилучшим использованием ресурсов.

  2. Сервер может потенциально иметь сотни (или, возможно, даже тысячи) этих запросов одновременно.

  3. Поскольку каждый запрос выполняется в своем собственном потоке, каждому запросу по крайней мере понадобится свой собственный оператор (и он может иметь свое собственное соединение).

В данный момент сервер настроен на одно Соединение с базой данных, а затем создает новый оператор для каждого запроса. Мои вопросы для тех из вас, кто имеет некоторый опыт работы с базами данных (в частности, MySQL, поскольку это база данных MySQL):

a) Безопасно ли создавать потоки для одного оператора на поток из одного соединения? Насколько я понимаю, просто ищу подтверждение.

б) Есть ли какой-нибудь потокобезопасный способ для нескольких потоков использовать один PreparedStatement? Все эти запросы будут в значительной степени идентичны, и, поскольку каждый поток выполнит только один запрос и затем вернется, это было бы идеально.

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

d) Лучше ли использовать хранимые процедуры SQL для всего этого?

Будем весьма благодарны за любые подсказки / комментарии / предложения из вашего опыта в этих вопросах.

EDIT:

Просто чтобы уточнить, андроид отправляет запросы по сети на сервер, который затем запрашивает базу данных. Андроид напрямую не связывается с базой данных. В основном меня интересуют передовые практики для соединения сервера с базой данных.

Ответы [ 3 ]

5 голосов
/ 09 июня 2011

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

Вам необходимо создать новые операторы / подготовленные операторы в каждом потоке, который будет обращаться к базе данных, они НЕ являются потокобезопасными. Я настоятельно рекомендую использовать подготовленные операторы, поскольку вы получите эффективность и защиту от атак с использованием SQL-инъекций.

Хранимые процедуры ускорят ваши запросы к базе данных, так как план выполнения уже составлен и сохранен - ​​настоятельно рекомендуется использовать, если вы можете.

Вы смотрели на кеширование данных вашей базы данных? Взгляните на spymemcached, если вы можете, это отличный продукт для сокращения количества обращений в ваше хранилище данных.

2 голосов
/ 09 июня 2011

Исходя из моего опыта, вы должны посвятить немного времени обертыванию базы данных в веб-сервисе. Это выполняет две вещи:

  1. Вы вынуждены изучить данные для более широкого потребления
  2. Вы облегчаете использование данных новыми потребителями

Немного больше времени на разработку, но прямые подключения к базе данных через открытую сеть (Интернет) более проблематичны, чем указание того, что можно получить с помощью метода.

1 голос
/ 09 июня 2011

Используйте пул соединений, такой как Commons DBCP. Он будет обрабатывать все вещи, о которых вы беспокоитесь, из коробки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...