|
MySQL.RU - Webboard
 Вернуться
 Большая БД (Eugene Prokopiev) 19/05/2003 - 14:10:41
 Re: Большая БД (Валентин) 19/05/2003 - 16:11:32
Re: Большая БД (Валентин) 19/05/2003 - 16:17:14
Re: Большая БД (Eugene Prokopiev) 19/05/2003 - 16:21:18
Re: Большая БД (Eugene Prokopiev) 19/05/2003 - 16:31:48
Re: Большая БД (Валентин) 19/05/2003 - 20:43:19
Re: Большая БД (Валентин) 20/05/2003 - 18:17:08
> Original message text:
> From: Eugene Prokopiev - 19/05/2003 - 14:10:41
> Subject:Большая БД
> -----------------
> Здравствуйте!
>
> Имеется задача, реализованная сейчас на Firebird. Т.к. она будет сильно переделываться, возникла мысль, а не перенести ли ее на MySQL. Если производительность увеличится хотя бы в 1.5 раза, то овчинка стоит выделки.
>
> Сама задача: каждую ночь в одну из таблиц БД заливается 3-5 млн. записей из файла, который выдала железка. Перед заливкой индексы удаляются, а после создаются заново. За ночь укладываемся :) Данные за каждый месяц попадают в разные БД (именно БД, а не только таблицы), через полгода БД удаляется. Данные фактически необходимо только читать, не считая процедуры заливки.
>
> То, что изменить нельзя: железо - Celeron 1200, 512 Mb RAM, 2 IDE винта по 60Г с данными, SCSI для /tmp, swap и всех системных разделов, т.к. для данных он все равно слишком маленький. OС - Linux 2.4.20.
>
> Основной вопрос: как добиться максимальной производительности от MySQL. Посоветуйте:
>
> 1) Файловую систему
> 2) Параметры настройки самого MySQL
> 3) Тип таблиц. Судя по тому, что я прочитал, лучше MyISAM, но как он отнесется к таким объемам?
> 4) Можно ли заливать такие объемы при живых индексах или лучше их удалить/построить заново?
> 5) Все прочее, что я мог забыть
>
From: Валентин - 19/05/2003 - 20:43:19
Subject:Большая БД
-----------------
>А поддержка транзакций не будет снижать производительность? >Именно из-за отсутствия транзакций в MyISAM я и задумался о >MySQL
Внимательно посмотрите тесты innodb.
Для innodb размеры каждой части базы не должны превышать ограничения на фал в ОС
>5) Объемы эти для interbase нормальные, для мускула это не >объемы.
>А что для него объемы?
У мускула значительно меньше размер индексного файла, чем у interbase, И я пока еще сомневаюся, что inrebase может строить индексы в бинарных деревьях (b-tree).
Посмотрите документацию и сайт мускула. Есть упоминание о таблицах с миллиардами записей. И я думаю, что для мускула это реально, а вот для interbase крутнуть такую таблицу - можно ответа не дождатся.
>6) при заливке данных можно отключать индексы в момент >добавления, а потом включать. Кроме того в мускуле одним insert >можно добавить огромную кучу строк, в отличие от interbase.
>Ну здесь Вы, мягко говоря, ошибаетесь.
Я не ошибаюсь насчет отключения индексов при добавлении в interbase, во всяком случае в мануале interbase такое не упомянуто вообще в синтаксисе команды(sqldialect=1).
Я не строил индексы на таких объемах таблиц 100 млн. записей, возможно сможет ответить кто-нибудь другой. Но внешние ключи в interbase на таблицу в 2,5 млн записей строятся долго (около 10 мин.)
Я не собираюсь вас в чем-либо убеждать, достаточно перекачать в мускул большую таблицу и провести тесты производительности, сразу станет все понятно. Кроме того interbase не умеет за один проход получать данные и сортировать их.
interbase не умеет держать запрошенный результат подзапроса в памяти, для чего он этот подзапрос пересчитывает для каждой строки внешнего запроса. Конечно это все можно обойти.
Но скорость добавления маленькая, а дефрагментация индекса в interbase быстро растет, и interbase очень плохо себя от этого чувствует - вот это не обойдешь. Только backup/restore спасает ситуацию или перестройка индекса.
Насчет транзакций могу сказать, что поведения транзакций в interbase и в innodb совершенно разные, и результаты соответственно.
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
8625
|
|
