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


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

Ну и под Осью этого форка нет тоже (если есть желание портировать, я буду только за). Кэш запросов - это не главное, но снижает нагрузку на диск - меньше износ оборудования.
Кроме того, ошибки есть в любом программном продукте. А MySQL очень много где используется и сравнительно хорошо отлажен и документирован.

>
> > Кроме того в высоконагруженных базах обычно применяется денормализация. Постройте базу данных так, чтобы запрос читал данные из одной таблицы, а не связывал много разных. Это увеличивает объем данных за счет дублирования информации, но позволяет снизить время блокировки таблиц.
>
> Спасибо за совет. [skip] Интересно, я изобрёл велосипед? Или наоборот, никто так никогда не делал, ибо маразм?
Лет 20 назад ;) Я делал что-то похожее в высоконагруженных пейджинговых системах. Работало замечательно. Файловая система Оси (HPFS в то время) прекрасно справляется с большим количеством файлов в каталоге, очень быстро ищет и открывает файл (b-tree).
Однако сейчас все-таки лучше использовать SQL сервера. Это стандарты разработки. Выше совместимость, меньше время разработки. Сколько времени уйдет на реализацию твоей идеи? Сколько еще понадобиться, чтобы отладить и избавиться от ошибок?



Wed 16 Mar 2011 15:44 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.11) Gecko/20



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.