RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > > И так с каждым показателем. Проблема в том, что у БД будет до 16 пользователей, каждый из которых может работать с 8 пациентами одновременно (не обязательно разными; один пользователь может читать давление Иванова Ивана Ивановича, второй писать новые данные о давлении, третий читать его полный анализ крови, четвёртый писать уровень гемоглобина, а всем остальным может внезапно понадобиться полная и тотальная инфа об Иване Ивановиче Иванове, включая угол кривизны его прямой кишки). Каждый пользователь БД генерирует от 5 до 10 операций записи в минуту для каждого из обслуживаемых им пациентов. Как я уже говорил, пациентов может быть до 8, так что запросы на запись могут генерироваться ежесекундно. Каждым из 16 пользователей! Операции чтения генерируются на порядок чаще. Что посоветуете?
> > > 
> > > Детальный анализ нагрузки я конечно не проводил, но по моим прикидкам MySQL выдержит.
> > 
> > Я слышал про мускул много плохого. Что ещё сейчас имеет смысл использовать? Моя БД крайне примитивна, поэтому возможности СУБД не интересуют, главное - скорость и надёжность. SQLite плохо справляется с реальной нагрузкой, PostgreSQL - монстр, DB2 - тем более...
> > 
> > > Включите кэш запросов и будет все хорошо.
> > 
> > Меня заинтересовал проект Drizzle, но в нём нет кэша запросов. - http://www.blogerator.ru/page/mysql-na-steroidah
> 
> Ну и под Осью этого форка нет тоже (если есть желание портировать, я буду только за). Кэш запросов - это не главное, но снижает нагрузку на диск - меньше износ оборудования.
> Кроме того, ошибки есть в любом программном продукте. А MySQL очень много где используется и сравнительно хорошо отлажен и документирован.
> 
> > 
> > > Кроме того в высоконагруженных базах обычно применяется денормализация. Постройте базу данных так, чтобы запрос читал данные из одной таблицы, а не связывал много разных. Это увеличивает объем данных за счет дублирования информации, но позволяет снизить время блокировки таблиц.
> > 
> > Спасибо за совет. [skip] Интересно, я изобрёл велосипед? Или наоборот, никто так никогда не делал, ибо маразм?
> Лет 20 назад ;) Я делал что-то похожее в высоконагруженных пейджинговых системах. Работало замечательно. Файловая система Оси (HPFS в то время) прекрасно справляется с большим количеством файлов в каталоге, очень быстро ищет и открывает файл (b-tree).
> Однако сейчас все-таки лучше использовать SQL сервера. Это стандарты разработки. Выше совместимость, меньше время разработки. Сколько времени уйдет на реализацию твоей идеи? Сколько еще понадобиться, чтобы отладить и избавиться от ошибок?
> 
>

_, _, _, / \ (_ / ~ ) \ / , ) / / ~ ~ ~~~