Добрый день!

Ситуация:

Сейчас есть база на MySQL состоящая из 112 таблиц, в среднем по 10-50 Мб на таблицу, но есть пара тяжелых таблиц с документами - 20Гб и 15Гб, по которым идет FULLTEXT поиск.
В среднем поиск нужного документа идет по 10-15 таблицам(кто/когда сделал, какой проект, участники, и.т.д) - можно сказать довольно тяжелый - 5-7 секунд на поиск.
Активных пользователей - 50 штук, поисковых запросов в день на одного пользователя - 70-100.
Бывает что одновременно захотят искать около 10 пользователей.
Плюс постоянно (около 1-2 в секунду) мелких запросов на всех.
Все подключаются через веб-клиент, там же и загружают документы, около 50-60 в день.
На сервере принимающая программа написана на perl - она почти не занимается никаким вычислениями или проверками - тупо формирует запрос CALL, принимает ответ и отдает клиенту.

Проблема 0:
Все это работает на быстрых таблицах MYISAM, без связей с таблицами и транзакциями.
Здесь без вопросов - надо будет переделывать на InnoDB, так что будет работать еще медленнее.

Проблема 1:
Невозможно искать в определенном месте в документа (большинство документов однотипные). Надо перевести все это в XML(если есть решение лучше - скажите), и искать там по полям, что MySQL не может(пока).

Проблема 2:
Хотим подключить еще один сервер в другом городе - пользователей добавится +30.
Надо, чтобы они работали со своим сервером, чтобы экономить траффик и разгрузить основной сервер. Каким образом это сделать? Если Интернет упадет - как базы будут синхронизироваться?
В идеале - пропал инет - можно только искать по базе - появился инет - синх - можно добавлять.
Более того надо вести лог - кто куда лазил и что делал.

Проблема 3:
В течении года пользователей может добавится до 300, офисов - до 10.
Соотвественно БД вырастет до 100 Гб.

Справится ли MySQL с такой нагрузкой?
Какую БД выбрать?
Сколько она будет стоить (пожалуй самый главный вопрос)?
С точки зрения БД все запросы идут от одного аккаунта.

DPHКак я понимаю, основная проблема с производительностью в полнотекстовом поиске по большим таблицам?

Тогда проще и дешевле всего настроить кластер writeOne-readAny на MySQL(через репликацию) , разделить пользователей по отдельным базам. Решение стандартное, много где описанное.
Тут придется тратиться на железо, правда. Но зато можно легко увеличивать скорость выполнения запросов.
Как себя ведет репликация MySQL на неустойчивом канале - не знаю.

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

Плюс переписывать подстилку на perl - работу с двумя серверами, что никак не упрощает разработку.
Хотелось всё это переложить на БД.

Но решение приемлимое, на самом деле. Осталось проверить восстановление.

Yo.!с ораклом бы выглядело так:
документы можно хранить в базе как blob или как bfile на фс оси. bfile можно синхронизировать rsync или чем то типа того. full text search из коробки обучен только английским словоформам. репликация - обычная мастер-мастер, аудит - тоже стандартная фича. стоит $5K на сокет (standart edition one)


rsync *nix-овая команда или oracle? Если хранить blob в базе тогда оно не надо?
full text search - надо докупать или он в коробке?
Опять же 5К$ на сокет это плюс к основному дистрибутиву(48К$ на сервер)?
Таких денег только астрономы не боятся.

Yo.![quot arrrght]
rsync *nix-овая команда или oracle? Если хранить blob в базе тогда оно не надо?

юниксовая, если блоб - не надо через репликацию думаю пойдет (хотя bfile может тоже пойдет через репликацию ... хз).

arrrght
full text search - надо докупать или он в коробке?

в коробке, но он по запросу "понос" найдет только "понос" и не найдет "поносный", "дерьмо" и т.п.


Класс. Спасибо. По деньгам должен пройти. Пройдет.
Уже установил один на Linux, осталось поставить второй на себя(XP) и сломать основной :)
В идеале все должно идти полностью автоматом.
Попробую.

А как насчёт Informix?
Там есть что-то подобное? А такое впечатление что кроме Oracle больше нет вариантов.
В конце концов можно как-нибудь обойтись без FTS, но репликация нужнее.
В идеале будет стоять много не очень сильных машин, на каждый офис.

chel_2000 AAronДостаточно стандартная реализация. В любом из серверов Oracle, MS, Sybase (ASA), DB2 нормально решаются вопросы репликации.
Нормально решаются вопросы с репликацией на хороших каналах связи. А на плохих кроме как у Sybase решаются не очень хорошо. Imho, выбор "что больше нравится на хороших каналах-Sybase на нехороших."

Sybase стоит немерянно :
Разговаривал с манагером - он мне на мой духголовый сервер насчитал 96К$ !!