Как поддерживать высокую производительность в базе данных медицинского производства с миллионами строк

Question

У меня есть приложение, которое используется для отображения данных о пациентах во время пребывания в отделении интенсивной терапии (электронная запись c). Пациенты обычно подключены к нескольким устройствам (мониторы, вентилятор, диализ и т. Д. c.), Которые отправляют данные с интервалом в одну минуту. В среднем на одного пациента вставляется 1800 строк в час.

До сих пор модуль интеграции получает данные и сохраняет их в файлах на выделенном диске. Приложение считывает его оттуда и строит на графиках и в сетках данных.

Поскольку существует потребность в анализе, мы думаем о записи входящих сигналов немедленно в БД. Но есть много опасений по поводу производительности. Особенно в этой рабочей среде люди очень щепетильны, когда дело касается производительности.

Существуют ли какие-либо методы, помимо правильного индексирования, для смягчения возможного воздействия на производительность? Я думаю о работе по загрузке данных в специальную таблицу или, может быть, даже в другую базу данных, например, через 1 месяц после закрытия записи.

Есть ли опыт, как сохранить производственную БД небольшой и легкой?

Answer 1

Я понятия не имею, сколько пациентов у вас в отделении интенсивной терапии, но если у вас нет тысяч пациентов, у вас не должно быть никаких проблем - пока вы придерживаетесь вставок, используете переменные связывания и имеете столько свободных списков, сколько необходимо. Вставка создаст блокировки только в свободном списке. Таким образом, вы можете выполнять столько параллельных вставок, сколько есть свободных списков для определения свободного блока, в который следует записывать данные. Вы можете посмотреть обсуждение на сайте ra TKyte https://asktom.oracle.com/pls/asktom/f?p=100: 11: 0 :::: P11_QUESTION_ID: 950845531436

Обычно 1.800 записей в час (или 10-20 раз что) не много для любого приличного размера Oracle db. Если вам действительно интересно, вы можете выбрать разделение на основе Patient_id. Это будет особенно полезно, если вы:

• Доступ к данным только для одного пациента за раз, потому что вы можете просто пропустить все другие разделы.
• Если вы хотите удалить данные для пациент en blo c после выхода из интенсивной терапии. Вместо УДАЛЕНИЯ вы можете просто удалить разделы пациентов.

Answer 2

Определите «немедленно». Одна из лучших вещей, которые вы можете сделать для повышения производительности INSERT, - это группировать команды вместо того, чтобы запускать их по одной.

Каждый оператор SQL имеет накладные расходы - отправка оператора базу данных, анализируя ее (не забудьте использовать переменные связывания, чтобы вам не приходилось жестко разбирать каждый оператор), возвращая сообщение, et c. Во многих приложениях на эти накладные расходы уходит больше времени, чем на фактические INSERT.

Вам достаточно выполнить небольшую пакетную обработку, чтобы значительно сократить эти накладные расходы. Запуск INSERT ALL с двумя строками вместо двух отдельных операторов снижает накладные расходы на 1/2, запуск с тремя строками снижает накладные расходы на 2/3, и т. Д. c. Подождите минуту или даже несколько секунд, и это может иметь большое значение.

Пока вы избегаете распространенных ошибок, связанных с строкой за строкой, база данных Oracle с «миллионами» строк ничего не стоит беспокоюсь о. Вам пока не нужно думать о настройках таблицы crypti c или репликации.