Ускорение доступа к базе данных - PullRequest
1 голос
/ 12 января 2010

У меня есть база данных, содержащая записи, собираемые каждые 0,1 секунды, и мне нужно усреднять данные за определенный день до одного раза в 20 минут. Поэтому мне нужно возвращать данные за день, усредненные на каждые 20 минут, что составляет 24 * 3 значения.
В настоящее время я делаю отдельный вызов AVG в базу данных для каждого 20-минутного периода в течение дня, который составляет 24 * 3 вызова. Мое соединение с базой данных кажется немного медленным (оно удаленное), и для выполнения всех усреднений требуется ~ 5 минут. Будет ли быстрее выполнить один запрос, в котором я получу доступ к данным за весь день, а затем усредню их каждые 20 минут? Если это поможет ответить на вопрос, я должен сделать некоторую арифметику с данными перед усреднением, а именно умножить несколько столбцов таблицы.

Ответы [ 7 ]

1 голос
/ 12 января 2010

Вы можете рассчитать количество минут с полуночи, например:

datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)

Если вы разделите это на 20, вы получите номер 20-минутного интервала. Например, 00:10 будет попадать в интервал 0, 00:30 - в интервал 1, 15:30 - в интервал 46 и т. Д. С помощью этой формулы вы можете группировать по 20-минутным интервалам, например:

select
    (datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)) / 20 as IntervalNr
,   avg(value)
from      YourTable
group by  (datepart(hh,datecolumn)*60 + datepart(mi,datecolumn)) / 20

Вы можете сделать математику внутри вызова avg, например:

avg(col1 * col2 - col3 / col4)
1 голос
/ 12 января 2010

В целом, сокращение количества запросов - хорошая идея. Агрегируйте и выполняйте в запросе любую арифметику / фильтрацию / группировку (т. Е. В базе данных), а затем выполняйте «итеративные» вычисления на стороне сервера (например, в PHP).

0 голосов
/ 12 января 2010

Если возможно, добавьте столбцы в таблицу, вычислите и сохраните продукт столбца и индекс интервала (см. Публикацию Andomar) каждый раз, когда вы публикуете данные в базу данных.

0 голосов
/ 12 января 2010

Если вы отправляете много данных, и соединение является узким местом, то как и когда вы группируете и отправляете данные, не имеет значения. Нет хорошего способа отправлять 100 МБ каждые 10 минут через модем 56 КБ. Определите размер ваших данных и пропускную способность и убедитесь, что вы даже можете их отправить.

Это говорит:

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

0 голосов
/ 12 января 2010

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

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

0 голосов
/ 12 января 2010

Как насчет хранимой процедуры в вашей базе данных? Если ваш движок базы данных не поддерживает ни одного, как насчет того, чтобы иметь скрипт или что-то, выполняющее математику и заполняющее отдельную «среднюю» таблицу на сервере базы данных. Тогда вам нужно только читать средние значения с удаленного клиента только один раз в день.

0 голосов
/ 12 января 2010

Чтобы быть уверенным, будет ли он быстрее или нет, его следует измерить.

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

...