Дело не в том демон это или приложение. (Обработка данных должна провисходить раз в 1-3 месяца, но быстро, а потом перерыв - собираются новые данные.) Дело в оптимальных алгоритмах хеш-массива (двумерного) и регулярок (ну это не так страшно, здесь много не проиграть). Добавлено спустя 6 минут 8 секунд: Напрямую mysql врятли это потянет, а держать данные не в массивах php, а в HEAP таблицах mysql может и получится.
при необходимости обработать 300мб/сек, надо писать на сях и с умом и железо соотв. пхп это крутой язык, он оч быстрый. Но для скриптового языка. Пхп крутой и быстрый для скриптового языка. Добавлено спустя 1 минуту 50 секунд: но можно распаралеллить. бюджет роляет.
Вы не правы по: - PHP однопотоковый, поэтому на 4-х ядерном процессоре получите 1/4 максимально возможного (реально, ещё меньше) - размер INSERT имеет значение, но зависимость не линейная - скорость вначале растёт, потом ограничивается движком БД "бодаться" будут, но тут уже зависит от того, что Уже. Пока я так и не понял, что у Вас "медленно" - PHP? mySQL? всё вместе?
Медленно и то и другое, но на данный момент главная проблема "Ошибка сегментирования". Как мне уже известно на данный момент, php отправляет в базу 50 миллионов записей, а mysql получает только 5 миллионов. Пока выясняю когда и как пропадают остальные 45.
Ээээ, не понял - если у Вас основное время уходит на вставку данных, при чём тут СИ? Количество вставок в БД имеет предел, пишите хоть на асемблере. Если у Вас основное время тратится на вставку, это и оптимизируйте. Наверняка у Вас индексы постоянно перестраиваются, логирование включено, неоптимальные настройки движка для конкретики и т.п. Добавлено спустя 2 минуты 59 секунд: Какая версия PHP?
Сейчас у меня пропадает 90% данных, поэтому невозможно установить кто (mysql или php) тратит больше времени. На Си возможно придется переписывать, если не удастся победить "Ошибку сегментирования" в php. (сомневаюсь, что Си в этой задаче в разы выиграет у php). А чему равен предел вставок в mysql? Версия php 5.0.41
Смешно. microtime() ещё никто не отменял (про логирование и пр. я уж не упоминаю) - поставьте пяток строк и будете знать. (повторюсь, - не нужно пихать все 50 млн строк одним insert-ом и даже 5 млн не нужно, ни к чему хорошему это не приведёт) Если без ухищрений и тонких настроек - несколько тысяч в секунду. Точное значение зависит от многих параметров, в т.ч. от структуры самой БД. Версия слишком старая - замените на новую и попытайте заново. Но, по хорошему Вам надо менять алгоритм - неправильный он у Вас.
От php в этой задаче придется отказаться - в памяти нужно хранить больше данных, чем он способен. Ошибка не устраняется уменьшением длинны строки. B большое количество мелких вставок более существенно замедляет работу mysql, чем наличие индексов в таблице.
Да при чем тут мелкие вставки. Размер запроса регулируется в конфиге. Если для вас при вашем размере строки и 10 МБ будут мелкими, то вам возможно надо сменить мускул на ченить типа "ключ-значение". Или идти в кластер. При таком количестве строк, неужели нельзя никак распаралелить это дело?
Ну попробуйте, - потом расскажите почему опять всё медленно Согласен с igordata - Вас заклинило. Вам надо надо найти другое решение, а не "добивать" существующее.
Мелкие вставки - когда я одним insert вставляю1-1000 записей, а крупные 100000-1000000 записей. Создаваемая таблица временная, но оперативки на нее точно не хватит. К каждому ключу привязаны два числовых значения. Ключи не уникальны. Уникальных ожидается до 500000. В следующей задаче делаются выборки по каждому значению ключа. Я не знаю чем типа "ключ-значение" можно обогнать mysql. А любое распараллеливание упрется в сохранение обработанных данных.
вы индексы до или после вставки создаете? и прям при создании таблицы? что значит временная? тип какой?
Индексы сожрут меньше времени если их создать при создании таблицы.(если по одной записи не вставлять). Временная, значит данные из нее будут удалены после прочтения. Тип myisam.
Короче мне кажется топик себя исчерпал. дальнейшее обсуждение имеет смысл при указании целей и задач, бюджета и парка железа.
я бы посоветовал выложить куда-нибудь на обозрение код обработки и тестовую базу. тогда можно вести разговор.