Мы собираемся развернуть двойное веб-приложение / внутреннее транзакционное приложение, в котором каждый клиент имеет свою собственную базу данных. Каждая база данных очень мала - менее 50 МБ каждая, поэтому нам было интересно, имеет ли смысл использовать SQL Express 2008 вместо полноценного SQL Server.
Похоже, что это дает преимущества в распределении дискового ввода-вывода между серверами при одновременной экономии огромных долларов (поскольку небольшие диски 15 КБ и используемые двухъядерные серверы стоят недорого). Если в какой-то момент нам понадобится слишком много серверов, мы можем перейти на SQL Server ... но с десятками внутренних пользователей это сейчас кажется слишком дорогим (особенно с учетом того, что нам понадобится аварийный блок).
1 ГБ памяти и использование 4 ядер на одном процессоре не кажутся слишком ограничительными, учитывая наши небольшие размеры базы данных. У нас никогда не будет более ~ 200 одновременных пользователей, и большинство операций будут более транзакционными (что, кажется, предпочтительнее для большого количества высокоскоростных дисков, чем для тяжелой оперативной памяти / процессора, верно?)
Не хватает ли мне каких-либо преимуществ SQL Server Standard, которые могли бы оправдать дополнительные инвестиции в размере 5-20 тысяч долларов на начальном этапе?
В других выпусках SQL Server есть такие вещи, как агент SQL, чтобы вы могли планировать обслуживание базы данных и другие задания.
Пока ваша база данных может соответствовать ограничениям Express edition, с вами все будет в порядке.
SQL-серверу нравится много оперативной памяти. Чем больше, тем лучше. Поскольку SQL Server не может загружать данные в кеш, это создает дополнительную нагрузку на диски. Вам следует взглянуть на версию SQL Server Web Edition или Workstation. Эти выпуски имеют более высокие ограничения, чем экспресс-выпуск, но стоят меньше, чем стандартная версия.
Если вы все же начнете с выпуска Express, вы всегда сможете обновить его до Standard Edition после покупки лицензии.
Несколько производственных проблем и обходных путей, которые у меня были с выпуском Express:
Запланированное резервное копирование
SSIS
Профилирование
Если вы читаете лицензию SQL Server, вам не нужно покупать дополнительную лицензию для пассивного сервера, если он используется исключительно для аварийного переключения и не обслуживает запросы до тех пор, пока не выйдет из строя ваш первый сервер.
Мы довольно долго использовали SQL Server Express, и он хорош и намного лучше, чем предыдущий MSDE, у нас более 200 имитирующих соединений, но у нас есть только одна база данных размером 2 ГБ, и все работает гладко. У нас никогда не было проблем при условии, что мы избегаем дорогостоящих объединений и выполняем хорошую индексацию. Сейчас мы используем SQL Standard, но пока размер вашей базы данных не превышает 4 ГБ, а количество пользователей меньше 200-500, вы, безусловно, можете жить с SQL Express.
SQL Server Express использует немного меньше памяти ~ 200 МБ, тогда как в стандартной версии используется ~ 1,5 ГБ, вероятно, потому, что стандартная версия будет выполнять много кэширования. Ваши запросы в Express будут выполняться медленнее на несколько миллисекунд по сравнению со стандартной версией. К сожалению, в Express edition не используется многоядерный процессор (это ограниченная функция), поэтому не будет большой помощи, если у вас 2 ядра или 4 ядра.
LuckyLindy - я бы посоветовал вам остановиться всего на секунду и убедиться, что вам не нужен агент SQL. Вы написали:
Мы собираемся развернуть двойное веб-приложение / внутреннее транзакционное приложение, в котором каждый клиент имеет свою собственную базу данных. Каждая база данных очень мала - менее 50 МБ каждая, поэтому нам было интересно, имеет ли смысл использовать SQL Express 2008 вместо полной версии SQL Server.
Какой у вас план резервного копирования? Вам не обязательно использовать агент SQL, но он, несомненно, облегчает жизнь администраторам баз данных. Вы можете написать T-SQL / SMO / PowerShell / любые сценарии, которые делают ваши резервные копии, а затем выполнять через sqlcmd или PowerShell с помощью запланированной задачи.
Каков ваш план обслуживания базы данных? Со временем эти базы данных необходимо будет дефрагментировать и проверять на целостность. В Standard Edition есть всевозможные полезности, чтобы сделать это e-a-s-y, тогда как в Express вам нужно работать (опять же со сценариями и запланированными задачами).
Как вы будете уведомлены о проблемах на сервере? Агент помогает здесь с помощью предупреждений, чтобы уведомить вас, когда журнал заполняется, диск заполняется и т. Д.
Это критические задачи типа администратора баз данных SQL Server. Одно дело запускать Express для внутреннего приложения, но как только вы начинаете говорить нам, что размещаете их для клиентов, я забеспокоился :)
Часть 2 Вас интересует, сколько клиентов вы планируете поддерживать в этом направлении - как при запуске, так и через год? Если вы скажете «100 клиентов», то 100 баз данных по 50 МБ будет недостаточно для Express - вам просто не хватит памяти. Черт возьми - в зависимости от того, какая у вас дельта, вы можете получить максимум 15 DB, я не знаю.
У нас никогда не будет более ~ 200 одновременных пользователей, и большинство операций будет более транзакционным (что, кажется, предпочтительнее для большого количества высокоскоростных дисков, чем для тяжелой оперативной памяти / процессора, верно?)
Транзакционные операции, такие как INSERT, по-прежнему записываются в память, поэтому не ожидайте, что вам потребуется меньшая поддержка памяти. Фактически, в зависимости от того, сколько INSERT вы делаете, вам может потребоваться больше памяти, чем большинству с таким количеством пользователей. Если вы загружаете много данных, которые люди на самом деле не будут использовать, они все равно будут занимать память. Вы можете столкнуться с конфликтами между «данными, которые пользователи часто запрашивают» и «данными, которые загружают пользователи и которые некоторое время никто не будет запрашивать». SQL защищает нас, сохраняя данные, которые люди запрашивают чаще, в памяти дольше, но у вас по-прежнему будет конкуренция.
В этот момент я болтаю, лол. И 200 одновременных пользователей мне тоже не подходят для Express. Скажем, 64 КБ - это среднее требование к памяти для подключения, сколько подключений будут выполнять ваши приложения? Будете ли вы использовать пул соединений?
В общем, мое чутье после прочтения вашего описания говорит: «Нет, Express Edition просто недостаточно мощный». И я ненавижу Workgroup Edition - считаю, что это плохая сделка - поэтому Standard мне кажется правильным.
Вы рассматривали возможность использования одной из бесплатных СУБД (MySQL, PostgreSQL ...)? Это могло бы облегчить ваши опасения по поводу лицензирования?
Если это не вариант, SQL Server Express кажется хорошим решением.
Его, безусловно, можно использовать для важных производственных приложений. Мы использовали его в более чем 1500 медицинских клиниках, все с отдельными экземплярами SQL Server Express, установленными для обработки миллионов транзакций каждый день. Вы можете легко обойти недостаток агента SQL Server, используя одно из следующих средств:
См. Отличную презентацию Майкла Оти (в Google) на тему «Использование SQL Server Express в производственной среде».