Меня интересуют следующие базы данных: 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? (Поскольку я спрашиваю, я уверен, что ответ: «Не твое!»)
Моя система слишком медленная, и я пытаюсь улучшить ее производительность и эффективность.
Слишком мало памяти.
И, что самое важное - как и большинство людей, не знающих толком о базах данных - вы много говорите о ядрах и оперативной памяти (и Win 7 - избавьтесь от этого и установите Windows Server, пожалуйста), но полностью игнорируете одну вещь, наиболее важную для базы данных. производительность: ДИСКИ. Сколько дисков вы используете?
В качестве примера я запускаю базу данных Futures - и мой SQL Server имеет 6 Velociraptor, установленных ТОЛЬКО для данных, и еще 2 диска для tempdb и журналов. Это инфраструктура SAS с аппаратным RAID-контроллером. И я не уверен, что мне нравится производительность ввода-вывода;)
Более того, даже после завершения запроса наблюдается значительная активность диска.
Купите диски - или лучше SSD - чтобы получить мощную дисковую подсистему.
В конечном итоге вы столкнетесь с проблемой производительности, если будете полагаться на хранимые процедуры для больших наборов данных. Если вам нужно более быстрое время отклика, вы, вероятно, захотите выгрузить эти вычисления из СУБД.
РЕДАКТИРОВАТЬ:
Я сделал неверное предположение, что вы говорили о какой-то системе транзакций, в которой сложно вносить изменения в модель данных. Я работаю на большом предприятии, где это очень сложно. Вы также можете «разгрузить» вычисления, выполнив их один раз заранее.
Прежде чем что-либо делать, вам следует очень внимательно изучить планы запросов и понять, какие запросы используют больше всего ресурсов и почему. Подумайте о том, что вы на самом деле делаете - на примере вычисления скользящих средних учтите, что вы ссылаетесь на исторические данные, которые не меняются. Если вам нужно построить 52-недельную скользящую среднюю IBM за 1982–1992 годы ... зачем вычислять ее по запросу? Сделайте это заранее! Емкость хранилища обычно дешевая - IOPS и ЦП обычно дороги.
Еще я видел, как происходит чрезмерная нормализация (потому что это преподается как «правильный поступок»). Иногда, особенно для статических данных, денормализация улучшает производительность за счет исключения объединений.