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
> 
> > Кроме того в высоконагруженных базах обычно применяется денормализация. Постройте базу данных так, чтобы запрос читал данные из одной таблицы, а не связывал много разных. Это увеличивает объем данных за счет дублирования информации, но позволяет снизить время блокировки таблиц.
> 
> Спасибо за совет. Я много думал, как оптимизировать свою БД и у меня родилась сумасшедшая идея. А что, если написать свою прогу для чтения и записи своих данных? Конечно, это не будет полноценная СУБД, но мне она и не нужна. Вот как я это себе представляю. БД организуем как набор файлов. Имя файла является ключом (например, IvanovIvan). В файле содержится неструктурированная информация (формат будет задан в моей программе, совместимость и расширяемость меня ведь не волнуют). Для работы с каждым пациентом форкается новый процесс, который считывает содержимое соответствующего файла и записывает в массив. Также запоминается, какой именно терминал хочет работать с этим пациентом. Учитывая, что позже этим пациентом может заинтересоваться и другой терминал, число терминалов является переменной. Когда переменная обнуляется, т.е. пациент никому уже не интересен, содержимое массива сбрасывается в тот же файл и процесс самоликвидируется. Никаких коллизий произойти не может в принципе, потому что терминалы будут опрашиваться по очереди. Процесс IvanovIvan будет спрашивать у каждого "заинтересованного" терминала: хочешь что-нибудь записать или прочитать? Если да, то происходит обмен информацией, причём практически мгновенно. Если нет, то переходим к следующему. Терминал действуют примерно по тому же принципу. Как только у него появляется потребность в чтении или записи каких-то данных, он входит в бесконечный цикл ожидания, когда соответствующий процесс-пациент обратит на него внимание. Опять же, коллизии невозможны в принципе. Вместо того, чтобы решать проблему, мы не допускаем её возникновения. Интересно, я изобрёл велосипед? Или наоборот, никто так никогда не делал, ибо маразм?

__, _,_ _, __, ___, \|_) \| \| \| \|_ ` / \| \ \| \| \| , \| / ~ ~ `~' ~~~ ~~~ ~~~