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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Igor Vaskov
To : VadimT
Subj : Посоветуйте СУБД

> БД представляет собой нечто вроде картотеки, в которой данные с одной карточки не зависят от данных на другой карточке. Поэтому структура БД крайне примитивна, по сути это одна таблица с одним ключом. Ключ представляет собой текстовую строку, все остальные данные - числовые. Чтобы представить наглядно, пусть это будет медицинская БД, которая содержит текущие и средние результаты измерений давления и прочих жизненных показателей пациентов. Ключом является ФИО, к нему привязаны ЧислоИзмеренийДавления, ТекущееДавление, СреднееДавление. Очевидно, что при поступлении результата очередного измерения давления НовоеДавление происходят следующие вычисления:
>
> ПоследнееДавление = НовоеДавление;
> СреднееДавление = ЧислоИзмеренийДавления * СреднееДавление + ПоследнееДавление;
> ЧислоИзмеренийДавления = ЧислоИзмеренийДавления + 1;
> СреднееДавление = СреднееДавление / ЧислоИзмеренийДавления;
>
>
> И так с каждым показателем. Проблема в том, что у БД будет до 16 пользователей, каждый из которых может работать с 8 пациентами одновременно (не обязательно разными; один пользователь может читать давление Иванова Ивана Ивановича, второй писать новые данные о давлении, третий читать его полный анализ крови, четвёртый писать уровень гемоглобина, а всем остальным может внезапно понадобиться полная и тотальная инфа об Иване Ивановиче Иванове, включая угол кривизны его прямой кишки). Каждый пользователь БД генерирует от 5 до 10 операций записи в минуту для каждого из обслуживаемых им пациентов. Как я уже говорил, пациентов может быть до 8, так что запросы на запись могут генерироваться ежесекундно. Каждым из 16 пользователей! Операции чтения генерируются на порядок чаще. Что посоветуете?

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

Tue 15 Mar 2011 15:26 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.