Мы создаем приложение, в котором у каждого клиента будет своя база данных. Ни одна из баз данных не является особенно большой (от 20 МБ до 400 МБ каждая), но их будет ~ 5000 для запуска и в любой момент около 100 будут активными.
Наша команда обсуждала, как лучше всего настроить систему. Клиенты обращаются к своей базе данных только раз в 2 недели (401 КБ / финансовая обработка) и используют ее только 10-30 минут за раз. Операции равномерно распределяются между чтением / записью.
Половина нашей команды считает, что в результате мы должны распределить базы данных по нескольким дешевым серверам и просто использовать SQL Express ... они говорят, что память / кеширование не будут столь же полезными, учитывая короткий период времени, в течение которого каждая база данных используется (мы у вас нет бюджета для полного стандарта SQL на более чем 1 сервере).
Так ли это? Более высокий предел памяти - единственное преимущество, которое, как я вижу, дает нам стандарт MSSQL (у нас уже есть скрипты для резервного копирования / восстановления, обновления схемы, переноса данных и т. Д.).
Обновить
Меня особенно интересуют характеристики производительности нескольких баз данных по сравнению с одной базой данных. Разве для конечного пользователя не было бы лучше работать с одной базой данных 200 МБ, чем с базой данных 1 ТБ (даже если бы обе были хорошо проиндексированы)? Это также означает, что мы можем легко создавать резервные копии / восстанавливать базы данных одного клиента очень и очень быстро, верно? Нужно ли нам настраивать SQL Server, чтобы лучше справляться со сценарием «тысячи баз данных»?
Кинул бы все на один сервер. Поддержание нескольких дешевых серверов sql express будет проблемой. Вы можете распределить базы данных, журналы и временную базу данных по различным дисковым массивам RAID. Вам следует подумать о переносе своей временной базы данных в собственный массив, так как она может использоваться всеми базами данных одновременно.
Ознакомьтесь с регулятором ресурсов 2008 года, чтобы убедиться, что ни один пользователь не запустит сканирование сервера. Но это только в корпоративной версии.
Джесс,
Не зная больше о вашей среде или шаблонах использования, я скажу, что вы можете увидеть повышение производительности с каждым клиентом, имеющим свою собственную базу данных (то есть тысячи меньших баз данных по сравнению с одной большой базой данных). Вы можете потенциально снизить вероятность блокировки таблиц и строк, поскольку клиенты будут использовать только свой собственный уникальный набор таблиц, а не совместно использовать набор таблиц. Однако дисковый ввод-вывод по-прежнему будет ограничивающим фактором.
Кроме того, безопасность будет более ясной, поскольку каждая база данных будет иметь свой собственный уникальный набор разрешений для каждого клиента. Как вы заявили, резервное копирование и восстановление будет намного быстрее с меньшими базами данных, но настройка и обслуживание этих заданий резервного копирования будут чрезвычайно сложными (но похоже, что вы уже это учли).
Если у вас есть оборудование, я настоятельно рекомендую настроить разные RAID-массивы для ваших данных, журналов и TempDB (как предложил Сэм). Если вы используете какое-то хранилище с прямым подключением или SAN и можете позволить себе дополнительные массивы, вы можете даже подумать о разделении фактических файлов для ваших баз данных на разные массивы.
HTH, Дэн
Если вы предлагаете хостинг для многопользовательского клиентского доступа, у вас также есть возможность корпоративного лицензирования в качестве Поставщик услуг, что может оказаться значительно дешевле, чем покупка стандартной лицензии на процессор, а стоимость может эффективно переложить на вашу услугу помесячную цену.
Развертывание нескольких экземпляров SQL Express для размещения на самом деле против рекомендаций.
Хотя он немного устарел в отношении SQL 2008 и R2, я рекомендую прочитать официальный документ Руководство по развертыванию SQL Server 2005 для сред веб-хостинга, руководство применимо не только к веб-хостингу, но и к другим средам хостинга и многопользовательской среде.
Ваша самая большая проблема, вероятно, будет связана с резервным копированием; Если вы используете SQL Express, у вас нет агента для их запуска, вам придется полагаться на запланированные задачи Windows и некоторые причудливые сценарии.
Если вы используете SQL Std / Ent Edition и пытаетесь использовать встроенные планы обслуживания для резервного копирования всех баз данных, он будет выполнять их по одной, и это может занять некоторое время. То же самое для резервных копий журналов.
Даже не думайте об использовании зеркалирования с таким количеством баз данных на сервере.
Я бы предпочел больше серверов с хорошо продуманной стратегией аварийного переключения.
Еще одно соображение, о котором вы должны помнить, - это периферийные затраты на обслуживание тысяч баз данных SQL, распределенных по «множеству дешевых серверов». С увеличением количества серверов требования к пространству в стойке возрастают, а также увеличиваются затраты на питание и охлаждение центра обработки данных с помощью всего дополнительного оборудования. Не говоря уже об увеличении административных затрат / времени из-за необходимости поддерживать несколько серверов по сравнению с одним сервером.
Здесь следует учитывать добавление нескольких файлов в tempdb и файлы db, распределенные по нескольким дискам. Затем SQL может распределять чтение и запись по шпинделям ... см. https://stackoverflow.com/questions/719869/how-to-spread-tempdb-over-multiple-files
Пожалуйста, не поймите это неправильно. У вас могут быть веские причины делать то, что вы делаете. С того места, где я нахожусь, я не понимаю, зачем кому-то нужно иметь несколько тысяч баз данных. Мне кажется, что в вашем приложении есть недостаток дизайна, и теперь вы ищете способы преодолеть его, не исправляя. Я бы серьезно рекомендовал пересмотреть фундаментальный дизайн базы данных.
Сказав это: если есть веские (возможно, юридические) причины иметь такое количество баз данных, учтите это: достойный MS SQL Server может легко обрабатывать несколько сотен небольших баз данных (500 x 400 МБ = 200 ГБ данных, что не является проблемой). Это должно принести более чем достаточный доход, чтобы не беспокоиться о дополнительных лицензиях SQL Server. Затем вы можете разделить их, просто назвав или любым другим методом по вашему выбору.
Или вы можете рассмотреть возможность использования MySQL, где лицензирование не является такой проблемой (хотя я понимаю, что это не вариант, если вы интенсивно используете хранимые процедуры).