Я работаю с базой данных postgresql, которая находится на действительно старом оборудовании.
1 Sun Sunfire V60x с одним 3,0 ГГц Xeon FSB 400 512 КБ кэш-памяти с 6 ГБ ОЗУ под управлением RHEL 4 (32 бит)
Табличное пространство и журналы хранятся в том же LUN емкостью 250 ГБ на Hitach 9520v SAN, на котором установлено 8 дисков USCSI со скоростью вращения 10 000 об / мин и каждый по 146 ГБ.
Наш бюджет ограничен, и, учитывая повышение производительности современных жестких дисков и дешевой оперативной памяти, мне интересно, сколько новых дисков со скоростью вращения 15 000 об / мин потребуется, чтобы обеспечить такую же производительность.
Табличное пространство составляет около 80 ГБ, и наша рабочая нагрузка, вероятно, составляет 90% чтения и 10% записи, поскольку RDMS содержит реестр нашей организации и [почти] используется только для отчетности.
Изменить: мы будем использовать новый сервер с 2x Xeon 5620 и 32 ГБ оперативной памяти. Интересно, смогу ли я избежать расходов на SAN.
Я не уверен, насколько больше будет оперативной памяти, если у вас 32-битная среда. Больше оперативной памяти было бы довольно недорогим обновлением, чтобы увидеть, насколько это поможет.
Новые диски 15k дадут вам некоторое улучшение производительности, в зависимости от того, где в настоящее время находится ваше узкое место. Если вы не привязаны к хранилищу, то трата денег на хранилище ничего для вас не сделает. Я думаю, вам нужно изучить показатели вашего сервера, прежде чем вы решите, на что потратить деньги.
(Мой опыт связан с использованием Microsoft SQL Server в Windows, но основная метрическая информация и основные принципы одинаковы.)
По правде говоря, инвестиции в жесткие диски дали бы только слабый улучшение в лучшем случае для доступа к диску. Я думаю, вы бы потратили большую часть своих денег, если бы вложились в новые диски. Что касается ОЗУ .... когда речь идет о СУБД, рекомендуется "БОЛЬШЕ". Неважно, сколько у вас есть, больше - лучше. Также не помешало бы провести профилирование и выяснить, где у вас проблемы. Возможно, вам просто нужно добавить индекс к одному или двум полям, и вы увидите ОГРОМНОЕ улучшение производительности.
SAN используется для экспорта блочных устройств. Единственное, что предлагает SAN, - это гибкость в хранении (единая точка хранения, любая точка монтирования по выбранной вами сети). По скорости вы не можете превзойти локальное подключенное хранилище в аппаратном (или программном) рейде ... если вам нужна скорость, самым простым, быстрым и дешевым (поскольку у вас уже есть жесткие диски) будет (IMHO) raid 10 (4 жестких диска в raid1 и оба тома в raid0), и это даст вам 2 x 146 ГБ памяти ... также 2 жестких диска в raid 1 и 4 x raid1 в raid0 также будут решением ... в любом случае на этом этапе и на этом размер настоятельно рекомендую посмотреть цены и емкость ssd .. 2 x 240 gb ssd (потребительские) в raid1 быстро курят!
Я предполагаю, что вы могли бы, по крайней мере, сопоставить производительность своего старого SAN с современным SSD-накопителем серверного уровня (или несколькими с хорошим контроллером RAID) и, вероятно, иметь гораздо лучшее время доступа.
Думали ли вы о программных сетях ISCSI SAN в качестве альтернативы, проверьте http://www.starwindsoftware.com/starwind. Вы сможете сократить расходы, получить централизованное хранилище и масштабируемое решение для кластеризации, если это то, что вы планируете сделать в будущем. В противном случае хранилище с прямым подключением, вероятно, удовлетворит ваши запросы ввода-вывода.