Первый раз столкнулся с такой проблемой. Есть база данных в текстовом файле 370 Mb.
В ней есть поля field1, field2,field3 и т.д. Так вот field2 может повторяться до ста раз, а field1 и field3 - уникальные. Задача вытащить по уникальному массиву данных $field 2 все записи из базы. Т.е. получится 180000 строк с объединенными данными field1, field3. Сейчас в базе 3280000 строк. Алгоритм я построил, но из-за того, что приходится каждый раз полностью шерстить базу, выборка идет со скоростью 3000-4000 строк в сутки. Проблема в том, что просто выборкой дело не обходится и каждую строку нужно еще обрабатывать при помощи PHP. Как ускорить?
Мне нужно создать выборку на основе PHP. Чем мне мускуль поможет, если приходится делать преобразования в пыхе? Т.е. к сейчасному гемору со скоростью добавится гемор с мускулем?
maiskiykot, насколько я понял, вы сейчас просто парсите файл, а не работаете с ним как с бд.
если это так, то перенос в бд ускорит сами выборки и аггрегацию данных, это будет быстрее, чем колбасить все пыхом.
если это не так, то мой совет можно удалить.
Вы не поняли. Не получается выдрать все простым перебором. Два поля приходится преобразовывать в массив и его по-любому нужно делать и хранить в пыхе. Тогда вопрос: как мускуль поможет все ускорить, если все равно будет и пых работать и мускуль?
maiskiykot, невозможно ответить не понимая структуру данных и что надо получить.
могу только сказать, что сервер бд со многими задачами способен справится быстрее, чем полный перебор данных на клиентской стороне.
Я думал просто ускорить процесс. Если бы можно было простым перебором строк выдрать данные, то тут не было б проблем, но получается, что без пыха не обойтись.
maiskiykot, дело не только в пыхе, дело в том, что субд заточены на выборку/обработку больших объемов данных (например, тот же постгрес умеет работать не только с простыми типами данных, но и с массивами) и справляются с этим лучше/быстрее клиентского кода.
база даст выборку к примеру 100 строк по field2, однако она не сможет объединить 100 field1 в array1 а 100 field2 в array2, а потом положить это все в 1 строку. Т.е. без пыха не обойтись.
maiskiykot, сможет, если ее об этом попросить и она это умеет (я уже написал выше, что постгрес умеет в массивы).
я не предлагаю отказываться от пыха совсем, я предлагаю переложить возможный максимум обработки (хотя бы первичную агрегацию данных) на субд.
Однако нет, не выходит каменный цветок. Повторюсь - чтобы вытащить одну строку выборки нужно до ста раз перебрать 3280000 строк. Получается где-то строка в 2секунды.
maiskiykot, Ну как минимум оттсортируйте по field2 - и тогда очередные максимум 100 записей будут находится < чем за n - потому что они подряд будут идти. Вот вам уже и оптимизация.
Базу загоняю в session и там обрабатываю. Коряво, но работает. Они и так идут подряд - field2, но приходится делать цикл в цикле, т.е. строка xxxyyyzzz повторяется неизвестное количество раз и поэтому проход не прервать по break, а каждый раз проходит до конца.
maiskiykot, ох бл... Ну во первых - выкидываете из цикла запись в файл! Вот прям нафиг. Пишите в память! Потом когда весь процессинг закончите - сливайте целиком за 1 проход в файл БЕЗ всяких APPEND. Во вторых - я честно хз что из себя представляет session в пхп, но советую посмотреть, какая сложность у него для операций удаления и поиска. Если большая - использовать другую структуру данных с более быстрыми операциями. В третих у вас очень много операций со строками - они работают долго. Возможно в данном случае будет правильнее составить т.н. карту соответствий чисто на индексах, и потом исходя из индексов уже на этапе вывода сформировать что нужно.
Но я вангую - уберете запись в файл - сразу будет сильно быстрее.
Запись в файл для страховки от ошибок. При записи в память постоянно вылетает с ошибкой по памяти, а значит - возврат в исходную точку! Строковых операций избежать невозможно, ибо только ради них и затеял сыр-бор. По-другому тут не выехать. Другой структуры данных нет - есть этот монструозный файл и баста.
maiskiykot, причем здесь файл? Вы в курсе что есть разные структуры - массив, словарь, хешсет, список (с разными связями), дерево, хештаблица и еще пачка всякого? И у каждой структуры разное время доступа к элементам, поиска, удаления, добавления? Строковые операции нужно минимизировать, или вынести их на этап сериализации, я уже написал как.
Я не понимаю, вам дают советы - а вы упираетесь рогом и все. Вы вообще какого ответа ожидаете? Попробовали бы! Пока что ваш код далек от оптимального в плане производительности.