HELP: Как работать с большим объемом данных? Oracle или Mysql?
Есть база mysql, в ней innodb таблица на 120 млн. строк и как-то все меееддддленнннно работает.
Написал процедуру, курсор перебирает часть данных (1 млн.) из большой таблицы, для каждой записи делает 10 простых запросов по индексным ключам в эту же таблицу, если условие проходит, то вставляется запись в другую таблицу (в среднем 1 раз в 200 записей).
Первые 1000 записей шустренько, потом все медленней, меeдленнней и меeеееeдленннннннней…
Я так и не понял от чего такое замедление. Мне кажется будет быстрее если переписать через jdbc. Хотя я был уверен, что если все нативно, то должно быть супер быстро. Может какая-то особенность с курсорами или памяти где не хватает, или настройки где подправить. Может разбить большую таблицу на несколько маленьких, хотя я думаю индексы все решают. Я полагаю что предел скорости — это скорость считывания данных с жесткого диска. А на деле работает 10 часов, mysqld полностью грузит одно ядро.
А разницу с oracle database на больших данных кто-нить знает?
Та же проблема была с курсорами в MySQL. Но у меня было много вставок, подумал тогда, что это связанно с перегенирацией индексов для каждой вставки. Но в вашем случае 1 вставка на 200 параметров… значит дело в чем-то другом.
Я бы не стал надеятся что оракел вас спасет. По моему опыту, тормозить в таких случаях он умеет отлично :)
— Придется потратить массу времени на возню с ним.
— А ваще он еще и платный — может за эти бабки докупить оперативы, Xeonов и SSD винтов?
Я не знаю сколько там у вас оперативки на сервере, но посмотрите на индексные файлы, их размер и в настройках мускула отведите, если есть возможность, размер памяти под индексы чуть больший чем размер этих индексных файлов
Может быть 10 запросов объединить в одну транзакцию/один запрос? ( Если еще не сделано )?
Таблицу, наверное можно разбить как нибудь, но особый эффект будет если разные части будут на разных винтах.
А еще может быть попробовать drizzle или какие то другие форки MySQL?
Минимальный набор индексов ~7G, под ключи выделено 3G, но я бы не сказал что диск используется на полную мощность. Проц. грузит все ядро, может как-то можно распараллелить, сама таблица ~6G но все равно считает 10 часов, я думаю что скорость должна быть сравнима с копированием файла в 6G, просто с большей нагрузкой на процессор.
Да, для обработки используются транзакции, раз в 100 записей делается коммит, хотя я не заметил особого прироста производительности для данной задачи с autocommit=0/1.
На таких больших данных работают какие-то другие законы и хитрости, пока не понятно в какую сторону копать.
Сотня-другая миллионов строк — для Oracle очень скромная БД. Никакого деградирования производительности на длительных операциях, даже очень сложных, я не замечал.
В любом случае нужно стараться по возможности упаковать всё в стандартные операторы DML с джойнами, без дополнительного кода, курсорных циклов и т.п. При очень больших объёмах изменений необходимо разбивать транзакцию на несколько, чтобы ограничить использование undo tablespace. Разумееется, включить параллелизм и тщательно рассмотреть план выполнения запроса.
>Первые 1000 записей шустренько, потом все медленней, меeдленнней и меeеееeдленннннннней…
Напоминает поведение при длинных транзакциях. Может просто автокоммит делать?
Это просто догадка. Если не поможет, то вам придется исследовать досконально.
Средний
