значит сгенерировал таблицу на милиард записей, без ключей и прочего. (чтобы быстро генерировать)

теперь индексирую, пол суток прошло, обработано только 12 милионов записи, тоесть весь процес займёт около 40 суток...мне кажеться что сдесь чтото не то.

ТАБЛИЦА



Тоесть таблица была без единого ключа, сгенерировал данные, теперь одним альтером хочу добавить все ключи.


ЗЫ поменял названия полей, чтоб не сбивать с толку что и зачем. ведь логика полей не влияет на медлительность индексации :)

вадясколько выделено памяти?
есть подозрение, что время уходит на дисковые операции

Та тоже подумал, только какие имено параметры смотреть надо, там же много по памяти?!

ЗЫ
кслову на сервере 16Гб оперативки, работает только Mysql и только одна база. так что можно не экономить

вадясудя по всему у тебя разовая операция - можно отдать всю
и посмотреть заогрузку диска - разными прогами, в зависимости от оси

так всю отдать не проблема, но куда именно??? там с десяток настроек по памяти??

key_buffer_size ?

я эту переменную на лету изменил в базе быстрее не стало, или её только через конфиг можно менять ?

miksoftalex564657498765453так всю отдать не проблема, но куда именно??? там с десяток настроек по памяти??

key_buffer_size ?Нет, key_buffer_size это только для MyISAM.
Для начала проверьте, что innodb_buffer_pool_size приличного размера. Например, 8G.

Но лучше, наверное, пересоздать табличку с ПК заново. Думаю, выйдет быстрее.

innodb_buffer_pool_size поставил 10Гб

а также

innodb_buffer_pool_size = 10G

innodb_flush_log_at_trx_commit = 0 - пойдёт

innodb_thread_concurrency = 8 - нашол формулу типо число ядер на два, ядер 8 но
подозреваю что их 4, 8 это виртуальные ядра(8 потоков)

innodb_flush_method = O_DIRECT, написано рекомендуеться для очень больших файлов данных(200Гб это достаточно большой)


ну а нащот пересоздать файл данных, там же связаная таблица есть ещо, где 2+млрд записей

вообщем это двое суток генерировалося в таблицы без индексов. или даже чуть больше.

вообщем счас пошло копирование во временную таблицу медленно... за час всего 3млн записей, или он копирует сразу создавая индексы?

ЗЫ
нащо сразу первичного ключа, я подумал что это замедлит генерацию данных, вставку.

ЗЫЗЫ - генерировала хранимая процедура.

вообщем решил ещо раз рестартануть, только теперь без опции
innodb_flush_method = O_DIRECT
(это же виртуальный сервер, и диск у него виртуальный ,то есть прямой работы один чорт не будет, а вот лишний геморой может сделать)

ну и пулсайз 12 гб сделал.

обработка во временую таблицу вроде пошла быстрее. до этого было за секунду гдето 1-3 тыщи записей, теперь около 10тыщ

miksoftalex564657498765453нащо сразу первичного ключа, я подумал что это замедлит генерацию данных, вставку.Скорее, даже ускорит.
У InnoDB есть фича. Поскольку без ПК в нем таблицы не могут существовать в принципе, в тех случаях, когда пользователь не указал ПК явно и нет ни одного уникального ключа, создается невидимое целочисленное поле размером 6 байт, которое и используется как ПК.
Т.е. помимо данных таблицы придется на диск писать еще и 6 ГБ бесполезных данных.


мдя, походу я немного соврал, говоря что я подумал. похоже то ли не думал, то ли не тем девайсом думал., я же знал про "невидимый" первичный ключ :):):)

У меня идея, может дабы не перегенерировать данные на милиард записей, и связаные 2млрд
(там функция ша1 пару раз вызываеться, плюс формул хватает)

а создать рядом таблицу, только уже с явнозаданым примари кеем и перекопировать данные? в исходной таблице данные уже размещены в порядке возрастания этого поля, что для ПК.

?!

Опять проблема.

раньше при индексации таблиц на милиард записей, я столкнулся что с добавлением примари кея, таблица заново пересоздаёться на винчестере, и поэтому долго.

сделал как советовали, заново сгенерировал таблици на 1 и 2 млрд записей(родитель, дочерняя) и индексация прошла сравнительно быстро, за сутки что одна что другая проиндексировались.

Но теперь когда я попытался добавить внешние ключи, опять теже грабли - идёт копирование таблицы во временый файл, приблизительно 1000 записей в секунду обрабатывает, так что перспектива - 1000 000 секунд. ожидания.


Но , если я сразу сделаю таблицу с примари кеем, и внешними ключами = индексами, то я буду долго генерировать этот обьём данных. там вставка капец как медленно пойдёт.

вот и возникает вопрос...так как же создать тогда для тестов базу с таким обьёмом данным, с внешними ключами.

ЗЫ
база получаеться такой
FK - внешний ключ
EK- уникальный ключ
AK - индекс
C - мощность(число записей)

t1: FK->t2(bigint) EK(varchar[40]) C=150K
t2: FK->t1(int) FK->t2(bigint) EK(binary[20]) EK(varbinary[255],bigint[=FK->t2]) C=16M
t3: FK->t1(int) FK->t2(bigint) EK(binary[20]) EK(varbinary[255],bigint[=FK->t2]) C=1G
t4: FK->t3(bigint) AK(int) AK(int) AK(int) C=2G

t2,t3 - второй уникальный ключ по двум полям шифрованая строка(имя) плюс сссылка на родителя. ибо имена могут совпадать у елементов, но при условии разного родителя.

=======
подойдёт любая помощь , как и по генерации быстрой подобной базы, так возможно кто-то покритикует ещо структуру.

MasterZiv,

дык отпишу сюда, только давайте подумаем... как сделать. ведь часто что-то кажеться не возможным, оказываеться не только возможным, а ещо и болле простым. я вон недавно в пхп столкнулся с проблемой, колега при аналогичной проблеме на ноуд-джиес перешол, так как форумы говорят что не возможно без написания своего мини протокола и обмена через сокеты.

оказываеться проблема решаема, более того, её решение помогает и в задаче ускорения работы серверной части защёт распаралеливания.

вот так вот бывает.