форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум WEB технологии (MySQL)
Изначальное сообщение		[ Отслеживать ]

"Быстрый импорт в MySQL"	+/–
Сообщение от ACCA (ok) on 21-Май-12, 07:25
Хочется быстро залить данные в MySQL, хотя бы 100тыс. строк в секунду на SATA RAID. Строки короткие - 3 int + 2 bigint + decimal(13,3). 1 bigint + 3 int + decimal дают primary key. Если критично, ключ можно сократить до 2 int + decimal. Что пробовал - 1. drop primary key + 6 потоков LOAD DATA INFILE, каждый в отдельную таблицу MyISAM. В сумме разгоняется до >300тыс. строк в секунду. Получается 6x110G .MYD. Делаю ALTER TABLE ... ADD PRIMARY KEY. Тягомотина с полным копированием на неделю. 2. подсунуть таблице без ключа .frm от такой же, но с ключом. Потом зарядить REPAIR TABLE ... QUICK. Долго думает, потом начинает полное копирование на неделю. 3. myisamchk - то же, что и REPAIR TABLE. 4. Порвать данные на 300 потоков, совать потоки по очереди в таблицу с ENGINE MEMORY. В memory залетает со свистом. Оттуда в MyISAM с помощью INSERT ... SELECT - не быстрее, чем просто LOAD DATA с ключом. Сами данные заливаются в порядке PRIMARY KEY, дубликаты уже порезаны. Есть ли какой-то способ сделать primary key без полного копирования?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Быстрый импорт в MySQL"	+/–
Сообщение от ACCA (ok) on 23-Май-12, 06:47
> Хочется быстро залить данные в MySQL, хотя бы 100тыс. строк в секунду Сдался, переписал под PostgreSQL + pg_bulkload. 4 потока на клиенте разбирают CSV и загоняют в BINARY в файловой системе сервера базы данных. Кто первый закончил - начинает заливать BINARY в таблицу. Если за это время ещё кто появился - ждёт, когда таблица освободится. Разбор в каждом потоке идёт со скоростью 30-40К строк в секунду, заливка в таблицу с индексацией - 88К. 1-2 декодера простаивают, ожидая очереди на заливку.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Быстрый импорт в MySQL"	+/–
	Сообщение от ACCA (ok) on 23-Май-12, 15:50
	PostgreSQL делает partitioning через inheritance. Для каждого потока делаю CREATE TABLE xxxN (...) INHERITS (xxx), потом заливаю CSV через pg_bulkload. У каждого своя таблица, никто ничего не ждёт. 5 потоков насыщают мелкую железяку за $600 - Xeon X3430, 4G RAM, пара SATA в LVM2. Около 30К/c строк на поток, 150K/c суммарно. MySQL слил вчистую.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Быстрый импорт в MySQL"	+/–
	Сообщение от Аноним (??) on 13-Июн-12, 15:28
	> PostgreSQL делает partitioning через inheritance. Для каждого потока делаю CREATE TABLE > xxxN (...) INHERITS (xxx), потом заливаю CSV через pg_bulkload. У каждого > своя таблица, никто ничего не ждёт. > 5 потоков насыщают мелкую железяку за $600 - Xeon X3430, 4G RAM, > пара SATA в LVM2. Около 30К/c строк на поток, 150K/c суммарно. > MySQL слил вчистую. б..ть, датафайл скопируй просто, у тебя-ж myisam. был-бы innodb - еще пришлось-бы повозиться, а тут-то что мешает? заблокируй только табличку во время операции.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Быстрый импорт в MySQL"	+/–
Сообщение от LSTemp (ok) on 04-Июн-12, 14:22
>[оверквотинг удален] > 2. подсунуть таблице без ключа .frm от такой же, но с ключом. > Потом зарядить REPAIR TABLE ... QUICK. Долго думает, потом начинает полное > копирование на неделю. > 3. myisamchk - то же, что и REPAIR TABLE. > 4. Порвать данные на 300 потоков, совать потоки по очереди в таблицу > с ENGINE MEMORY. В memory залетает со свистом. Оттуда в MyISAM > с помощью INSERT ... SELECT - не быстрее, чем просто LOAD > DATA с ключом. > Сами данные заливаются в порядке PRIMARY KEY, дубликаты уже порезаны. Есть ли > какой-то способ сделать primary key без полного копирования? 1) не озвучено, кто в данный момент к таблицам мог еще доступ иметь 2) проверку ключей на время операций с данными можно временно отключить. часто работает быстрее, чем drop/add ключей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Быстрый импорт в MySQL"	+/–
	Сообщение от ACCA (ok) on 07-Июн-12, 05:38
	> 1) не озвучено, кто в данный момент к таблицам мог еще доступ > иметь Какая разница? Никто, это специальный сервер, который сейчас занимается только приёмом данных. > 2) проверку ключей на время операций с данными можно временно отключить. часто > работает быстрее, чем drop/add ключей. И как ты это сделаешь для primary key?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Быстрый импорт в MySQL"	+/–
	Сообщение от LSTemp (ok) on 13-Июн-12, 15:06
	>> 1) не озвучено, кто в данный момент к таблицам мог еще доступ >> иметь > Какая разница? Никто, это специальный сервер, который сейчас занимается только приёмом > данных. а данные надо думать в него с неба сыпятся... сервисы, которые вливания делают  - это тоже по Вашему "никто"? >> 2) проверку ключей на время операций с данными можно временно отключить. часто >> работает быстрее, чем drop/add ключей. > И как ты это сделаешь для primary key? а у Вас других ключей, кроме как первичных на таблицах нет? с чего Вы вообще взяли, что стопор именно из-за первичного ключа идет? Итого: 1) ОС - неизвестна 2) структура БД - не известна 3) настройки сервера неизвестны 4) что конкретно (команды) делалось - неизвестно (банальный insert values (v1)(v2)..(v100) выполняется гораздо быстрее, чем 100 последовательных insert например) телепатировать для решения Ваших задач или убеждать Вас в том, что MySQL лучше/хуже PostgreSQL не вижу смысла.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Быстрый импорт в MySQL"	+/–
	Сообщение от ACCA (ok) on 19-Июн-12, 01:11
	> Итого: > 1) ОС - неизвестна > 2) структура БД - не известна > 3) настройки сервера неизвестны > 4) что конкретно (команды) делалось - неизвестно (банальный insert values (v1)(v2)..(v100) > выполняется гораздо быстрее, чем 100 последовательных insert например) > телепатировать для решения Ваших задач или убеждать Вас в том, что MySQL > лучше/хуже PostgreSQL не вижу смысла. Перечитай ветку с начала. Потом попробуй заливать строки по 40 байтов, из которых 31 байт - primary key. Строчек много - на 600 гиг диска получается, грубо говоря, 15 млрд. Уложишься в 12 часов в одну таблицу с primary key в MySQL на SATA с любыми настройками в любой ОС любыми командами - сможешь рассказать всему миру, какие они мудаки. А пока у тебя получились только пузыри в луже. Зато много...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Быстрый импорт в MySQL"	+/–
	Сообщение от ACCA (ok) on 19-Июн-12, 06:08
	С любыми настройками в любой ОС любыми командами - по твоему выбору. На сегодняшний день считается, что на SATA это невозможно.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Быстрый импорт в MySQL"	+/–
	Сообщение от ACCA (ok) on 19-Июн-12, 06:09
	[]
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Быстрый импорт в MySQL"	+/–
	Сообщение от LSTemp (ok) on 26-Июн-12, 02:22
	> С любыми настройками в любой ОС любыми командами - по твоему выбору. > На сегодняшний день считается, что на SATA это невозможно. что не возможно? (подозреваю, что почитать документацию - тут ты прав - удачи)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Быстрый импорт в MySQL"	+/–
	Сообщение от LSTemp (ok) on 26-Июн-12, 02:19
	> Перечитай ветку с начала. читал. ТТХ нет никаких - одно словоблудие. > Потом попробуй заливать строки по 40 байтов, из которых 31 байт - > primary key. Строчек много - на 600 гиг диска получается, грубо > говоря, 15 млрд. > Уложишься в 12 часов в одну таблицу с primary key в MySQL > на SATA с любыми настройками в любой ОС любыми командами - > сможешь рассказать всему миру, какие они мудаки. обязательно и только для Вас я это конечно сделаю! несомненно (руку дружбы я Вам уже протянул. она сжата в кулак и средний палец распремляется прям щас - fuck U) > А пока у тебя получились только пузыри в луже. Зато много... - Вы так и не сказали с каких источников данные в БД поступают (нагрузка с клиентов не определена) - Пузыри в луже только от Вас пока вижу: PK/datа. про нормализацию БД вообще не слышали? Можете миру об этом рассказать. PS получилось на постгресе Вашу ТЕКУЩУЮ задачу решить, ну и хорошо - я про это уже говорил. Не пойму зачем залупаться дальше?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема