Какая база данных (СУБД) может наилучшим образом использовать несколько ядер и больше памяти?
Базы данных, которые меня интересуют: SQL Server 2008, MySQL и PostgreSQL 9.0.
В общем, мне интересно, кто из них "увеличит масштаб" лучше всего. Я читал, что PostgreSQL раньше масштабировался лучше, чем MySQL, но эта разница сократилась с более новыми версиями MySQL.
В дополнение к общей информации, я также ищу советы для моей конкретной ситуации:
У меня есть 64-битная база данных SQL Server 2008 R2 Developer Edition с данными за 20 лет и данными о вариантах за 2 года. Аппаратное обеспечение - Intel i7 Extreme с 6 ядрами, 12 ГБ оперативной памяти, 64-битная Windows 7.
База данных довольно большая и интенсивные вычисления, такие как скользящие средние, могут занимать до 7 минут. Кроме того, существует значительная активность диска даже после того, как запрос конкурирует. Я делаю все вычисления в хранимых процедурах прямо сейчас.
Моя система работает слишком медленно, и я пытаюсь улучшить ее производительность и эффективность. В настоящее время я улучшаю свою модель данных и настраиваю настройку программного обеспечения. Какие-либо предложения?
Кроме того, когда кто-то должен рассмотреть возможность использования MySQL Cluster? (Поскольку я спрашиваю, я уверен, что ответ "Не твой!")
2 ответа
Моя система работает слишком медленно, и я пытаюсь улучшить ее производительность и эффективность.
Слишком мало памяти.
И, самое главное, как и большинство людей, которые действительно не знают о базах данных, вы много говорите о ядрах и оперативной памяти (и о Win 7 - избавьтесь от него и установите Windows Server, пожалуйста), но полностью игнорируете одну самую важную вещь для базы данных. производительность: диски. Сколько дисков вы запускаете?
Например, я запускаю базу данных Futures - и на моем SQL-сервере для данных установлен набор 6 Velociraptor JUST и еще 2 диска для базы данных tempdb и журналов. Это на инфраструктуре SAS с аппаратным RAID-контроллером. И я не уверен, что мне нравится производительность IO;)
Кроме того, существует значительная активность диска даже после того, как запрос конкурирует
- Слишком мало оперативной памяти
- Нормальное поведение Трансацитональные базы данных (и таковы значения скользящих средних) всегда тяжелы на диске. Обычные компьютеры сосут за базы данных именно по этой причине. В документации есть большой раздел о том, как SQL Server (вынужден использовать) использует диски.
Получите диски - или лучше SSD - чтобы получить мощную дисковую подсистему.
В конечном итоге вы столкнетесь с кирпичной стеной с точки зрения производительности, если будете полагаться на хранимые процедуры для больших наборов данных. Если вам нужно более быстрое время отклика, вы, вероятно, захотите посмотреть на выгрузку этих вычислений из СУБД.
РЕДАКТИРОВАТЬ:
Я сделал неверное предположение, что вы говорите о некой транзакционной системе, в которой сложно вносить изменения в модель данных. Я работаю на большом предприятии, где это очень сложно. Вы также можете "разгрузить" вычисления, выполнив их один раз, заблаговременно.
Прежде чем что-то делать, вы должны очень тщательно изучить планы запросов и понять, какие запросы используют больше всего ресурсов и почему. Подумайте о том, что вы на самом деле делаете - на примере вычисления скользящих средних учтите, что вы ссылаетесь на исторические данные, которые не меняются. Если вам нужно построить 52-недельное скользящее среднее значение IBM за 1982-1992 годы... зачем вычислять его по требованию? Сделай это заранее! Емкость хранилища обычно дешевая - IOPS и процессор, как правило, дороги.
Еще одна вещь, которую я видел, это то, что люди чрезмерно нормализуют (потому что это преподается как "правильный поступок"). Иногда, особенно для статических данных, удаление нормализаций повышает производительность за счет исключения соединений.