Mimic-code: Установка MIMIC-III в локальную базу данных Postgres выполняется медленно

Mac OS — Сьерра, версия 10.12.3

MIMIC-III версия 1.4

Первые несколько столов загружаются, так что вы идете в правильном направлении. Загрузка MIMIC может занять некоторое время, особенно таблицы chartevents, до которой вы доберетесь. Вы уверены, что у вас достаточно места на диске Macbook Air? Вам потребуется около 90 ГБ свободного места для базы данных.

Спасибо, что сообщили мне, что мне нужно иметь 90 ГБ свободного места для базы данных. У меня доступно 389 ГБ, так что место не проблема.

Когда вы загружали его, не могли бы вы сказать мне, какая у вас конфигурация машины и сколько времени ушло на загрузку MIMIC в postgres?

Я загрузил его на несколько разных машин, но ближайшая к вам система — это Macbook Pro 2,9 ГГц Intel Core i5 2013 года с 16 ГБ ОЗУ и твердотельным диском емкостью 1 ТБ. Я точно не помню, сколько времени занимает сборка, но обычно достаточно одной ночи.

Поскольку ваша система имеет более низкую спецификацию, вам может потребоваться оставить ее немного дольше. В качестве альтернативы попробуйте выполнить сборку на компьютере с более высокими характеристиками или, если вы просто хотите изучить данные, воспользуйтесь конструктором запросов MIMIC: https://mimic.physionet.org/gettingstarted/querybuilder/

Привет, Крупа, поскольку вы разместили вопрос на https://github.com/MIT-LCP/mimic-code/issues/182 , я предполагаю, что эта проблема теперь решена.

Чтобы добавить к этому, я только что собрал MIMIC с Postgres на MacBook Pro середины 2012 года с 8 ГБ ОЗУ.

Самой длинной командой была вставка данных в события диаграммы, что заняло почти 4 часа. Я предполагаю, что вся сборка заняла не более ~ 6 часов (я запускал ее всю ночь). Я настоятельно рекомендую отключить любой режим гибернации/сна, который автоматически выполняет ваш компьютер, так как это может прервать сборку. Для Mac OS X приложение «caffeine», устанавливаемое через Homebrew, действительно полезно для этой цели.

Большое спасибо за вашу помощь, доктор Поллард и Алистерев!

@alistairewj @tompollard Возможно, что-то вроде этого может быть полезно: (https://github.com/ossc-db/pg_bulkload)

У меня такая же проблема - postgres_load_data.sql работает два дня подряд! Таблицы заполняются, так как у меня была та же распечатка, что и у postgres-newbie выше. Я также проверил внутри pgadmin4, и select limit возвращает несколько строк таблиц допусков, вызовов и опекунов, но ничего для таблиц chartevents или chartevents_{N}.

Когда я остановил его в первый раз (я запустил его снова), он составил около 40 миллионов строк через 1 день, а это означает, что для загрузки всего этого потребуется неделя! Есть ли у вас какие-либо другие предложения по загрузке этого CSV в postgres? Для своей повседневной работы я использую фреймы данных Spark, которые могут легко загрузить более 1 миллиарда строк csv в df, так что это довольно неожиданная задача для меня! Цените любую помощь, которую вы можете предоставить!

Вы загружаете его через графический интерфейс или оболочку postgres?

5 декабря 2017 г., 22:47, «brokejoker» [email protected] написал:

У меня та же проблема - postgres_load_data.sql работает уже
два дня подряд! Таблицы заполняются, как у меня было то же самое
распечатка как postgres-newbie выше. Я также проверил внутри pgadmin4 и
select limit возвращает несколько строк госпитализаций, выноски и опекунов
таблиц, но ничего для таблиц chartevents или chartevents_{N}.

Когда я остановил его в первый раз (я начал снова), это было около
40 миллионов строк за 1 день, а это значит, что загрузка файла займет неделю.
Все это! Есть ли у вас какие-либо другие предложения по загрузке этого CSV в
постгрес? Для своей повседневной работы я использую фреймы данных Spark, которые могут легко загрузить 1
миллиард+ строк csv в df, так что это довольно неожиданная задача для меня!
Цените любую помощь, которую вы можете предоставить!

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/MIT-LCP/mimic-code/issues/181#issuecomment-349523656 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABOSdA7ulZzfdDrf3nU7uDqR9dp7tnDrks5s9g5ngaJpZM4MOwWg
.

командная строка через:
psql 'dbname=mimic user=rohunkshirsagar options=--search_path=mimiciii' -f postgres_load_data.sql -v mimic_data_dir='/Users/rohunkshirsagar/Documents/mimic-iii/data_files'

аналогично моей ситуации, я загружаю данные в postgresql на windows10 более 72 часов, я обнаружил, что диаграммы и подтаблица полны данных (330712483 строки), но я обнаружил, что процесс застрял на день, таблицы после таблицы chartevents пуст, и я проверяю, что сервер postgresql не работает (загрузка ЦП близка к 0, до этого около 33%), я не знаю, как это сделать, остановить это, что заняло у меня так много раз?

Есть несколько вещей, которые вы можете сделать, чтобы ускорить импорт, но я бы сначала проверил, не находится ли ваш компьютер в спящем режиме или что-то подобное. На моем ноутбуке, которому сейчас почти 5 лет, это занимает всего ~ 4 часа. Моему ПК с Windows ~ 3 года, и это заняло примерно столько же времени.

Если у вас все еще есть проблемы, есть много предложений, которые вы можете реализовать здесь: https://stackoverflow.com/questions/12206600/how-to-speed-up-insertion-performance-in-postgresql .

Загрузка данных в postgresql на macbook pro 2016 i5-8G Ram заняла более 24 часов, запущен один процесс postgre с одним потоком.
Я следую руководству https://mimic.physionet.org/tutorials/install-mimic-locally-ubuntu/ и устанавливаю caffiene, почему Windows 10 и macbook pro занимают так много времени? какие-либо настройки для postgresql?

Я устанавливаю postgresql 9.6.6 на macbook pro и windows10 с конфигурацией по умолчанию.

Я, честно говоря, не знаю, что сказать, кроме «ну, у меня работает!». Похоже, ваш компьютер более чем способен импортировать данные, поэтому я не думаю, что проблема связана со сценариями здесь или конкретно с MIMIC-III.

У меня такая же проблема на макбуке про. Но я когда-либо создавал базу данных на своем компьютере. И мое решение состояло в том, чтобы сделать резервную копию базы данных и восстановить ее в моем MBP, используя «pg_dump dababase -U username -f dbdump.sql» и «psql -U username -d database -f dbdump.sql» в cmd и терминале соответственно.

Я использую macOS Sierra на довольно новом iMAC и Postgres 10. Что исправило крайнюю медлительность для меня, так это использование сценария postgres_create_tables_pg10.sql для создания таблиц вместо сценария postgres_create_tables.sql . Поскольку для сборки всего я использовал Makefile, я отредактировал строки 75 и 115 в Makefile, заменив 'postgres_create_tables.sql' 'postgres_create_tables_pg10.sql' на ' postgres_create_tables.sql '. Мой скрипт загрузки работал примерно через 2 часа!

Интересно. Единственным отличием является синтаксис декларативного разделения в
Скрипт pg10 (только pg10) по сравнению с триггером при вставке в старом.

22 декабря 2017 г., 10:44, «sanfordbaran» [email protected] написал:

Я использую macOS Sierra на довольно новом iMAC и Postgres 10. Что
исправлена ​​крайняя медлительность для меня было использовать
Скрипт postgres_create_tables_pg10.sql для создания таблиц вместо
скрипт postgres_create_tables.sql. Поскольку я использовал Makefile для
построить все, я отредактировал строки 75 и 115 в Makefile, заменив
'postgres_create_tables_pg10.sql' для 'postgres_create_tables.sql. Мой
скрипт загрузки запустился примерно через 2 часа!

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/MIT-LCP/mimic-code/issues/181#issuecomment-353622522 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABOSdEdkcKo55kz9nAfzc_m-keM4HRwbks5tC85lgaJpZM4MOwWg
.

Просто хотел взвесить.

Запуск setup.sh в контейнере Docker занял 29 часов. Я подозреваю, что причина, по которой это заняло так много времени, заключается в том, что данные были записаны на жесткий диск (он занимает 71 ГБ с индексами). Кроме того, тот факт, что мне не удалось заставить Docker использовать более 1 ядра ЦП (на i7 4770k) при выполнении команд COPY из postgres (или чего-либо еще в этом отношении).

См. № 362, где мы обсуждаем это, так как это, вероятно, связано с недавним изменением разделения событий диаграммы.

Мы все еще тестируем скорость сборки, поэтому было бы здорово узнать ваше время.