|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
||||||||||||
простая база с одним полем (оно же ключ), но много записей. как максимально быстро организовать проверку и добавление пакета новых записей?27.03.2013, 23:59. Показов 3357. Ответов 13
Метки нет (Все метки)
есть простейшая БД (с одним полем), состоящая из уникальных строковых ключей, типа:
время от времени на сервер приходит пакет новых ключей в виде строки, в которой ключи разделены символом “\n” (или каким-нибудь другим разделителем – это не важно). во вновь прибывшем пакете может быть от 100 до 3000 ключей. для каждого нового ключа из входящего пакета нужно проверить, есть ли такой ключ в базе, и если нет, то добавить его в базу. сейчас для хранения данных используется обычный текстовый файл f.txt, в котором ключи разделены символом “\n”, а для проверки и добавления новых ключей в базу используется следующий сценарий:
но что делать, если база со временем разрастется? для стресс-теста был сгенерирован файл, аналогичный файлу f.txt, но с количеством ключей - 2 млн. (объем файла получился около 40 Мб). первая же попытка прогнать цикл «проверка-добавление» в массиве из 50-ти новых ключей показала, что сценарий начинает заметно тормозить. если же массив вновь добавляемых ключей увеличить до 1000, то сценарий встает колом. в связи с чем возникает вопрос: как лучше реализовать такую задачу на php? можно ли что-то придумать здесь быстрее, чем strpos()? P.S. в качестве сервера используется домашний ПК /Intel(R) Core(TM)2 Quad CPU Q8200 @2.33GHz 2.34Ghz, ОЗУ 4GB/ под управлением Windows 7 64бит + Denwer 3.
0
|
||||||||||||
| 27.03.2013, 23:59 | |
|
Ответы с готовыми решениями:
13
Добавление новых записей невозможно, ключ связи таблицы не входит в набор записей
На новой форме организовать добавление новых записей |
|
632 / 440 / 67
Регистрация: 19.09.2012
Сообщений: 1,632
|
|
| 28.03.2013, 11:27 | |
|
попробуйте поставить колонке таблице индекс UNIQUE и добавлять в БД через INSERT IGNORE.
У вас в колонке не будет дубликатов
1
|
|
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
||||||||||||||
| 28.03.2013, 16:23 [ТС] | ||||||||||||||
|
koza4ok,
допустим, я последовал вашему совету и сформировал mysql-таблицу mytable с одним полем типа UNIQUE. пример таблицы mytable для наглядности:
выполняем, например, такой запрос:
можно ли при этом еще и вывести множество строк, которые были добавлены в результате последнего запроса? то есть только 'xxx' и 'yyy' хочется и рыбку съесть и... то есть чтобы в таблицу были добавлены только уникальные значения, и при этом еще знать какие именно значения были добавлены.
0
|
||||||||||||||
|
13210 / 6599 / 1041
Регистрация: 10.01.2008
Сообщений: 15,069
|
|
| 28.03.2013, 17:04 | |
|
0
|
|
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
|
| 28.03.2013, 20:02 [ТС] | |
|
боюсь, с поштучными INSERTами картина будет весьма печальная.
хорошо, если поштучно нужно вставить 10-20 строк, а если 2-3 тысячи? сегодня загнал свою стресс-базу с 2-мя миллионами строк в mysql-таблицу. первый же запрос для подсчета общего количества строк SELECT COUNT(*) FROM mytable подвесил сценарий более чем на минуту. это уже выглядит не очень оптимистично. как же с такой mysql-таблицей дальше-то работать
0
|
|
|
13210 / 6599 / 1041
Регистрация: 10.01.2008
Сообщений: 15,069
|
|||||||
| 29.03.2013, 15:39 | |||||||
|
Добавлено через 43 секунды См также результат из:
0
|
|||||||
|
87 / 87 / 8
Регистрация: 02.09.2012
Сообщений: 510
|
|
| 29.03.2013, 17:08 | |
|
если есть доступ к фс сервера mysql можно воспользоваться LOAD DATA из файла данных который вы закачаете на сервер. скорость страшно сказать на несколько порядков выше чем построчный insert.. скорее всего придется поговорить с хостером..
Добавлено через 8 минут а проверку для формирования загрузочного файла делать обычным селектом, благо он выполняется быстро
0
|
|
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
||||||
| 29.03.2013, 17:32 [ТС] | ||||||
|
еще раз.
таблица уже в базе. я её так и загружал:
сейчас вопрос в том, как максимально ускорить добавление новых записей (есть необходимость добавлять до 2000 тысяч записей за раз), при этом чтобы дубликаты не добавлялись в таблицу, и чтобы выводился список последних добавленных записей (ну и оптимально общее количество записей в таблице) P.S. тип таблицы: InnoDB, в таблице только одно поле VARCHAR(25) с типом UNIQUE
0
|
||||||
|
87 / 87 / 8
Регистрация: 02.09.2012
Сообщений: 510
|
|
| 29.03.2013, 17:41 | |
|
формируйте файл на основе селектов - не пихайте в него то что уже есть.. или какие у вас там проверки... ускорить - бросить бесплатный софт с вашими объемами 2000 за раз.. это что - типовая операция для обычного пользователя системы? а если не типоавая - то подождет несколько минут, не повесится..
0
|
|
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
||||||
| 30.03.2013, 17:15 [ТС] | ||||||
|
сегодня попробовал такое вот решение.
создал InnoDB-таблицу users. в таблице два поля: num (INT(11), PRIMARY KEY, AUTO_INCREMENT) и id (VARCHAR, UNIQUE). типовая операция с таблицей включает следующие запросы: шаг 1. запоминаем номер последней записи как num_MAX; шаг 2. добавляем в таблицу новые id (если такие уже есть в таблице, то дубликаты не добавляются); шаг 3. выводим только те id, которые были добавлены в ходе предыдущего запроса (то есть, у которых num > num_MAX) .
затем сгенерирован запрос на добавление в таблицу еще 2 тысяч новых id. при первом выполнении сценария самым узким местом, что не удивительно, оказался INSERT IGNORE INTO users(id) VALUES('aaa'),('bbb'),('ccc'),...('...') на выполнение этого запроса потребовалось примерно 20 секунд. причем, при повторном прогоне сценария (через CTRL+R) времени на insert новых случайным образом сгенерированных id в таком же количестве - 2 тысячи потребовалось уже значительно меньше. вопрос: можно ли как-то еще оптимизировать таблицу или запросы, чтобы уменьшить время на добавление новых записей? 20 секунд, конечно, не столь уж критично, но и не так уж мало. Добавлено через 25 секунд если, скажем, для данного конкретного примера оставить все-таки таблицу с одним полем id. уже без всяких индексов. перед добавлением новых id: aaa, bbb, ccc... делать предварительную выборку из таблицы вроде SELECT * FROM users WHERE id in ('aaa', 'bbb', 'ccc') потом сравнивая эту выборку с входящим списком новых id, удалить из него дубликаты. (здесь уже можно и простым сравнением строк или регулярными выражениями обойтись) и затем уже этот усеченный список вставлять в таблицу с помощью INSERT, но уже без всяких игноров. не будет ли так быстрее?
0
|
||||||
|
87 / 87 / 8
Регистрация: 02.09.2012
Сообщений: 510
|
|||
| 30.03.2013, 18:07 | |||
|
Добавлено через 2 минуты Добавлено через 1 минуту сделать ключи не строковыми а целыми числами..
0
|
|||
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
|
| 31.03.2013, 02:33 [ТС] | |
|
вопрос сейчас только в одном. сразу вставлять в таблицу 2К записей через INSERT IGNORE... или сначала через SELECT... WHERE... IN... сделать выборку дубликатов, усечь из 2К записей дубликаты и вставлять уже усеченный список через обычный INSERT.
Добавлено через 6 минут еще вопрос. индексы ведь тормозят таблицу? потом что в первом варианте нужно использовать индексную таблицу, а во втором можно без индексов. Добавлено через 7 часов 32 минуты беру свои слова обратно. без индекса таблица работает медленнее по всем фронтам.
0
|
|
|
13210 / 6599 / 1041
Регистрация: 10.01.2008
Сообщений: 15,069
|
||
| 31.03.2013, 06:27 | ||
|
0
|
||
|
0 / 0 / 0
Регистрация: 26.03.2013
Сообщений: 14
|
||||||
| 03.04.2013, 16:10 [ТС] | ||||||
|
если кто следил за темой, то решение свелось к следующему.
используется таблица users (тип InooDB) 2 поля: id - varchar(22), primary key; time - timestamp, по умолчанию CURRENT_TIMESTAMP (дополнительное вспомогательное поле). главная "хитрость" в том, чтобы вместо запроса INSERT IGNORE INTO ... VALUES('aaa'),('bbb'),('ccc'),...('...') использовать запрос LOAD DATA LOCAL INFILE '.....txt' IGNORE INTO TABLE, предварительно сохранив данные для добавления во временный txt-файл. сохранение данных во временный txt происходит ничтожно быстро, зато потом загрузка данных в таблицу из файла будет во много раз быстрее чем групповой INSERT (про поштучный вообще молчу).
0
|
||||||
| 03.04.2013, 16:10 | |
|
Помогаю со студенческими работами здесь
14
Добавление записей невозможно: ключ связи таблицы не входит в набор записей
Формы: добавление новых записей и удаление записей База данных на основе массива записей: добавление, удаление, поиск записей Добавление новых записей и новых полей Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Идея фильтра интернета (сервер = слой+фильтр).
Hrethgir 31.03.2026
Суть идеи заключается в том, чтобы запустить свой сервер, о чём я если честно мечтал давно и давно приобрёл книгу как это сделать. Но не было причин его запускать. Очумелые учёные напечатали на. . .
|
Модель здравосоХранения 6. ESG-повестка и устойчивое развитие; углублённый анализ кадрового бренда
anaschu 31.03.2026
В прикрепленном документе раздумья о том, как можно поменять модель в будущем
|
10 пpимет, которые всегда сбываются
Maks 31.03.2026
1. Чтобы, наконец, пришла маршрутка, надо закурить. Если сигарета последняя, маршрутка придет еще до второй затяжки даже вопреки расписанию.
2. Нaдоели зима и снег? Не надо переезжать. Достаточно. . .
|
Перемещение выделенных строк ТЧ из одного документа в другой
Maks 31.03.2026
Реализация из решения ниже выполнена на примере нетипового документа "ВыдачаОборудованияНаСпецтехнику" с единственной табличной частью "ОборудованиеИКомплектующие" разработанного в конфигурации КА2. . . .
|
|
Functional First Web Framework Suave
DevAlt 30.03.2026
Sauve. IO
Апнулись до NET10.
Из зависимостей один пакет, работает одинаково хорошо как в режиме проекта
так и в интерактивном режиме. из сложностей - чисто функциональный подход.
Решил. . .
|
Автоматическое создание документа при проведении другого документа
Maks 29.03.2026
Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2.
Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники".
В. . .
|
Настройка движения справочника по регистру сведений
Maks 29.03.2026
Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии.
. . .
|
Автозаполнение реквизита при выборе элемента справочника
Maks 27.03.2026
Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2.
При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .
|