memcached с применением java и php - PullRequest
0 голосов
/ 02 ноября 2010

У меня есть приложение, которое включает в себя запись состояния до 8000 устройств каждые 1-2 минуты через приложение Java и сохранение идентификатора устройства, времени и состояния в таблице в базе данных.

Следующим компонентом этого приложения является интерфейс PHP, который отображает самое последнее состояние этих устройств (тех, которые назначены пользователю, вошедшему в систему, может быть максимум 500 одновременных пользователей, то есть просмотр 16 устройств на каждом, но больше чем вероятно средняя нагрузка 50-100 пользователей). Приложение также будет печатать отчеты о состоянии устройства с течением времени.

Я подумывал об использовании memcached в java-приложении для хранения самого последнего статуса для каждого deviceid, а затем о том, чтобы приложение php просто получило доступ к memcached для заполнения экрана. Отчеты о предыдущем статусе по-прежнему поступают из базы данных, поскольку они запускаются нечасто.

Моя путаница возникла при принятии решения о том, будет ли производительность достойной записи memcached в это приложение, поскольку производительность memcached, по-видимому, реализуется с помощью многократных попаданий на обновление кэша. Это приложение, скорее всего, будет иметь несколько обновлений (но не напрямую из базы данных, а непосредственно из приложения) на одно чтение кэша. Но сохранит чтение в таблице состояния (2-3 ГБ) разумного размера.

Кроме того, есть ли какие-либо проблемы взаимодействия при записи / чтении в memcached из API разных языков?

1 Ответ

0 голосов
/ 02 ноября 2010

У вас, вероятно, уже есть эффективный многоязычный механизм цепочки, встроенный в вашу RDBMS!Маловероятно, что это значительно улучшит механизмы кэширования и параллелизма, встроенные в вашу систему баз данных.Ваше время было бы лучше потратить на настройку SQL, чтобы обеспечить максимальную выгоду при использовании этих механизмов.(Обеспечение параметров параллелизма в SELECT позволяет выполнять «грязное чтение», сохранять единицы работы (обработка между BEGIN TRANSACTION и COMMIT) максимально короткими и т. Д. И т.-

set transaction isolation level read uncommitted;

позволит вам читать любые вставленные строки до того, как они будут зафиксированы, и полностью игнорирует любые блокировки и параллелизм.Это повысит вашу производительность и не вызовет никаких проблем, поскольку Java-часть приложения вставляется только.

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