[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Нагрузка на сервер
leo
У меня такой вопросик (может даже глупый - незнаю ) : если в одной папке будет хранится например 26000 файлов для скачивания то увеличится ли нагрузка на сервер и время поиска файла по сравнению еслиб было 1000 папок по 26 файлов в каждой



Спустя 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. еще по разному пытался это осуществить, но по любому комп не выдерживает.

Спустя 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 выполнять по определенному кол-ву, т.е. все равно очень долго будет smile.gif

Спустя 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

Давай сравним smile.gif

Спустя 4 минуты, 4 секунды (8.02.2009 - 18:44) Sylex написал(а):
LoneCat
базу у Незабываемого попросим? biggrin.gif

Спустя 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);

mysql_connect('.''login''password'false);
mysql_select_db('database');

$sQuery 'INSERT INTO `test` (`name`) VALUES %s';
for(
$i 0$i 1000$i++) {
    
$aQuery = array();
    for(
$j 0$j 1000$j++) {
        
$aQuery[] = sprintf('(%u)'rand(01000));
    }
    if(!
mysql_query(sprintf($sQueryimplode(','$aQuery)))) {
        echo 
mysql_error();
        break;
    }
}

В поле 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 написал(а):
Правда для чистоты эксперимента нужно было конечно сгенерировать строки, но это так, навскидку набрасывалось, за продуктами схожу, а то уж вечереет, и перенабъю smile.gif

Спустя 18 минут, 26 секунд (8.02.2009 - 19:27) Sylex написал(а):
LoneCat
я тоже уже провел эксперимент, 180.000 строк...smile.gif твой запрос висит уже 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 строк...smile.gif твой запрос висит уже 2 минуту, тогда как с уник. записями - 0,53 сек.

Просто что огромные данные выбираются - в этом тормоз. Нужно всегда стараться делать выборку минимальной.

Ну это первый вариант что пришел на ум, что поделать, не все коту масленница smile.gif а GROUP BY если подумать в таких масштабах делает тоже самое, что я пытался сделать вручную, создает временную таблицу, и туда пихает уникальные значения, которые потом легко и быстро копируются в результирующую таблицу.

Спустя 2 часа, 44 минуты, 4 секунды (8.02.2009 - 22:39) kirik написал(а):
Интересный вопрос smile.gif Присоединяюсь к тестам.
Сделал 2 таблицы структуры которую написал LoneCat.
Одну таблицу (test1) заполнил значениями, вторая (test2) - пустая.

Зпрос вида
SQL
INSERT INTO `test2` (`name`) (SELECT DISTINCT `name` FROM `test1`)

занял 1.4559 секунды (добавилась 1001 строка). Но это без сохранения привязки id=name (в принципе это важно?).

Запрос
PHP
INSERT INTO test2 (idnameSELECT idname FROM&nbs

занял 1.5167 секунду

Похоже что вариант с GROUP BY самый оптимальный smile.gif

Еще есть вариант - поиграть с индексами
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 миллионах и отпишусь)
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.