Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Производительность и надежность MySQL при больших объемах данных  (Прочитано 18047 раз)
0 Пользователей и 1 Гость смотрят эту тему.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« : 03-08-2010 12:54 » 

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

Давно использую MySQL по работе в различных небольших проектах.. В основном из-за простоты связки с PHP..
Встала задача сбора и анализа логов с различных серверов.. Из-за некоторых требований было решено реализовать это так - с некоторой периодичностью выделенный сервер собирает порции новых записей из логов удаленный серверов, загоняет их в базу, а потом, по запросу все анализируется и выводится в виде графиков и тп...
По привычке выбрал MySQL, но после нескольких дней засомневался в правильности...

Сейчас база занимает около 5 Гб, в ней содержится около 19 млн записей (И это еще даже не десятая часть от желаемого объема!), каждый день прирастает примерно по 2 млн записей (потом будет еще раза в 2 больше)..

Меня беспокоит вопрос - будет ли база стабильно и достаточно быстро работать на пике, когда объем вырастет раз в 10.. По моим ощущениям, скорость, как минимум, добавления записей, упала раза в 2 по сравнению с пустой базой..
При этом нагрузка процессора (Dual-Core AMD Opteron 1220, 2.8 GHz) приближается к 100% при добавлении в 2 потоках через ODBC-коннектор.
Памяти у серванта 4 Gb, из них более 1.5 Gb отдано для MySQL.. Сервер под Win2003 SE SP2.
Кроме этой базы тут же крутятся базы еще нескольких нужных проектов, но их нагрузка минимальна, однако не хочется, чтоб упавший сервант погреб их под собой..

Собственно вопрос такой - если ставить на этот же сервер другую базу - например MSSQL - будет ли это более выигрышным? В перспективе можно организовать сервер с Oracle 10 (на него лицензия какая-то есть у компании), но также нужно сравнить - будет ли выгода?

Приоритеты в порядке убывания:
* Цена решения
* Надежность работы остальных компонентов на этом же сервере (чтоб не влияло на них и не отбирало 100% CPU)
* Хранение больших объемов (скажем, до 80 Гб и 500 млн записей)
* Скорость добавления новых записей

Временем анализа можно пожертвовать - оно может немного подождать при построении графиков, но также в разумных пределах..
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 03-08-2010 13:07 » 

Скажем так, у меня работа на MS SQL V10 с таблицами по 500 млн. записей и базами свыше 150 Gb особых проблем не вызывает. Скорость добавления записей ~3000/сек.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #2 : 03-08-2010 13:20 » 

ИМХО решающий фактор всё-таки железо. Память, количество процессоров, быстрые диски.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 03-08-2010 13:21 » 

Лучше Oracle. Он с задачей справится, но место на диске кушает хорошо.

Вопросы:
0. Версия MySQL.
1. Какой тип таблиц использовали?
2. Не думали делать анализ не по запросу, а онлайн (или периодически) и хранить только результат анализа?
3. Каковы настройки MySQL? Буфера и т.п. Лучше весь конфиг покажи.

Добавление данных эффективнее в режиме bulk: сперва накопить N строк, а потом вставлять единым INSERT. Эффект прежде всего в более редком перестроении индексов.
« Последнее редактирование: 03-08-2010 13:25 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
McZim
Модератор

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #4 : 03-08-2010 13:27 » 

1. Уверен что оптимально организовал хранение данных в таблицах?
2. Уверен что оптимально выбрал набор индексов?
3. Уверен что оптимально строишь SQL?
4. Уверен что оптимально организовал хранение на уровне ОС?
5. Уверен что оптимально работаешь с данными на уровне ОС?

Что касается того что работа с БД заметно снизилась при ее росте. Однозначно можно сказать что оптимальность работы и хранения данных храмает!

RXL, по поводу съедания места ораклом не понял? Заполнения справочников статистикой, по отношению к объему данных, мизерно.
Записан

The CBO without stats is like a morning without coffee. (c) T.Kyte.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #5 : 03-08-2010 13:38 » 

Лучше Oracle. Он с задачей справится, но место на диске кушает хорошо.

Наверное, лучше.. Но под него, видимо, нужен отдельный сервак, причем, скорее всего не на Windows.. Пока же в наличии то что есть.
Проект пока пилотный и если получится что-то интересное - сервак могут дать.. Но администрировать Oracle и *nix я сейчас сам не готов Жаль

Вопросы:
1. Какой тип таблиц использовали?
InnoDB.

2. Не думали делать анализ не по запросу, а онлайн (или периодически) и хранить только результат анализа?
Думали.. Проблема в том, что пока хочется загнать в базу логи, например, за месяц, потом поиграть с запросами, посмотреть что интересного можно из этого получить.. Также есть желание показывать не только графики с ошибками, но и куски разных логов за этот промежуток времени.
Если будет сильно тормозить, то наиболее тяжелые анализы сделаю кэшируемыми.

3. Каковы настройки MySQL? Буфера и т.п.

см. ниже кусок из my.ini

Добавление данных эффективнее в режиме bulk: сперва накопить N строк, а потом вставлять единым INSERT. Эффект прежде всего в более редком перестроении индексов.
Спасибо, это *очень* хорошая мысль.. Так и сделаю.

Код: (INI) my.ini
default-storage-engine=INNODB

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

max_connections = 1000

query_cache_size=0

table_cache = 128

tmp_table_size = 200M

thread_cache_size = 12

myisam_max_sort_file_size=100G

myisam_sort_buffer_size=369M

key_buffer_size=32M

read_buffer_size = 256K
read_rnd_buffer_size = 512K

sort_buffer_size=256K

innodb_additional_mem_pool_size = 50M

innodb_flush_log_at_trx_commit=1

innodb_log_buffer_size = 40M

innodb_buffer_pool_size = 1200M

innodb_log_file_size=586M

innodb_thread_concurrency = 16

innodb_file_per_table
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #6 : 03-08-2010 13:46 » 

MySQL 5.1.45
McZim, да, оптимальность хромает. Структуру таблиц и индексов приводить не буду - у вас своей работы хватает, чтобы в моей разбираться.. Улыбаюсь Структура будет, скjрее всего, меняться.
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 03-08-2010 14:04 » 

Версия устарела. Рекомендую апгрейд до 5.1.49.


innodb_flush_log_at_trx_commit=2
Сброс логов будет реже. Это типа должно снизить надежность, но на практике достаточно более-менее надежной машины (хотя бы наличие UPS).

innodb_thread_concurrency = 4
Рекомендуемая формула: 2 * число ядер проца.

Попробуй partitioning. Минимизируй количество индексов.

Ну, а памяти мало никогда не бывает... Улыбаюсь


Макс, я про заполнение блоков - в них много свободного места остается. Меньше блоков - меньше IO. Если данные не будут модифицироваться, то это свободное место не нужно.
« Последнее редактирование: 03-08-2010 14:06 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
McZim
Модератор

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #8 : 03-08-2010 14:09 » 

Цитата
Макс, я про заполнение блоков - в них много свободного места остается.

В блоках данных таблицы или индексов? Блоки таблицы настраиваются! Блоки индекса заполняются по мере того, поместится туда инфа или нет и можно ли ее в этот блок записать. Всегда можно сделать compress и rebuild.

Это все с точки зрения Oracle.

Цитата
Меньше блоков - меньше IO

Ну ты даешь Улыбаюсь
Записан

The CBO without stats is like a morning without coffee. (c) T.Kyte.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #9 : 03-08-2010 14:14 » 

Цитата
Меньше блоков - меньше IO

Ну ты даешь Улыбаюсь

Разве нет?...
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
McZim
Модератор

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #10 : 03-08-2010 14:25 » 

RXL, нет Улыбаюсь Ты путаешь, наверно, количество блоков таблицы и количество блоков при чтении!
Записан

The CBO without stats is like a morning without coffee. (c) T.Kyte.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 03-08-2010 14:28 » new

В MS SQL главное не Express-версию, там лимит на базу 2 Гб и однопроцессорная она. Это значит, что MS SQL будет платным.

Если база весит 50 Гб и постоянно растёт... по-моему для оперативной работы с такими объямами становится важной регулярная дефрагментация диска. Не вставок ради, но хотя бы ради запросов.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines