Сервер или база данных

Question

Привет, ребята, мне нужно ваше мнение. Я нахожусь в ситуации, когда мне нужно использовать ajax, поэтому мне нужно запрашивать информацию о пользователях каждые 30 секунд ..... что более эффективно, в первую очередь запрашивает сервер (скажем, проверьте текстовый файл) во-первых) и, если есть обновление для информации о пользователе, выполните полный запрос к базе данных или просто напрямую запрашивайте базу данных каждые 30 секунд. Пожалуйста, объясните ваши аргументы, чтобы я мог взвесить свое решение ....... спасибо в заранее.

Answer 1

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

Это слишком много для минимального усиления, иначе

Answer 2

Если у вас небольшое количество пользователей и мало веб-клиентов, то внедрите самое простое решение.

Причина: нет необходимости оптимизировать что-то подобное, если только у вас нет серьезных проблем с производительностью. Я бы начал думать об этом, если:

• В БД тысячи пользователей
• Эта информация запрашивалась каждую секунду сотнями веб-клиентов.

Но если у вас 10 пользователей, то это, вероятно, означает, что 10 веб-браузеров запрашивают эту информацию каждые 30 секунд. Вы должны беспокоиться о плохом процессоре на ваших серверах, потому что он будет скучно до смерти;)

Answer 3

Я бы измерил бы сначала , если бы более простая версия (кажется, сначала запрашивает базу данных непосредственно) не достаточно .

Тогда, если это не достаточно хорошо, ищите лучшее решение (все еще измеряя результаты).

Есть много , если и зависит , чтобы дать вам хороший совет удаленно.

Answer 4

Не уверен, что вижу необходимость в кешировании, но, может быть, я наивен? Как Cache узнает, изменились ли данные или нет?

SELECT ... lots of columns
FROM MyTable
WHERE UserID = 1234
      AND LastUpdated > @MyLastUpdated

будет выполнять какую-либо серьезную работу только тогда, когда AND - это правда? Если вы вернете ноль строк назад, это не изменилось - или UserID = 1234 больше не существует, но если вам нужно знать, что запрос можно изменить, чтобы он тоже возвращался). Таким образом, я не считаю необходимым делать запрос «Имеется ли UserID = 1234, измененный с момента @MyLastUpdated», за которым следует полномасштабный SELECT *.

Если вы получите значение LastUpdated в списке столбцов, сохраните его, затем оно будет доступно в качестве параметра при следующей проверке изменения UserID = 1234.

(LastUpdated - это не время, когда вы последний раз проверяли, а время последнего обновления записи, разумеется, но его нужно каждый раз создавать по одним и тем же часам, если не в самом окне SQL, а на ПК клиента! !) и учитывая то, что происходит с летним временем осенью.)

Answer 5

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

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

Я также советую вам изучить memcachedb (или любой ключ / значение DB DB ) для кодирования вашего промежуточного программного обеспечения.

Если у вас не слишком много пользователей, можно использовать схему опроса.