|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Я специалист по серверам стандартной архитектуры, но не по базам данный, поэтому проще помощи !!
Задача:
"Подсчет различного рода отчетов в БД. подсчет отчетов идет в хранимых процедурах с использованием временных таблиц на движке MEMORY и View.
количество одновременно подсчитываемых отчетов программно ограничивается (порядка 7 штук, но конкретное кол-во не принципиально).
Software:
FreeBSD 7.1
MySQL 6.0
Описание параметров БД:
порядка 150 таблиц. бОльшая часть таблиц справочная. таблиц, с которыми идет активная работа порядка 30-40.
если рассматривать построение отчета как некие OLAP-кубы, то ситуация примерно такая:
таблицы измерений содержат порядка 10 тыс. записей. View на них порядка 10 тыс*кол-во месяцев длительности акции (сейчас это 4).
таблицы фактов – порядка 400 тыс. записей и ежемесячный прирост порядка 100 тыс. записей.
вспомагательные таблицы отчетов (используются для хранения результатов и параметров отчетов) – порядка 1.5-2 млн. записей в месяц."
Сколько оперативы посоветуете поставить в сервак ?? Физическое ограничение - 256 ГБ (чудестный сервак IBM x3950m2 в максимальном исполнении)
Неактивен
Правильный ответ, конечно же, «чем больше — тем лучше» 
Разумеется, на объем данных влияет не только количество строк, но и длины этих строк. В идеальной
ситуации нужно, чтобы памяти хватало на то, чтобы кэшировать все индексы данных (+ еще оставалось
на разные буферы — сортировки, передачи по сети и т.п.).
Опять таки, влияет сильно характер запросов к таблицам. Например, таблица 100к строк (10G данных +
9G индекс) великолепно справляется с точечными запросами на 8G оперативки. С другой стороны, если
нужно будет объединить полнотекстовым сканом две такие таблички — такой сервер уйдет в себя с головой
на час минимум.
Если можете позволить себе менять/доставлять память, то попробуйте, например, начать с 32G (~26G в
innodb_buffer_pool и остальное по кусочкам) и понаблюдать за системой. Если производительности окажется
мало, то тогда добавить памяти.
Также учтите, что часто бывает гораздо дешевле разбить базу на несколько машинок (опыт показывает, что
поставить две машинки 32G гораздо дешевле, чем одну 64G). Не говоря уж об указанном Вам ограничении 
Разумеется, такое разбиение потребует каких-то дополнительных возможностей клиентских приложений.
UPD: А, да, заговорился, совсем забыл спросить то, что смущает Почему такой странный выбор ОС / версии MySQL?
Всегда думал, что IBM использует AIX / Linux. Ну и стабильная версия MySQL не повредит
Неактивен
А разве mysql поддерживает мультипроцессорность (SMP)? Насколько я знаю просто sql не держит ...
Неактивен
Не понял, как это следует из моего ответа
Да, поддерживает. Один запрос на несколько потоков, конечно, не режет, но каждое подключение
выполняется в отдельном потоке => разные соединения могут работать одновременно.
Неактивен
а он и не следует - это я уже дальше спросил )) Огромное спасибо - совет разбить БД на две машины реально сработал !! Еще раз спс
Неактивен
