2013-07-30 3 views
1

У меня есть набор данных в mysql с 150 строками. У меня есть набор из 2 для циклов, которые выполняют математические вычисления на основе некоторых пользовательских входов и набора данных. Код выполняет вычисления для 30-строчных окон и накапливает результаты для каждого 30-строчного окна в массиве. Я имею в виду, что я делаю «цикл» вычислений в строках 0-29, затем 1-30, затем 2-31 и т. Д. Это приведет к 120 «циклам».Как перебирать «окно» данных в наборе данных?

Сейчас цикл устанавливается как так (есть несколько полей, я просто обрезается код для простоты этот вопрос.

$period=30; 
    $query = "SELECT * FROM table"; 
    $result = mysql_query($query); 
    while ($row = mysql_fetch_assoc($result)){ 
     $data[] = array("Date" => $row['Date'], "ID" => $row['ID']); 
    } 
    for($i=0;$i<(count($data)-$window);$i++){ 
     for($j=0;$j<$window;$j++){ 
      //do calculations here with $data[] 
      $results[$i][$j]= calculations; 
     } 
    } 

Это хорошо работает для числа строк, у меня есть, однако. , Я открыл сценарий для большего набора данных (1700 строк) с другим окном (360 строк) .Это означает, что экспоненциально больше итераций. Это дало мне ошибку в памяти. Некоторое быстрое использование memory_get_peak_usage() показало, что память будет постоянно увеличиваться.

Я начинаю думать, что поиск петли через этот массив данных чрезвычайно трудоемкий ous, особенно когда «окно» перекрывается во многих «циклах». Пример: цикл 0 проходит через строки 0-29. Цикл 1 проходит через строки 1-30. Таким образом, оба этих цикла имеют ряд данных, которые им нужны, но я говорю PHP, чтобы каждый раз искать новые данные.

Есть ли способ структурировать это лучше? Я получаю отчасти заблуждение о том, как управлять этими параллельными циклами.

+0

Ответ зависит от того, что вы делаете в фрагменте кода, который вы оставили. Если вам лучше описать то, что вы на самом деле делаете, вы получите лучшую помощь. – RiggsFolly

+0

Я просто делаю базовую математику с пользовательскими вводами ($ _POST) и набором данных. –

ответ

1

Я думаю, что массив, который продувает память, будет массивом $result. В вашем маленьком образце это будет 2-мерный массив с ячейками 150x149. array(150, 149). На 144 байта на элемент, что 3218400 байт чуть выше 3 Meg + оставшееся пространство ковша.

У вас второй более крупный образец будет array(1700,1699). При 144 байтах на элемент, который составляет 415,915,200 байт, это чуть более 406 мегабайт + оставшееся пространство ковша, просто чтобы удерживать результаты ваших вычислений.

Я думаю, вам нужно спросить, действительно ли вам нужно хранить все эти данные. Если вы действительно это сделаете, вам, возможно, придется придумать другой способ его хранения.

Я не вижу попыток совершать вызовы с нечетными базами данных 1000, так как это только добавит к накладным расходам, поскольку вам все равно нужно поддерживать список результатов в массиве hugh.

+0

Да, я никогда не думал о математике по размеру массива. Просветление. Возможно, для большего набора данных просто имеет смысл сделать фоновый процесс, который пользователь может вернуться к нему позже, и хранить информацию в базе данных в течение некоторого количества часов. Это даже не факт, что я считаю, что моя реальная структура массива глупа, потому что я определил массивы странно и просто продолжал работать с ним. Это что-то вроде $ results [0] [0] [$ i] [$ j] ... что, вероятно, экспоненциально увеличивает его. Doh! –

0

SQL-Way

Вы можете сделать это с помощью LIMIT

$period = 30; 
$cycle = 0; // 
$query = "SELECT * FROM table LIMIT $cycle,$period"; 

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

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

+0

Итак, как вы думаете, лучше ли выполнять 120 вызовов базы данных, а не делать 1 вызов базы данных и помещать их в массив и искать через этот массив 120 раз? Я спрашиваю, потому что, если мы экстраполируем этот пример на более крупный набор данных (1700 строк), он заканчивает выполнение 1300 или около того вызовов БД. –

+0

Нет, это, наверное, не лучше. Однако при выполнении этих вызовов результаты будут кэшироваться. –

Смежные вопросы