Спустя 12 минут, 1 секунда (8.02.2009 - 13:23) LoneCat написал(а):
Насколько мне известно - увеличится, и порядочно.
Спустя 1 час, 43 минуты, 2 секунды (8.02.2009 - 15:06) Sylex написал(а):
да, увеличится
а зачем постоянно производить поиск?
а зачем постоянно производить поиск?
Спустя 1 минута, 41 секунда (8.02.2009 - 15:07) leo написал(а):
Не производить поиск , а время поиска файла при нажатии на ссылку скачивания
Спустя 1 минута, 48 секунд (8.02.2009 - 15:09) Adil написал(а):
Не буду открывать новую тему, а спрошу прямо тут. Ребята в бд (mysql) имеется свыше 5 миллионов слов. Требовалось пройтись по всем словам и если есть повторяющиеся, то удалить одно из слов.
Так самая первая и тупая мысль пройтись двумя циклами по всем словам сравнивая каждую с каждым, одним словом выходило 5 миллионов в квадрате.. сами понимаете, что комп просто не выдержал таких мучений..
Конечно есть возможность сделать это на выделенном сервере, он помощнее будет моего компьютера.. но хотелось бы услышать каким другим способом можно это реализовать?
P.S. еще по разному пытался это осуществить, но по любому комп не выдерживает.
Так самая первая и тупая мысль пройтись двумя циклами по всем словам сравнивая каждую с каждым, одним словом выходило 5 миллионов в квадрате.. сами понимаете, что комп просто не выдержал таких мучений..
Конечно есть возможность сделать это на выделенном сервере, он помощнее будет моего компьютера.. но хотелось бы услышать каким другим способом можно это реализовать?
P.S. еще по разному пытался это осуществить, но по любому комп не выдерживает.
Спустя 32 минуты, 53 секунды (8.02.2009 - 15:42) LoneCat написал(а):
Цитата (Nezabivaemiy @ 8.02.2009 - 16:09) |
Не буду открывать новую тему, а спрошу прямо тут. Ребята в бд (mysql) имеется свыше 5 миллионов слов. Требовалось пройтись по всем словам и если есть повторяющиеся, то удалить одно из слов. Так самая первая и тупая мысль пройтись двумя циклами по всем словам сравнивая каждую с каждым, одним словом выходило 5 миллионов в квадрате.. сами понимаете, что комп просто не выдержал таких мучений.. Конечно есть возможность сделать это на выделенном сервере, он помощнее будет моего компьютера.. но хотелось бы услышать каким другим способом можно это реализовать? P.S. еще по разному пытался это осуществить, но по любому комп не выдерживает. |
Ну можно например так:
SQL |
INSERT INTO new_table (id, word) SELECT id, word FROM old_table ON DUPLICATE KEY UPDATE word = word |
где:
new_table - новая таблица, с такой-же структурой
old_table - старая таблица
id - первичный ключ
word - столбец со словом
на столбец word в новой таблице нужно повесить индекс UNIQUE
Итого MySQL будет выбирать поочередно все слова из старой таблицы, и вставлять в новую, если слово будет совпадать - он вместо вставки будет обновлять содержимое ряда, что собственно в данном случае бессмыслено, оставлено ради того чтобы MySQL не вставлял новый ряд, в виде заглушки, но можно например реализовать счетчик повторяющихся слов, например так:
SQL |
INSERT INTO new_table (id, word, count) SELECT id, word, 0 FROM old_table ON DUPLICATE KEY UPDATE count = count + 1 |
Спустя 13 минут, 55 секунд (8.02.2009 - 15:56) Sylex написал(а):
Цитата (leo @ 8.02.2009 - 18:07) |
Не производить поиск , а время поиска файла при нажатии на ссылку скачивания |
однозначно гораздо быстрее, если по папкам разбито!
Спустя 2 минуты, 2 секунды (8.02.2009 - 15:58) Sylex написал(а):
да, хорошая идея... можно еще с LIMIT выполнять по определенному кол-ву, т.е. все равно очень долго будет
Спустя 2 часа, 36 минут, 40 секунд (8.02.2009 - 18:35) Sylex написал(а):
а по-моему лучше сразу выбрать уникальные записи, и их переливать поэтапно LIMIT'ами без всяких ON DUPLICATE KEY UPDATE
Спустя 5 минут, 18 секунд (8.02.2009 - 18:40) LoneCat написал(а):
Цитата (Sylex @ 8.02.2009 - 19:35) |
а по-моему лучше сразу выбрать уникальные записи, и их переливать поэтапно LIMIT'ами без всяких ON DUPLICATE KEY UPDATE |
Давай сравним
Спустя 4 минуты, 4 секунды (8.02.2009 - 18:44) Sylex написал(а):
LoneCat
базу у Незабываемого попросим?
базу у Незабываемого попросим?
Спустя 21 минута, 26 секунд (8.02.2009 - 19:06) LoneCat написал(а):
Итак, сначала я создал таблицу такого плана:
SQL |
CREATE TABLE IF NOT EXISTS `test` ( `id` int(10) unsigned NOT NULL auto_increment, `name` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 |
потом заполнил ее миллионом значений посредством:
PHP |
set_time_limit(0); |
В поле name скрипт записывает случайное значение в диапазоне от 0 до 1000, итого в миллионе записей каждый вариант должен повторяться в районе 1000 раз.
Затем собственно копирование данных, для этого были созданы две аналогичные первой таблицы, только в одной из них был установлен UNIQUE-индекс на поле name.
Запрос первый:
SQL |
INSERT INTO test2 (id, name) SELECT id, name FROM test ON DUPLICATE KEY UPDATE test2.name = test2.name |
1001 row(s) inserted. ( запрос занял 52.6245 сек. )
Запрос второй:
SQL |
INSERT INTO test3 (id, name) SELECT id, name FROM test GROUP BY name |
1001 row(s) inserted. Inserted row id: 1437 ( запрос занял 1.5818 сек. )
Итог:
Ты прав, проще и лучше сгруппировать дублирующиеся поля сразу, и потом уже их копировать в новую таблицу, причем лучше в разы.
Спустя 2 минуты, 55 секунд (8.02.2009 - 19:08) LoneCat написал(а):
Правда для чистоты эксперимента нужно было конечно сгенерировать строки, но это так, навскидку набрасывалось, за продуктами схожу, а то уж вечереет, и перенабъю
Спустя 18 минут, 26 секунд (8.02.2009 - 19:27) Sylex написал(а):
LoneCat
я тоже уже провел эксперимент, 180.000 строк... твой запрос висит уже 2 минуту, тогда как с уник. записями - 0,53 сек.
Просто что огромные данные выбираются - в этом тормоз. Нужно всегда стараться делать выборку минимальной.
я тоже уже провел эксперимент, 180.000 строк... твой запрос висит уже 2 минуту, тогда как с уник. записями - 0,53 сек.
Просто что огромные данные выбираются - в этом тормоз. Нужно всегда стараться делать выборку минимальной.
Спустя 2 минуты, 3 секунды (8.02.2009 - 19:29) Sylex написал(а):
Time: 236.922ms
Спустя 26 минут, 11 секунд (8.02.2009 - 19:55) LoneCat написал(а):
Цитата (Sylex @ 8.02.2009 - 20:27) |
LoneCat я тоже уже провел эксперимент, 180.000 строк... твой запрос висит уже 2 минуту, тогда как с уник. записями - 0,53 сек. Просто что огромные данные выбираются - в этом тормоз. Нужно всегда стараться делать выборку минимальной. |
Ну это первый вариант что пришел на ум, что поделать, не все коту масленница а GROUP BY если подумать в таких масштабах делает тоже самое, что я пытался сделать вручную, создает временную таблицу, и туда пихает уникальные значения, которые потом легко и быстро копируются в результирующую таблицу.
Спустя 2 часа, 44 минуты, 4 секунды (8.02.2009 - 22:39) kirik написал(а):
Интересный вопрос Присоединяюсь к тестам.
Сделал 2 таблицы структуры которую написал LoneCat.
Одну таблицу (test1) заполнил значениями, вторая (test2) - пустая.
Зпрос вида
Сделал 2 таблицы структуры которую написал LoneCat.
Одну таблицу (test1) заполнил значениями, вторая (test2) - пустая.
Зпрос вида
SQL |
INSERT INTO `test2` (`name`) (SELECT DISTINCT `name` FROM `test1`) |
занял 1.4559 секунды (добавилась 1001 строка). Но это без сохранения привязки id=name (в принципе это важно?).
Запрос
PHP |
INSERT INTO test2 (id, name) SELECT id, name FROM&nbs |
занял 1.5167 секунду
Похоже что вариант с GROUP BY самый оптимальный
Еще есть вариант - поиграть с индексами
SQL |
ALTER IGNORE TABLE `test2` ADD UNIQUE INDEX duplicates (`name`); ALTER TABLE `test2` DROP INDEX duplicates; |
этот запрос (а точнее два) не показал сколько по времени выполнялся.. около 20-ти секунд. Но тут не требуется создания второй таблицы.
Спустя 3 часа, 21 минута, 53 секунды (9.02.2009 - 02:01) Adil написал(а):
Большое спасибо. Завтра проверю на 5 миллионах и отпишусь)