Единая Система Выписывания Рецептов?

http://www.computerworld.com/action/... — 100 лимонов уе. Что это — попил денег или реальная попытка? Поминте, был спор на базе про плохой почерк у докторов и результирующие ошибки? Вот теперь хотят сделать единую систему. Плюсы очевидны — система ведёт учёт несовместимых лекарств, уменьшается количество ошибок из-за почерка, быстрее заполнение — доктор может послать запрос на выполнение прямо из оффиса. Но и минусы есть — огромная такая база — как обеспечить безопасность? Вариант для удалённого убийства — выписать кому-то рецепт такой, что приведёт к смерти пациента. Что делать, если система выйдет из строя?

Блин, я за 500 баксов за две недели сделаю им систему, еще за 50000 можно купить мощный сервер. Компьютеры в больницах и так есть. Отмывание денег в чистом виде. А безопасность... Хуже чем есть никак не будет.

Это единая система по США, в которую уже входят 99% фармацевтов. Проблема в том, чтобы подключить ещё и докторов.

А насчёт за две недели сделаю — можешь попробовать прикинуть, только должен знать, что она должна работать 24х7 с возможностью полного бэкапа и восстановления и горячего переключения. Попробуй уложиться со всеми обновляемыми транзакциями в 5-10 секунд времени. Количество обновлений в день явно превысит десятки мегабайт в день.

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

10 мегов в сутки это мелочи, а система описания лекарств вообще не из этой оперы

Abaddon> 10 мегов в сутки это мелочи

В смысле - вы имеете опыт написания подобных систем?

Сервер l2 - реальная расчетная мощность на текущий момент до 1000 онлайна, каждый по 5+ Мб трафика в час. Получается около 120 Гб трафика в сутки. Сотни тысяч запросов в БД, таблицы с миллионами записей. И сотни мегабайт логов. Вполне достаточно чтобы оценить сложность задачи.

Abaddon> Сервер l2 - реальная расчетная мощность на текущий момент до 1000 онлайна, каждый по 5+ Мб трафика в час. Получается около 120 Гб трафика в сутки. Сотни тысяч запросов в БД, таблицы с миллионами записей. И сотни мегабайт логов. Вполне достаточно чтобы оценить сложность задачи.

И что, как у вас с обеспечением безотказности? Что будет, если сервер упадет? Сколько человек вас пытаются взломать? Есть ли многомегабайтные (а лучше многогигабайтные)апдейты?

Большая часть упомянутого или реализуется существующим ПО (защита), или упирается в мощность серверов (скорость, надежность).

Abaddon> Сервер l2 - реальная расчетная мощность на текущий момент до 1000 онлайна, каждый по 5+ Мб трафика в час. Получается около 120 Гб трафика в сутки. Сотни тысяч запросов в БД, таблицы с миллионами записей. И сотни мегабайт логов. Вполне достаточно чтобы оценить сложность задачи.

1000? Мы говорим о 50,000-100,000 легко. А у меня, пардон, Oracle 10g не справляется с моими запросами — на приличной машине не хочет вставлять более 4,000 записей в секунду. Про mySQL говорить вообще не буду. А 5МБ в час — это 1389 байт в секунду на клиента. Сколько из них реально идут в качестве обновлений в базу?

И все эти 100000 одновременно дергают бд? Ерунда, на самом деле базу будут дергать не так уж часто. Что, все врачи только тем и занимаются что сидят и выписывают рецепты тысячами? Тем более что тут не требуется быстрый отклик, даже 10 секунд на выполнение запроса приемлимы. Тем более что никто не заставляет делать один сервер на весь мир, это легко паралелится. Тем более что это все не обязательно хранить в одной таблице, погашеные рецепты можно отправлять в архив. Тем более что можно использовать что-то вроде RamDrive для таблицы активных в текущий момент рецептов. Она врядли будет больше 4 Гб, а скорость RamDrive позволяет увеличить в сотни раз.

Полярный зверек...
Врач-рецепт-больной - это сверхинтимная цепочка. Уже применение промышленных лекарств и забвение провизорского искусства - уже проблема.

Ник

Abaddon> Тем более что можно использовать что-то вроде RamDrive для таблицы активных в текущий момент рецептов.




Abaddon>Она врядли будет больше 4 Гб, а скорость RamDrive позволяет увеличить в сотни раз.




Вам в Гугль с такими талантами надо. Они, бедные, маются со своими смешными задачками, вы б им рассказали, как оно на самом деле делается - через "что-то вроде RamDrive"!

PS Кстати, а из каких соображений вы поставили ограничение в 4G? Вот, скажем, одну только таблицу наименований лекарств вы примерно как оцените?

Abaddon> И все эти 100000 одновременно дергают бд? Ерунда, на самом деле базу будут дергать не так уж часто.

Ну, посчитай докторов и всех фармацевтов. Их будет больше 100,000. Одновременно будут не все, но много — больше 1000.


Abaddon> Что, все врачи только тем и занимаются что сидят и выписывают рецепты тысячами?

В день? Больше 1000.

Abaddon> Тем более что тут не требуется быстрый отклик, даже 10 секунд на выполнение запроса приемлимы.

Да, 10 секунд приемлемы для доктора, но не для фармацевта.

Abaddon> Тем более что никто не заставляет делать один сервер на весь мир, это легко паралелится.

Конечно, никто не заставляет, только надо чтобы вся база была доступна всем — у меня доктора сидят в 5 разных городах. Плюс, если я в командировке, то могу пойти к любому доктору из сети. Плюс все покрытые госпиталя.

Abaddon> Тем более что это все не обязательно хранить в одной таблице, погашеные рецепты можно отправлять в архив.

Можно. Только рецепт действует пол-года. И есть последствия потребления лекарств (скажем, особенно для женщин — нельзя беременеть после приёма в течении года), из-за которых нельзя их переводить в архив достаточно долго. Есть сведения (например, аллергия) которые никогда нельзя переводить.

Abaddon> Тем более что можно использовать что-то вроде RamDrive для таблицы активных в текущий момент рецептов. Она врядли будет больше 4 Гб, а скорость RamDrive позволяет увеличить в сотни раз.

Не знаю, когда мы автоматизировали FMC у нас таблицы были легко превосходящие 4 ГБ. И одного пациента легко может быть более 30 рецептов. Практически все люди старше 60 имеют более 6 рецептов. Таких людей здесь 25% — четверть от 300,000,000.

Wyvern-2> Полярный зверек...
Wyvern-2> Врач-рецепт-больной - это сверхинтимная цепочка. Уже применение промышленных лекарств и забвение провизорского искусства - уже проблема.
Wyvern-2> Ник

Ник, эта цепочка давно нарушена — страховые компании практически всегда знают всё про предписанные лекарства (и много чего другого). Этому уже лет 20 как.

Единственный способ избежать — платить всегда и за всё самому. Только это дорого очень.

Ник, don't be mad — get Glad!

Abaddon>> И все эти 100000 одновременно дергают бд? Ерунда, на самом деле базу будут дергать не так уж часто.
Mishka> Ну, посчитай докторов и всех фармацевтов. Их будет больше 100,000. Одновременно будут не все, но много — больше 1000.
Abaddon>> Что, все врачи только тем и занимаются что сидят и выписывают рецепты тысячами?
Mishka> В день? Больше 1000.
1000 это с учетом того что 99% загрузки сервера вовсе не БД, а сам сервер - домашняя машинка изрядной древности.
Сергей-4030> PS Кстати, а из каких соображений вы поставили ограничение в 4G? Вот, скажем, одну только таблицу наименований лекарств вы примерно как оцените?
А кто сказал что это принципиальное ограничение? Таблицу наименований - пара мегабайт.
Сергей-4030> Вам в Гугль с такими талантами надо. Они, бедные, маются со своими смешными задачками, вы б им рассказали, как оно на самом деле делается - через "что-то вроде RamDrive"!
Не надо передергивать. Поисковые системы - это много терабайт информации и огромные нагрузки. А тут... Ну миллион запросов в сутки. Ну 10 миллионов. А у меня 500000 в сутки держит домашняя машинка с athlon 2500+ и обычным очень старым винтом, и загрузка ее mysql - меньше 1%.

Таблица наименований (химических) - может, и пара мегабайт.

А еще разница между коммерческими названиями и химическими названиями (10 коммерческих на 1 химическое = легко) ну и т.д.

А еще смеси.

А еще то, что взаимодействия всего со всем надо учитывать.

1) Не пойму при чем тут таблица наименований к полной базе по лекарствам, мы вроде делаем базу рецептов
2) Даже mysql может делать выборку по многосотмегабайтным таблицам за доли секунды, даже без RamDrive. Таблица на 38054 элемента с динамическим форматом, 137 байт средний размер строки, 5 мегабайт вес. select distinct по ключевому полю за 0.0228 секунд. Это очень трудный запрос если не знаешь. А сервер слабый.

Abaddon> 1) Не пойму при чем тут таблица наименований к полной базе по лекарствам, мы вроде делаем базу рецептов

Эх, разработчик. Прочитай исходные. Там взаимодействие лекарств описано, что с чем можно, что с чем нельзя, какие осложнения, что когда можно, что когда нельзя, при каких болезнях можно, при каких нельзя. Я же в самом начале написал — чтобы ошибок было меньше.

Abaddon> 2) Даже mysql может делать выборку по многосотмегабайтным таблицам за доли секунды, даже без RamDrive. Таблица на 38054 элемента с динамическим форматом, 137 байт средний размер строки, 5 мегабайт вес. select distinct по ключевому полю за 0.0228 секунд. Это очень трудный запрос если не знаешь. А сервер слабый.


Я же тебе сказал — дай данные по обновлениям — update, insert, delete. А не по select.

Abaddon> select distinct по ключевому полю за 0.0228 секунд. Это очень трудный запрос если не знаешь. А сервер слабый.

Ты ничего не путаешь? По ключевому? Distinct? А на кой хрен? Может по индексному?

Abaddon>> 1) Не пойму при чем тут таблица наименований к полной базе по лекарствам, мы вроде делаем базу рецептов
Mishka> Эх, разработчик. Прочитай исходные. Там взаимодействие лекарств описано, что с чем можно, что с чем нельзя, какие осложнения, что когда можно, что когда нельзя, при каких болезнях можно, при каких нельзя. Я же в самом начале написал — чтобы ошибок было меньше.
Хм... Но один фиг это не даст серьезной нагрузки.

Abaddon>> 2) Даже mysql может делать выборку по многосотмегабайтным таблицам за доли секунды, даже без RamDrive. Таблица на 38054 элемента с динамическим форматом, 137 байт средний размер строки, 5 мегабайт вес. select distinct по ключевому полю за 0.0228 секунд. Это очень трудный запрос если не знаешь. А сервер слабый.
Mishka> Я же тебе сказал — дай данные по обновлениям — update, insert, delete. А не по select.

Тип запроса	Количество с момента запуска	В час	В % от всех запросов
insert	26 M	10.37 k	25.75%
replace	7,167 k	2,854.55	7.09%
select	14 M	5,543.88	13.77%
stmt execute	69 M	27.54 k	68.41%
stmt prepare	9,966 k	3,969.15	9.86%
update	24 M	9,417.36	23.39%

примечание - большинство stmt execute это replace

Abaddon>> select distinct по ключевому полю за 0.0228 секунд. Это очень трудный запрос если не знаешь. А сервер слабый.
Mishka> Ты ничего не путаешь? По ключевому? Distinct? А на кой хрен? Может по индексному?
а по ключевому чтобы одинаковых значений в столбце не было, я просто первый попавшийся запрос с приличным временем исполнения сделал

Abaddon> Хм... Но один фиг это не даст серьезной нагрузки.

Даёт, к сожалению. Смотри, поля:
1. Клиент (имя, адрес, телефоны)
2. Страховка — номер группы, номер полиса, платежи по каждому виду.
3. Уникальный страховой ID пользователя. Раньше был SSN, сейчас другой — типа UUID.
4. Срок действия страховки.
5. Кем выписан рецепт (с полной контактной информацией и сертификацией).
6. Сроки действия рецепта.
7. Название лекарства.
8. Возможность замены лекарства на другой брэнд и новые цены.
9. Оригинальное химическое название или смесь.
10. Доза лекарства.
11. Расписание, как принимать (три раза в день, до еды за 30, 40, час, 2 часа перед сном и т.д.)
12. Сроки хранения лекарства.
13. Условия хранения лекарства.
14. Побочные эффкеты системного действия — может влиять на печень.
15. Побочные эффекты не системного действия — нельзя пить алкоголь или водить машину.
16. Комбинированные побочные эффекты с другими лекарствами.
17. Продолжительность эффектов после приёма.
18. Предельное количество, которое оплатит страховка.
19. Известные аллергии пациента.
20. Когда последний раз лекарства по рецепту были выданы — и напоминание, и чтобы раньше времени не пробовал получить.
21. Данные фармаколога, который выполнил заказ и его фирмы.

Может я ещё чего забыл.

А теперь посчитаем врачей — фармацевтов не буду — я в одном-двух-трёх местах их получаю.

1. Окулист.
2. Техник окулиста (очки он мне делает, контактные линзы тоже).
3. Мой терапевт.
4. Детский педиатр.
5. Мой эндокринолог.
6. Эндокринолог моей жены.
7. Кожники.
8. Хирурги и другие врачи госпиталя.
9. Зубные врачи — у нас их много — один общий, другой по дёснам, третий по удалению нервов, четвертый по удалению зубов, пятый по скобам, шестой по имплантам.
10. Медсестры в школах и детсадах.
11. Женские врачи.
12. Инфекционисты (это у нас в связи с положительной пробой на туберкулез).
13. Желудочно-кишечные специалисты (у жены язва).

Может ещё что-то забыл.

Abaddon> а по ключевому чтобы одинаковых значений в столбце не было, я просто первый попавшийся запрос с приличным временем исполнения сделал


У тебя update, replace — явно не по ключевым полям. Т.е. перестройки индексов нет.

А вопрос про ключевое поле был потому, что distinct (он же unique) там роли играть не должен — ключевое поле должно обеспечить уникальность, т.е. никакой сортировки, всё за один проход.

Abaddon>> Хм... Но один фиг это не даст серьезной нагрузки.
Mishka> Даёт, к сожалению. Смотри, поля:...
А что поля? Важно количество рядов, а количество полей на скорость практически не влияет. Кстати то как ты сделал - ужоснах. Выборка быстрая, но хранить столько дублирующейся инфы... Информация о клиентах отдельно, о лекарствах отдельно, о рецептах отдельно. В результате самая большая бд (собственно рецепты) будет выглядеть примерно так:

• id рецепта (primary autoincriment)
• id клиента (ключ к поиску по бд клиентов)
• id лекарства (ключ к поиску по бд лекарства)
• id серии выданного лекарства (добавляется update при погашении рецепта, для информации о сроках хранения итп, одновременно флаг того что лекарство получено)
• дата выписки
• дата погашения (не обязательно)
• текстовый комментарий (не обязательно)

такой инсерт будет выполнен моментально независимо от размера БД, поскольку уникальных полей в нем нету
Mishka> А теперь посчитаем врачей — фармацевтов не буду — я в одном-двух-трёх местах их получаю....
А это на что влияет? На общую загрузку разве что. Ты целыми днями по ним ходишь? Еще раз могу сказать, что неактуальные строки можно скидывать в архив, в котором обьем бд и скорость работы не играет особой роли (если надо узнать не было ли пациенту выписано не тех лекарств можно и минуту подождать ответа, хотя чтобы такую загрузку обеспечить надо туда еще не знаю что засунуть).
Abaddon>> а по ключевому чтобы одинаковых значений в столбце не было, я просто первый попавшийся запрос с приличным временем исполнения сделал
Mishka> У тебя update, replace — явно не по ключевым полям. Т.е. перестройки индексов нет.
Mishka> А вопрос про ключевое поле был потому, что distinct (он же unique) там роли играть не должен — ключевое поле должно обеспечить уникальность, т.е. никакой сортировки, всё за один проход.
Практически все запросы затрагивают ключевые поля, а порой еще многоуровневые джойны используются.

Abaddon> А что поля? Важно количество рядов, а количество полей на скорость практически не влияет.

Влияет, хотя и с меньшим коэффициентом. Особенно при вставке и наличии нескольких индексов.

Abaddon> Кстати то как ты сделал - ужоснах.

Где я сделал?

Abaddon> Выборка быстрая, но хранить столько дублирующейся инфы... Информация о клиентах отдельно, о лекарствах отдельно, о рецептах отдельно. В результате самая большая бд (собственно рецепты) будет выглядеть примерно так:

Правильно, нормализовать надо. Но именно тут начинает собака рыться — для нормального обновления надо достаточно много чего проверить, а для этого джойнты строить длнинные.

Abaddon> * id рецепта (primary autoincriment)
Abaddon> * id клиента (ключ к поиску по бд клиентов)
Abaddon> * id лекарства (ключ к поиску по бд лекарства)
Abaddon> * id серии выданного лекарства (добавляется update при погашении рецепта, для информации о сроках хранения итп, одновременно флаг того что лекарство получено)
Abaddon> * дата выписки
Abaddon> * дата погашения (не обязательно)

Обязательно. Т.к. рецепт действует полгода и по нему можно получать 6 раз. И отношения по выполнению — будет 1:N сразу. А отношения врачей, рецептов, клиентов в чистом виде становится N:M.

Abaddon> * текстовый комментарий (не обязательно)
Abaddon> такой инсерт будет выполнен моментально независимо от размера БД, поскольку уникальных полей в нем нету

??? Что значит фраза — уникальных полей в нем нет?

Mishka>> А теперь посчитаем врачей — фармацевтов не буду — я в одном-двух-трёх местах их получаю....
Abaddon> А это на что влияет? На общую загрузку разве что. Ты целыми днями по ним ходишь?

Я не хожу, но чтобы записаться к врачу — от месяца до трёх ждать надо. Это тебе так — сведения про загрузку врачей.

Abaddon> Еще раз могу сказать, что неактуальные строки можно скидывать в архив, в котором обьем бд и скорость работы не играет особой роли (если надо узнать не было ли пациенту выписано не тех лекарств можно и минуту подождать ответа, хотя чтобы такую загрузку обеспечить надо туда еще не знаю что засунуть).


Не будет врач ждать минуту. У него на стандартного пациента 15 минут. Это на всё про всё.

Abaddon> Практически все запросы затрагивают ключевые поля, а порой еще многоуровневые джойны используются.

И что с этого?