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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : ???
To : Igor Vaskov
Subj : Посоветуйте СУБД
> > И так с каждым показателем. Проблема в том, что у БД будет до 16 пользователей, каждый из которых может работать с 8 пациентами одновременно (не обязательно разными; один пользователь может читать давление Иванова Ивана Ивановича, второй писать новые данные о давлении, третий читать его полный анализ крови, четвёртый писать уровень гемоглобина, а всем остальным может внезапно понадобиться полная и тотальная инфа об Иване Ивановиче Иванове, включая угол кривизны его прямой кишки). Каждый пользователь БД генерирует от 5 до 10 операций записи в минуту для каждого из обслуживаемых им пациентов. Как я уже говорил, пациентов может быть до 8, так что запросы на запись могут генерироваться ежесекундно. Каждым из 16 пользователей! Операции чтения генерируются на порядок чаще. Что посоветуете?
>
> Детальный анализ нагрузки я конечно не проводил, но по моим прикидкам MySQL выдержит.

Я слышал про мускул много плохого. Что ещё сейчас имеет смысл использовать? Моя БД крайне примитивна, поэтому возможности СУБД не интересуют, главное - скорость и надёжность. SQLite плохо справляется с реальной нагрузкой, PostgreSQL - монстр, DB2 - тем более...

> Включите кэш запросов и будет все хорошо.

Меня заинтересовал проект Drizzle, но в нём нет кэша запросов. - mysql-na-steroidah

> Кроме того в высоконагруженных базах обычно применяется денормализация. Постройте базу данных так, чтобы запрос читал данные из одной таблицы, а не связывал много разных. Это увеличивает объем данных за счет дублирования информации, но позволяет снизить время блокировки таблиц.

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

Wed 16 Mar 2011 09:19 Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Ge



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.