Собственно вопрос в сабже.

На сегодня активно работаем с MySql 5.1.48(кажись), в основном движок InnoDb. Пока справляется достаточно хорошо.
Сервер: 2 проца по 2 ядра (AMD64) 3.5Ггц, память что-то около 8Гб (4дырки по 2), диск raid1 "proffesional :)" 120..200 Мб/сек. Тянет на себе ПХП-сайт и все БД.

Сайт: Nginx + Appache(PHP+Zend) + memcache. Общая отдача (с ботами) около 100к в сутки. Пиково справляется до 170 одновременных обращений в секунду. На запрос к сайту, в среднем делается 3-5 обращений к БД со средним джойном в 5-15 таблиц из нескольких БД (3-5НФ). Некешированная выборка - от 0.1 до 3сек...

Базы на сегодня:
1. Основной справочник (фирмы, адреса, телефоны, люди и т.д.) - около 70_000 фирм, достаточно подробно.
2. Товарная база - около 400 000 товаров.
3. Статистика сервера - около 15млн записей, ежедневный прирост 150к шт.
4. Почтовый автомат (переписка посетителей + рассылки). Работает в виде ПХП демона там же - около 1.5млн писем, ежедневный прирост около 1тыс. шт.
Суммарно что-то около 60 гектар, может уже больше.

В связи с тем, что планируется строить большую экспертную систему на основе товарной базы и ожидается существенный прирост объемов товарной базы (в 10-100 раз), возник вопрос "а потянет ли этот чудо дальше?"

Ну и, как обычно, возникла мысля, а может экспертную систему (ЭС) лепить не на Мускуле?
В основе ЭС будет лежать большой сложно связанный граф. Ожидается средняя глубина в 10 вершин со средней ветвистотью около 25 ребер на узел, на товарную позицию (к счастью, не каждую).

А поскольку акромя Мускуля и когда-то давно MS ACCESS 97, и ещё давнее Borland Paradox 4.1 - ничего не едал... прошу помощи у сообщества...

miksoft,

1. Гоняем постоянно. Собственно система в активном развитии с 2008года. Как такового "production" - нет. То, что работает "для всех" - одна из реинкарнаций из общего репозитория разработчиков. Практически ежедневно делается очередной "svn up". :)
Есть большая внутренняя часть - СРМ система "для своих" (в т.ч. удаленно).

2. По узким местам: от сегодняшней нагрузки (это товарно-ценовой портал mediam.ru - около 20_000 полезных визитов в сутки) есть запас около 10 раз по работе серверной части, около 15 раз по вычислительной мощности (средняя нагрузка по htop 30-50% на одно ядро, остальные - 5-10%). Думаю это связано с крайне шустрой дисковой работой (последовательное чтение до 200мб/сек, время простоя на дисках innoDb по статусу не более 15%)... и innoDb уже матерится на недостаток памяти для мускуля, уже сейчас (конкретно недостаток индексного кеша или как он там называется).
... но там есть только 2 дырки, в которых стоит по 4 гектара (в первом посту ошибся)... так что можно ли нарастить - не знаю. В продаже больше 4Гб с ЕСС не видел (у нас).

3. По операциям с графом. Ожидается примерно следующий набор работ (отдельный демон и СУБД):

а) операции выборки всех подузлов, начиная с заданного (необязательно корневого). Типа "много и часто" - поиск, подготовка данных для ПО сайта и т.п. Большей частью можно по крону. В основном, результат выборки будет основой для выуживания данных из остальных БД...

б) операции вставки отдельных узлов (поштучно) в заданную вершину. Ожидается "пачками" (в смысле в много разных мест, но в каждое по одному и поштучно)... не так часто, но по многу и сразу (добавление знаний в экспертную систему). В основном режим "онлайн" - или "как посетителю вздумается". Пример: добавление нового прайс-листа (10-12500 позиций за раз, ограничено сверху нами).

в) перестройка графа (канонизация - перенос поддеревьев, удаление/вставка вершин, ребер). Отдельный фоновый процесс, в основном при снижении нагрузки на БД графа по чтению (например по крону).

Я догадываюсь, что возможно какой-нибудь mumps для ЭС подошел бы лучше (очень слегка ставил и знакомился)... но, недавно нашел плагин к Мускулю, который позволяет лазить из ПО непосредственно к индексам и прочим потрохам, обеспечивая скорости близкие к memcache (тест приводился для 8 ядер 3.5Ггц Intel и 32гектаров RAM)... вот и задумался стоит ли менять "шило на мыло"?.

Надеюсь, это поможет для ответа на вопрос "Стоит ли для реализации ЭС брать другую БД?" Сервер - один, и другой в ближайшее время не предвидится...

Arhat109, "друг, подай закурить! ... а в ответ - тишина, он вчера не вернулся из боя."

так никто и не выскажется?

ScareCrow,

Пасибки за целых 3 поста, жаль что все "ни о чем"... Мне показалось, что достаточно внятно написал "есть такой и другого НЕ предвидится", разве что - подарите, не? Тогда не надо давать советы, которыми нельзя воспользоваться.

По теме, что-то сказать - можете?

Повторю ещё раз вопрос: в связи с недостатком времени, изучать подробно "прочие" СУБД - у меня возможности нет.

Если можете ВНЯТНО сказать стоит ли переходить на другую бесплатную СУБД (кроме PostGreSQL альтернативы не вижу) или имеющийся MySQL наши задачи потянет "не хуже"?

Ну или чем одно лучше другого на таком железе и для такой задачи?

pkarklin, что конкретно Вам не понравилось в моих постах? Я задался вполне нормальным вопросом проектировщика, при начале нового проекта. Нет времени и денег - нормальное состояние. У Вас есть и то и другое? Значит Вы - безработный меценат, живущий на рентный доход. ;)

То что не хочу, чтобы тему превратили во флуд "чья пиписька тольщее"? Всё равно - УЖЕ превратили.

Меня интересовал конкретный ответ на конкретный вопрос. Мне его дали - "не стоит". За что пасибки автору. Чётко и понятно.
Времени разбираться ПОЧЕМУ - у меня нет.

Так что спасибо за участие, тему можно закрывать - мерялки проприетарных рекламистов меня ваще не интересуют.

Arhat109, жаль нельзя исправить... дополню:

Вот ответ "надо переходить на..." - обязан сопровождаться объяснением ПОЧЕМУ эти задачи в этих условиях полезно решать другими средствами.