Как работать с базой dbf 370 Mb?

Question

[maiskiykot]

Первый раз столкнулся с такой проблемой. Есть база данных в текстовом файле 370 Mb.
В ней есть поля field1, field2,field3 и т.д. Так вот field2 может повторяться до ста раз, а field1 и field3 - уникальные. Задача вытащить по уникальному массиву данных $field 2 все записи из базы. Т.е. получится 180000 строк с объединенными данными field1, field3. Сейчас в базе 3280000 строк. Алгоритм я построил, но из-за того, что приходится каждый раз полностью шерстить базу, выборка идет со скоростью 3000-4000 строк в сутки. Проблема в том, что просто выборкой дело не обходится и каждую строку нужно еще обрабатывать при помощи PHP. Как ускорить?

Answer 1

[DevMan]

загоните данные в mysql/postgres/etc и гоняйте свои выборки.

Comments

[maiskiykot]

Мне нужно создать выборку на основе PHP. Чем мне мускуль поможет, если приходится делать преобразования в пыхе? Т.е. к сейчасному гемору со скоростью добавится гемор с мускулем?

[DevMan]

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

[maiskiykot]

Вы не поняли. Не получается выдрать все простым перебором. Два поля приходится преобразовывать в массив и его по-любому нужно делать и хранить в пыхе. Тогда вопрос: как мускуль поможет все ускорить, если все равно будет и пых работать и мускуль?

[DevMan]

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

[maiskiykot]

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

[DevMan]

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

[maiskiykot]

база даст выборку к примеру 100 строк по field2, однако она не сможет объединить 100 field1 в array1 а 100 field2 в array2, а потом положить это все в 1 строку. Т.е. без пыха не обойтись.

[DevMan]

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

[maiskiykot]

Пока что пошел по пути удаления найденных строк из базы. Объем уже сократился на 15 Мб. Может и скорость подрастет.

[maiskiykot]

Однако засунул в mysql - раз в 10 ускорилось.

[DevMan]

maiskiykot, собственно, о чем я и говорил)

[maiskiykot]

Я просто первый раз с такими объемами сталкивался. Как правило предпочитаю файлы парсить чем базу.

Answer 2

[GavriKos]

выборка идет со скоростью 3000-4000 строк в сутки

Вы что то сделали очень неправильно. 3 миллиона строк и 400 мегабайт прекрастно грузятся целиком в оперативу и там шерстятся достаточно быстро.

Comments

[maiskiykot]

Однако нет, не выходит каменный цветок. Повторюсь - чтобы вытащить одну строку выборки нужно до ста раз перебрать 3280000 строк. Получается где-то строка в 2секунды.

[GavriKos]

maiskiykot, не нужно, если подходить по умному типа с сортировкой, хешами, хеш-таблицами, правильными структурами данных и прочим.

[DevMan]

GavriKos, насколько я понял, он просто парсит файл, а не работает с ним как с базой.

[maiskiykot]

Структура не моя. Данные тоже. Сортировка тоже не особо поможет, ибо там каша такая, что черт ногу сломит.

[GavriKos]

maiskiykot, Ну как минимум оттсортируйте по field2 - и тогда очередные максимум 100 записей будут находится < чем за n - потому что они подряд будут идти. Вот вам уже и оптимизация.

[GavriKos]

DevMan, не ну если на каждый поиск строки файл заново открывается для чтения - то тогда да, будет сутками грузить винт.

[maiskiykot]

Базу загоняю в session и там обрабатываю. Коряво, но работает. Они и так идут подряд - field2, но приходится делать цикл в цикле, т.е. строка xxxyyyzzz повторяется неизвестное количество раз и поэтому проход не прервать по break, а каждый раз проходит до конца.

[maiskiykot]

Вот что приходится делать 180000 раз

foreach ($_SESSION['dom'] as $key=>$value)
         {
              if (preg_match("![0-9]{19}!",$value,$matches) AND preg_match("!^".trim($base[$i])."!",$matches[0]))
              {    
               $str = explode(",ДОМ",$value);
               $str1 = explode(",",trim($str[1]));
               $doma[] = trim($str[0]);
               if (!in_array($str1[2],$code))
               $code[] = $str1[2];
               unset($_SESSION['dom'][$key]);
              }
          }
           
            $domy = implode("",$doma);
            $cod = implode(",",$code);
            
            $puts = $domy."::".$cod."::".base_convert(trim($base[$i]), 10, 36)."\n";
            file_put_contents("base.dat", $puts, FILE_APPEND);
        
      $z++;
       
      }

[GavriKos]

maiskiykot, ох бл... Ну во первых - выкидываете из цикла запись в файл! Вот прям нафиг. Пишите в память! Потом когда весь процессинг закончите - сливайте целиком за 1 проход в файл БЕЗ всяких APPEND. Во вторых - я честно хз что из себя представляет session в пхп, но советую посмотреть, какая сложность у него для операций удаления и поиска. Если большая - использовать другую структуру данных с более быстрыми операциями. В третих у вас очень много операций со строками - они работают долго. Возможно в данном случае будет правильнее составить т.н. карту соответствий чисто на индексах, и потом исходя из индексов уже на этапе вывода сформировать что нужно.
Но я вангую - уберете запись в файл - сразу будет сильно быстрее.

[maiskiykot]

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

[GavriKos]

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

[maiskiykot]

Вот строка этой монстробазы - в первом поле тоже запятые для разделения.

10,11,12,13,14,15,16,17,18,19,2,3,4,5,6 , ,ДОМ ,2200000401101080001,659305,2204, ,01405000000,

[DevMan]

рукалицо.жпег...

дядь, а зачем ты гоняешь это дело под веб-сервером вместо консоли?