форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Оптимизация и Промышленные системы (Public)
Изначальное сообщение		[Проследить за развитием треда]

"MySQL, Oracle, большие базы и производительность"

Сообщение от Алексей (??) on 03-Апр-07, 16:18

В данный момент есть сайт, который использует достаточно большую БД (Около 12G на винте) под управлением MySQL. В БД около десятка таблиц с большим количеством записей (от 10 до 25 миллионов в каждой) и еще около 30 таблиц более мелких. Сервер - Xeon 2.4/1G/160Gb. Нагрузка - около 5000 хостов в сутки. Тачка реально дохнет в пиковые моменты, а в остальные моменты запросы выполняются достаточно долго (до 15-20 секунд на запрос с выборкой из 3-4 тяжелых таблиц и 3-4 мелких). Меня склоняют на смену СУБД на Oracle, ну и, как следствие, на замену тачки на более мощную. Вопрос: 1) Изменится ли в лучшую сторону смена СУБД? 2) Какие требования к тачке, чтобы при нагрузке до 10000 хостов в сутки не было проблем с производительностью такой базы данных?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

[Сортировка по времени, UBB]

1. "MySQL, Oracle, большие базы и производительность"

Сообщение от Vlad (??) on 03-Апр-07, 17:00

>2) Какие требования к тачке, чтобы при нагрузке до 10000 хостов в >сутки не было проблем с производительностью такой базы данных? Сколько запросов то с хоста одного? Какой физический размер больших таблиц?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "MySQL, Oracle, большие базы и производительность"
	Сообщение от Алексей (??) on 03-Апр-07, 17:41
	>>2) Какие требования к тачке, чтобы при нагрузке до 10000 хостов в >>сутки не было проблем с производительностью такой базы данных? > >Сколько запросов то с хоста одного? 1 хост генерит в среднем 12 страниц, из которых тяжелых запросов - 3-4. В пиковые моменты число одновременных активных запросов к базе сейчас может достигать 30-40. > >Какой физический размер больших таблиц? пример (это не все файлы): -rw-rw----    1 mysql    mysql    218072196 Apr  3 15:27 net_price.MYD -rw-rw----    1 mysql    mysql    226216960 Apr  3 15:27 net_price.MYI -rw-rw----    1 mysql    mysql    142464152 Apr  3 14:50 TOF_ARTICLES.MYD -rw-rw----    1 mysql    mysql    40118272 Apr  3 14:50 TOF_ARTICLES.MYI -rw-rw----    1 mysql    mysql    164587625 Feb 23  2005 TOF_ARTICLE_CRITERIA.MYD -rw-rw----    1 mysql    mysql    77990912 Feb 23  2005 TOF_ARTICLE_CRITERIA.MYI -rw-rw----    1 mysql    mysql    351712412 Apr  3 14:51 TOF_ART_LOOKUP.MYD -rw-rw----    1 mysql    mysql    334016512 Apr  3 14:51 TOF_ART_LOOKUP.MYI -rw-rw----    1 mysql    mysql    697246550 Feb 23  2005 TOF_LA_CRITERIA.MYD -rw-rw----    1 mysql    mysql    140584960 Feb 23  2005 TOF_LA_CRITERIA.MYI -rw-rw----    1 mysql    mysql    50303663 Feb 23  2005 TOF_LINK_ART.MYD -rw-rw----    1 mysql    mysql    48913408 Feb 23  2005 TOF_LINK_ART.MYI -rw-rw----    1 mysql    mysql    356924158 Feb 24  2005 TOF_LINK_LA_TYP.MYD -rw-rw----    1 mysql    mysql    573570048 Feb 24  2005 TOF_LINK_LA_TYP.MYI
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "MySQL, Oracle, большие базы и производительность"

Сообщение от andrey (??) on 04-Апр-07, 07:52

>В данный момент есть сайт, который использует достаточно большую БД (Около 12G >на винте) под управлением MySQL. В БД около десятка таблиц с >большим количеством записей (от 10 до 25 миллионов в каждой) и >еще около 30 таблиц более мелких. Сервер - Xeon 2.4/1G/160Gb. Нагрузка >- около 5000 хостов в сутки. Тачка реально дохнет в пиковые >моменты, а в остальные моменты запросы выполняются достаточно долго (до 15-20 >секунд на запрос с выборкой из 3-4 тяжелых таблиц и 3-4 >мелких). Меня склоняют на смену СУБД на Oracle, ну и, как >следствие, на замену тачки на более мощную. Вопрос: >1) Изменится ли в лучшую сторону смена СУБД? >2) Какие требования к тачке, чтобы при нагрузке до 10000 хостов в >сутки не было проблем с производительностью такой базы данных? увеличить оперативную память хотя бы до 4Г..

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "MySQL, Oracle, большие базы и производительность"
	Сообщение от Алексей (??) on 04-Апр-07, 11:24
	>увеличить оперативную память хотя бы до 4Г.. Это требования для MySQL или для ORACLE? ;) очевидно, что 4G - лучше, чем 1G, но даст ли это нужный мне эффект? Т.е. чтобы при необходимой мне нагрузке сервер устойчиво и быстро работал? Вопрос мой заключается в том, что я пытаюсь понять: необходимо ли при указанном мною объеме БД и нагрузке менять СУБД с MySQL на ORACLE, или достаточно просто добавить памяти?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "MySQL, Oracle, большие базы и производительность"
	Сообщение от andrey (??) on 05-Апр-07, 03:03
	> >>увеличить оперативную память хотя бы до 4Г.. > >Это требования для MySQL или для ORACLE? ;) >очевидно, что 4G - лучше, чем 1G, но даст ли это нужный >мне эффект? Т.е. чтобы при необходимой мне нагрузке сервер устойчиво и >быстро работал? Вопрос мой заключается в том, что я пытаюсь понять: >необходимо ли при указанном мною объеме БД и нагрузке менять СУБД >с MySQL на ORACLE, или достаточно просто добавить памяти? а что тут думать, в любой бд при объеме базы 12Г, увеличение оперативной памяти только во благо и это как песочные часы где посередине твой гигабайт. у нас MaxDB, так называемый инстанс уже 25Г, оперативы сейчас 6Г и все равно стремимся увеличить еще на 4Г.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "MySQL, Oracle, большие базы и производительность"

Сообщение от johnjoy (??) on 12-Апр-07, 03:41

Имхо таково: Оракл имеет смысл, если вы перенесете бизнес логику-на уровнь БД и оптимизируете запросы конкретно под оракл. Иначе все преимущество пойдет исключительно от новоприобретенной более сильной машины. С тем же успехом вы можете начать переписывать логику в сторону MySQL/PostgreSQL. Во-первых, действительно увеличьте память и оттюньте my.cnf Во-вторых, подумайте над изменением логики работы приложения с базой. Лучший, пожалуй пример - livejournal.ru В любом случае, гораздо большие (и дешевые) результаты дает оптимизация приложения и SQL запросов, чем решения "железные". Врядли у вас OLTP приложение, а значит оптимизация реальна.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]