Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / MySQL |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 вперед Ctrl→ все |
miltorg Member Откуда: Калининград Сообщений: 860 |
Как отсортировать 1 миллиард записей? Максимум который сортирует mySQL - 3 миллиона записей. И то, начинаются страшные тормоза и зависание. Что делать? Спасибо. |
8 янв 21, 15:44 [22260285] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 865 |
miltorg, а что мешает отсортировать снаружи обычным sort, ограниченным лишь размером свободного места на диске? |
8 янв 21, 16:35 [22260302] Ответить | Цитировать Сообщить модератору |
вадя Member Откуда: Екатеринбург Сообщений: 18678 |
miltorg, настройки проверял? там сказано про сортировку |
8 янв 21, 16:38 [22260304] Ответить | Цитировать Сообщить модератору |
вадя Member Откуда: Екатеринбург Сообщений: 18678 |
miltorg, интересно, для чего такой огромный выбор? |
8 янв 21, 16:40 [22260305] Ответить | Цитировать Сообщить модератору |
Gluck99 Member Откуда: Оттуда Сообщений: 1127 |
|
||||
8 янв 21, 17:00 [22260317] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 865 |
вадя, похоже на DW или ML задачу. У меня тоже есть таблицы с более, чем миллиардом записей и трансформация их в таблицы, содержащие уже полтора миллиарда записей. Но на PostgreSQL. MySQL на таких объемах применять не рискнул. |
8 янв 21, 18:06 [22260334] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
Нормально всё сортируется - при наличии подходящего индекса. А без него любая СУБД заткнётся на сортировке больших объёмов (или Вы всерьёз полагаете, что "взрослые" СУБД используют какие-то суперские алгоритмы сортировки, которые в разы эффективнее, чем у MySQL? огорчу...).
Добавить в запрос предложение ORDER BY с требуемым выражением сортировки. Для более осмысленного ответа недостаточно данных. Нужны как минимум: точный текст запроса, точные DDL всех задействованных таблиц, статистика по данным. |
||||||||
8 янв 21, 18:44 [22260344] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 865 |
Про эффективность ничего не скажу, так как не сравнивал, но то, что в нормальных СУБД объем сортируемых данных ограничен только доступным дисковым пространством или явно заданными лимитами на его использование, знаю точно. За счет сочетания sort-merge, скорость сортировки, как только сортируемый набор не помещается в запрошенную планировщиком память, зависит от объема почти линейно. Точнее линейно на фазе сортировки, а на фазе слияния нарастание логарифмическое по основанию 2 или более. Сообщение было отредактировано: 8 янв 21, 18:54 |
||||
8 янв 21, 19:00 [22260353] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
Любая СУБД теоретически выполнит сортировку любого объёма данных - во всяком случае в пределах объёмов, определяемых возможностями СУБД по хранению и обработке. И, по-моему, сейчас все СУБД, столкнувшись с необходимостью сортировки массива, не умещающегося в памяти, используют внешнее слияние.
|
||||||||||||
8 янв 21, 20:00 [22260369] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
Клиент готов запустить свой компьютер хоть на неделю. Поэтому задачу придётся решать. Итак. Есть строчечный файл: ... ... 4.5.2012 3 8 9 11 16 28 30 31 35 37 40 43 48 53 54 58 59 60 61 68 5.5.2012 5 6 8 11 16 18 19 22 25 34 37 40 42 51 55 59 61 64 65 69 6.5.2012 10 15 16 18 23 24 27 29 31 33 36 38 53 55 57 58 62 66 67 68 ... ... То есть дата и 20 цифр. Строчек в файле - 5000. Будут добавляться - по 1 в день Из каждой строчки берётся 10 цифр и из них делаются не повторяющиеся комбинации: 4.5.2012 3_8_9_11_16_28_30_31_35_37 4.5.2012 3_8_9_11_16_28_30_31_35_40 ... ... ... 4.5.2012 40_43_48_53_54_58_59_60_61_68 Сообщение было отредактировано: 8 янв 21, 23:48 |
8 янв 21, 23:54 [22260460] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
Символ подчёркивания - пожелание заказчика - то есть его наличие - не критично Нужно получить все совпадения. В идеале в виде сортировки. То есть на самом верху таблицы: 4.5.2012 3_8_9_11_16_28_30_31_35_37 7.12.2017 3_8_9_11_16_28_30_31_35_37 5.12.2019 3_8_9_11_16_28_30_31_35_37 ... ... ... 3.5.2016 3_8_9_11_16_28_30_31_35_40 3.5.2020 3_8_9_11_16_28_30_31_35_40 ... ... ... 4.5.2012 40_43_48_53_54_58_59_60_61_68 ... ... ... |
9 янв 21, 00:02 [22260462] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
Строить все комбинации, а потом искать совпадение - это [censored]. Надо нормализовать данные, потом выполнять сравнение, получая для каждой пары дат количество совпадений, а вот потом для тех пар, у которых это количество превышает 10, строить десятки значений. PS. Даже всё описанное - это не задача, а выбранный способ решения некоей неозвученной задачи. И не факт, что способ выбран правильно... PPS. Если Вы в форуме по MySQL - то пишите дату в его формате, YYYY-MM-DD. |
9 янв 21, 00:06 [22260465] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
До одного миллиона записей всё грузилось чудно и быстро. Я открывал phpmyAdmin. Запросто и радостно делал сортировку. На 2 миллионах записей стала притормаживать сортировка - до 1 минуты. На 3 миллионах записей - я не смог даже просто открыть страницу в phpmyAdmin. Просто. Без никакой сортировки. ----------------------- Вот и весь мой рассказ. Это всё было на хостинге. Теперь клиент выделяет под это дело отдельный комп - который"может работат хоть неделю - лишь бы был результат" Что и как делать? Выделенный комп - под Виндос Спасибо. |
9 янв 21, 00:11 [22260468] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
Akina, Дата написана в формате который пожелал заказчик. |
9 янв 21, 00:28 [22260476] Ответить | Цитировать Сообщить модератору |
ptr128 Member Откуда: Moscow Сообщений: 865 |
Akina, 1. Я просто недостаточно знаю MySQL, чтобы утверждать, использует ли он сортировку-слияние с использованием диска или нет. При этом в PostgreSQL и MS SQL уход сортировки на диск/tempdb явно отображается в плане запроса. Про MySQL в этом вопросе не нашел вообще ни слова в гугле. 2. Прошу прощения, я и имел в виду N*log2(N) или меньше, в случае полифазного слияния. |
9 янв 21, 00:33 [22260477] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
Данные в нём - не секретные? можно выложить его? зипануть и прикрепить к сообщению... |
||||
9 янв 21, 01:15 [22260487] Ответить | Цитировать Сообщить модератору |
booby Member Откуда: Сообщений: 2321 |
Это да. Описание похоже на "группировку по комбинации", то есть по сочетаниям по 10 из 20 С(20)(10) = 184,756 это худший случай, когда все 20 чисел разные Сортировка, видимо, сначала нужна только для того, чтобы образовать строковый ключ сочетания. Всего строк получается: 184756*5000 = 923 780 000 строк, для которых надо дальше сделать Group by ключу сочетания и датам 5 тысяч сортировок наборов из 20 элементов, ну это не должно быть неподъемным. Но группировка сколько -то потребует, от числа уникальных групп зависит. На таких размерах пару-тройку минут и подождать прилично. Хотя, если бы был известен физический смысл задачи, может быть нашлись какие-то пути сокращения размерности. |
||||
9 янв 21, 01:36 [22260491] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
раз ничего не предложили - я вижу только одно решение: 1. Возможно что нужно упорядочить-отсортировать исходный файл - хуже от этого не будет - точно 2. Набивать БД постоянно держа её в отсортированном - то есть в готовом виде. 3. Добавлять буквально по 1 миллиону записей или меньше - продолжая держать БД в готовом виде. После каждой записи? 4. Не открывать никакого phpmyAdmin - раз он тормозит. Сообщение было отредактировано: 9 янв 21, 01:43 |
9 янв 21, 01:47 [22260493] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
Упс. совсем забыл. Писать то придётся под Виндос. Какую БД взять? Ведь всё равно придётся что-то ставить. Спасибо. |
9 янв 21, 01:59 [22260495] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
вспомнил ещё. Если выгрузить всё в виде текстовых файлов то получится около 50 ГБ. |
9 янв 21, 02:22 [22260500] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
|
||||
9 янв 21, 10:18 [22260524] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 50489 |
Тоесть нужно определить что в 12 и 17 итд годах были события (хромосомы) с одинаковыми атрибутами? |
9 янв 21, 11:48 [22260551] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 50489 |
Топик немного похож на унификацию https://www.sql.ru/forum/1270456-1/tyapnichnaya-unifikaciya и хотя там постановка про другое - про устранение дублей но то что обсуждалось - может быть применено и здесь. |
9 янв 21, 12:13 [22260560] Ответить | Цитировать Сообщить модератору |
miltorg Member Откуда: Калининград Сообщений: 860 |
Akina, Вариации 10 из 20 из каждой из 5 тысяч строк |
9 янв 21, 13:13 [22260577] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20871 |
miltorg, Вы упорно уходите от темы озвучить собственно задачу. Ну это я ещё понимаю - конкуренция и всё такое. Но Вы хотя бы определите требуемый результат - мне почему-то крайне сомнительно, что в качестве финального итога нужны все, абсолютно все, вариации каждой из записей, просто специальным образом сортированные. Финального - в смысле совсем. Ибо я вполне допускаю, что для завершения текущей подзадачи и для передачи следующей подзадаче это может быть допустимый формат. Равно как и сомневаюсь в оптимальности именно такого формата. |
9 янв 21, 13:30 [22260582] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 вперед Ctrl→ все |
Все форумы / MySQL | ![]() |