Предлагаю испытание или соревнование: берём общедоступный большой текстовый файл, описываем схему БД и пытаемся как можно быстрее перегнать одно в другое. Результаты рассматриваем под лупой и берем на вооружение. Предлагаю взять дамп вопросов и ответов stackoverflow (XML) и согласовать структуру таблицы MySQL. Сорцы зальем на github, у каждого участника свой бранч в проекте. В мастере только описание. Сливаться ветки врядли будут, в одном репозитории просто для кучности. На чтение будет доступно всем, на изменение только команде участников. Как сравнивать: создаем эталонную виртуалку с Linux, git, php и mysql. Vagranfile включаем в проект. Если внезапно чье-то решение потребует установки чего-то сверх эталона, это должно быть описано как provision к вагранту. Естественно абсолютные цифры производительности будут зависеть от хост-машины, но зато тесты будут сравнимы и доступны каждому. Итого, требования к участнику: владение git+github, установленный Vagrant c VirtualBox. Кто хочет поучаствовать? UPDATE: файл можно качнуть через torrent, не обязательно брать всё, выделите только Posts со stackoverflow. Это около 6Гб в архиве. Распакуется в XML 29Гб.
Да и так известно сколько будет, - всё уже тестировали и не раз и здесь об этом писали (или в соседнем форуме). Максимально: <= Скорости диска (максимум 30-500 Мб/сек) <= Числу записей в БД (максимум 30000 зап/сек) <= Скорости парсера строк (PHP - максимум порядка 100 000 строк/сек) Хотя ... если скучно и мозги чешутся, то можно и поразвлекаться конечно
блин, я бы с удовольствием по участвовал, но могу только по наблюдать ( мне кажется, это интересно сделать на PHP и сравнить время выполнения ( Хотя на C++ будет ваще летать...
надо за один запрос в БД добавлять много записей, т.е. в одном запросе: Код (PHP): INSERT INTO `tb_name` (.......) VALUES (.......), (.......), (.......), (.......); если добавлять по одной записи то жесть будет, часов 5 если мне не изменяет память, а если по 200 - 500 за запрос, то где то за 20 минут.
может имело бы смысл сразу написать какой? странно у меня именно так вписывалось в sql файл и потом не было ни каких проблем.
[vs], задача не сводится к простому знанию MySQL load from file. Нет, большой XML интереснее. ))) Ну так как, есть желающие? За это вам ничего не будет.
не охота свой парсер писать правда. =( А с библиотечными я не работал, не знаю, умеют ли они xml кусочками кушать.
+1 На CSV я съел десяток собак пока достигнутый результат около 20 тысяч строк в секунду падает в БД XML куда более сложно разбирать и складывать ( просто ввиду того, что сам файл XML, содержащий то же кол-во инфы что и CSV как минимум раза в три "тяжелее" CSV (
Друзья, вы не поняли. Челлендж изначально не может быть комфортным Добавлено спустя 2 минуты 26 секунд: Представьте: у вас есть возможность поучаствовать в ралли. Вы приходите к оргам и говорите, что вам больше нравится гонять на бмв7 по автобану. Увы! Добавлено спустя 3 минуты 28 секунд: С вашими желательными условиями задача и правда превратится в тестирование скорости диска. Похоже с выбором места я ошибся.
Не обессудь, в контексте недавнего топика про разбор 2гб файла, показалось что именно в этом суть. Здесь надо определиться, парсить конкретный файл или парсить XML вообще. Во втором случае нужно реализовать RFC, это слишком для спортивного интереса =)
Другая тема это другая тема, я за ней не слежу. Кто не хочет, тот ищет причину. Кто хочет, тот ищет возможность.
Вы преувеличиваете. Выше же Вам сказали, что больше чем 30 тыс. записей/сек на поток принципиально не получится (реально - меньше). Остальное ограничение - диск. Ну и зачем тратить кучу времени на то, что и так известно? Лучше его потратить на что-нибуть более полезное. Кроме того, Вы сами не так давно участвовали в теме viewtopic.php?f=13&t=43563