Уважаемые господа!
Подскажите пожалуйста новичку, что выбрать бесплатное для Linux. Халява от Oracle/IBM/MS не проходит по процессорам, памяти, производительности (а использовать много экземпляров не хочется).

Нужно чтобы было бесплатно,
ODBC,
размер базы - 100 Гб.,
будет исполняться на железе, где 24 процессора, 128 Гб оперативки, и крутится аналитика, а базу не хочется выносить на отдельный сервер.

Максимальный приоритет для Insert-ов.
кол-во Insert-ов 100 тыс. в сек.,
тайм-аут 15 сек.,
Insert-ы идут 5 дней в неделю, оставшиеся 2 дня - реорганизация индексов, обновление статистики (т.к. не получается у меня использовать кластерные индексы - иногда не успевает до тайм-аута).

Средний приоритет Select.
кол-во 100 в сек.,
тайм-аут 30 сек.
Тяжёлые запросы разбиты на отдельные сессии, которые исполняются так, чтобы не создавать пиковых нагрузок.

Низкий приоритет - Update, Delete.
Исполняется когда низкая загруженность ресурсов.

Переписать код - не составляет никаких сложностей.

Поясняю:
Максимум бывает Insert-ов 100 тыс. в сек. в определённые часы суток. При этом желательно удерживать тайм-аут 15 сек. База больше чем 100 Гб. не распухает.

P.S.
Всё работает очень хорошо под MS Datacenter по отдельности. Отдельный сервер - отдельная база - отдельная таблица.
На прикладном уровне разруливается что куда посылать и что откуда запрашивать. Но стоит всё это немеренно, если лицензионно!!! Поэтому и возник вопрос: может уже появилась какая-либо халява, чтобы сделать "всё в одном" и без диких трат?

Большое спасибо!
Буду копать на досуге.

Ну, если уж про MS, то:

1. Standard Edition может адресовать максимум 64 Гб. - не подходит.
2. Enterprise Edition позволяет установить только до 25 экземпляров - тут около сотни экземпляров, каждый на своём приоритете, со своей маской ProcessorAffinity. Иначе низкоприоритетные запросы иногда могут "заткнуть" высокоприоритетные.

Конечно, это всё легко разносится на десяток серверов с Standart Edition, но стоимость железа + ОС + SQL - выше.

Действительно имеются в виду Instance.

Несколько "инстантов" обслуживают приём данных, с высоким приоритетом на зарезервированных только для них процессорах и "складывают" всё в сотню баз с суммарным размером в сотню Гб. Старые базы просто sp_detach_db. И дальше файлы перемещаются на backup.

Остальные "инстанты" обслуживают аналитику. Соответственно приоритеты у них другие, процессоры другие и диски другие. Но это уже не так важно, т.к. это уже не realtime. Просто, что-то более приоритетно, что-то менее.

Resource Governor не используется.

Т.к. аналитические приложения сначала использовали MS SQL 7.0 , потом 2000, потом 2005. Сейчас 2008. Причём, каждое приложение - свой собственный сервер для промежуточных результатов и общий датацентр для общих результатов. При этом, всё потихоньку консолидировалось и масштабировалось. Поэтому и выросла куча экземпляров.

Resource Governor конечно же попробую, но не в 2008. Как то страшновато пробовать первую редакцию. Вдруг ещё его отменят...

SERG1257, согласен, всё правильно, так делают все.
Всё, что я видел, сделано именно так.

Но очень хочется поизвращаться.

Интересная арифметика...

Если бутылку водки будут пить из горла трое, то никак не получится по стакану на каждого. Кто-то выпьет больше, а кто-то меньше. Притом, бывает, что первый выпивает практически всё. Но остальным ведь тоже выпить надо! Поэтому бывают недовольные.

Следующий раз уже пьют из стаканов. Всем поровну. Но кому-то ещё мало, а кому-то уже много. Снова есть недовольные.

Тогда решают догоняться пивом. Вроде всем хватило. Но всё равно есть недовольные, т.к. все скидывались, а не все пили.

Тогда решают так: следующий раз купить бутылку водки и бочонок пива. Каждый что хочет, то и пьёт. Если что останется - на следущий раз. Если не хватит - скидываться снова. Главное взять четвёртого, чтобы развёз всех домой и наливать ему только пиво и только по 100 гр.

А Вы говорите бутылка на троих = по стакану. Не так всё просто!

Дело в том, что точно сказать, базу какого именно размера приложение создаст на конкретном экземпляре не представляется возможным. Можно лишь ограничивать этот конкретный экземпляр в ресурсах, чтобы его функционирование не привело к нарушению требований ко временным характеристикам системы. Больше данных - больше точность. Меньше данных - больше скорость. Баланс производительности определяется через мониторинг скорости исполнения запросов. При достижении нижнего порогового значения производительности, увеличивается ограничение на кол-во записей в запросе. При достижении верхнего порогового значения, уменьшается ограничение на кол-во записей. В нерабочее время неиспользуемые записи удаляются. (Хотя, конечно, некрасиво. Но не хочется усложнять всё сегментированием, чтобы не наделать ошибок.) Файлам баз расти не разрешается т.к. они нефрагментированы и выровнены по отношению к страйпу RAID-ов. Recovery model Simple, поэтому логи отдыхают. Все сортировки в tempdb которые на высокоскоростных массивах. У разных экземпляров разные приоритеты и разные ProcessorAffinity. Если вдруг оказывается, что какое-то аналитическое приложение нужно поднять в приоритете, то не нужно вновь пересматривать маски ProcessorAffinity или добавлять памяти чтобы случаем что-либо не напортить, а достаточно отключить базу от экземпляра и подключить к другому экземпляру. Приложения бывают почти одинаковыми и отличается вообще неизвестно чем - поэтому их базы не могут существовать в одном экземпляре (хотя всё можно переписать). Некоторые приложения создают базы по 40 Гб., некоторые по 100 Mb. Какое начнёт расти предположить нет возможности. Количество приложений меняется время от времени. Соответственно наблюдаются и "пустые" экземпляры, которые "ждут" своих приложений. Есть также несколько высокоприоритетных приложений, для которых экземпляры исполняются на выделенных процессорах. Также имеется множество приложений, которые исполняются на своих собственных серверах, и которые планируется перенести.

Собственно, пока вижу 2 основных пути:

1. Постараться избавиться от этого множества экземпляров серверов и оставить только один MS SQL Enterprise на высоком приоритете на всех процессорах. Приоритеты распределять через Resource Governor.

2. Получать не Insert-ы а уже готовые файлы. Перенести триггеры и курсоры из баз в сами приложения на этап загрузки данных. Мигрировать на Linux. Использовать что-то бесплатное для накопления результатов. Но остаётся вопрос, что делать, если нужно "покопаться"? Загружать все данные на SQL сервер?

Вариант 1 получается решить ещё дешевле.

Достаточно 2 экземпляра Standard.
Один на высоком приоритете (для входящих данных), другой на среднем (для промежуточных и исходящих).
Использование ресурсов сервера мониторится из приложений. Запросы запускаются на исполнение, только когда нагрузка на ресурсы падает до определённого уровня. Сами приложения динамически меняют свои приоритеты, в зависимости от важности приложения и устаревания данных (чтобы не заснуть навсегда). Теряется примерно 0.3% производительности, но зато всё такое "отзывчивое".

Всем большое спасибо, что помогли расширить кругозор!
Форум - суперский.

Самый последний вариант не подходит. Standard не хочет закреплять страницы в памяти и время от времени конкретно напрягает диски. Приходится вернуться к Enterprise, но с управлением по ресурсам с приложений.