Mimic-code: Menginstal MIMIC-III di database Postgres lokal lambat

Mac OS - Sierra, versi 10.12.3

MIMIC-III versi 1.4

Beberapa tabel pertama sedang dimuat, jadi Anda menuju ke arah yang benar. Memuat MIMIC mungkin memakan waktu cukup lama, terutama tabel chartevents, yang merupakan poin yang Anda dapatkan. Apakah Anda yakin bahwa Anda memiliki cukup ruang disk di Macbook Air? Anda akan membutuhkan sekitar 90GB ruang kosong untuk database.

Terima kasih telah memberi tahu saya bahwa saya perlu memiliki 90GB ruang kosong yang tersedia untuk database. Saya memiliki 389 GB yang tersedia, jadi ruang tidak menjadi masalah.

Saat Anda memuatnya, dapatkah Anda memberi tahu saya apa konfigurasi mesin Anda dan berapa lama waktu yang dibutuhkan untuk memuat MIMIC di postgres?

Saya telah memuatnya di beberapa mesin yang berbeda, tetapi sistem terdekat dengan Anda adalah Macbook Pro 2.9 GHz Intel Core i5 2013 dengan RAM 16GB dan solid state disk 1TB. Saya tidak ingat persis berapa lama waktu yang dibutuhkan untuk membangun, tetapi semalam biasanya cukup.

Karena spesifikasi sistem Anda lebih rendah, Anda mungkin perlu membiarkannya sedikit lebih lama. Atau, coba buat di mesin dengan spesifikasi lebih tinggi atau jika Anda hanya ingin menjelajahi data, lihat pembuat kueri MIMIC: https://mimic.physionet.org/gettingstarted/querybuilder/

Hai Krupa, saat Anda memposting pertanyaan di https://github.com/MIT-LCP/mimic-code/issues/182 , saya menganggap masalah ini sekarang telah teratasi.

Sebagai tambahan, saya baru saja membuat MIMIC dengan Postgres pada MacBook Pro pertengahan 2012 dengan RAM 8GB.

Perintah tunggal terpanjang adalah memasukkan data ke dalam chartevents, yang memakan waktu hampir 4 jam. Saya membayangkan seluruh pembangunan tidak memakan waktu lebih dari ~ 6 jam (saya menjalankannya dalam semalam). Saya sangat menyarankan untuk menonaktifkan hibernasi/tidur apa pun yang dilakukan komputer Anda secara otomatis karena dapat mengganggu proses build. Untuk Mac OS X, aplikasi "kafein" yang dapat diinstal melalui Homebrew sangat berguna untuk tujuan ini.

Terima kasih banyak atas bantuan Anda Dr. Pollard dan alistairewj!

@alistairewj @tompollard Mungkin yang seperti ini mungkin bermanfaat: (https://github.com/ossc-db/pg_bulkload)

Saya memiliki masalah yang sama - postgres_load_data.sql telah berjalan selama dua hari berturut-turut! Tabel semakin terisi karena saya memiliki cetakan yang sama dengan postgres-newbie di atas. Saya juga memeriksa di dalam pgadmin4, dan pilih batas mengembalikan beberapa baris tabel penerimaan, info, dan pengasuh, tetapi tidak untuk tabel chartevents atau chartevents_{N}.

Ketika saya menghentikannya pertama kali (saya memulainya lagi) sekitar 40 juta baris setelah 1 hari, yang berarti akan memakan waktu seminggu untuk memuat semuanya! Apakah Anda punya saran lain untuk memuat csv ini ke dalam postgres? Untuk pekerjaan harian saya, saya menggunakan spark dataframes, yang dapat dengan mudah memuat 1 miliar+ baris csv ke dalam df, jadi ini adalah tugas yang cukup mengejutkan bagi saya! Hargai setiap dan semua bantuan yang dapat Anda berikan!

Apakah Anda memuatnya melalui GUI atau shell postgres?

Pada 5 Desember 2017 22:47, "brokejoker" [email protected] menulis:

Saya memiliki masalah yang sama - postgres_load_data.sql telah berjalan selama
dua hari berturut-turut! Tabel semakin terisi karena saya memiliki hal yang sama
printout sebagai postgres-newbie di atas. Saya juga memeriksa di dalam pgadmin4, dan
pilih batas mengembalikan beberapa baris penerimaan, info, dan pengasuh
tabel, tapi tidak untuk tabel chartevents atau chartevents_{N}.

Ketika saya menghentikannya pertama kali (saya memulainya lagi) itu sekitar
40 juta baris setelah 1 hari, yang berarti perlu waktu seminggu untuk memuat
semuanya! Apakah Anda memiliki saran lain untuk memuat csv ini ke
postgres? Untuk pekerjaan harian saya, saya menggunakan kerangka data percikan, yang dapat dengan mudah memuat 1
miliar+ baris csv menjadi df, jadi ini adalah tugas yang cukup mengejutkan bagi saya!
Hargai setiap dan semua bantuan yang dapat Anda berikan!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/MIT-LCP/mimic-code/issues/181#issuecomment-349523656 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABOSdA7ulZzfdDrf3nU7uDqR9dp7tnDrks5s9g5ngaJpZM4MOwWg
.

baris perintah melalui:
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'

mirip dengan situasi saya, saya memuat data ke postgresql di windows10 selama lebih dari 72 jam, saya menemukan chartevents dan subtabel penuh data (330712483 baris), tetapi saya menemukan prosesnya macet selama sehari, tabel setelah tabel chartevents kosong, dan saya memeriksa server postgresql tidak berjalan (beban CPU mendekati 0, sebelum sekitar 33%), saya tidak tahu bagaimana melakukannya, hentikan yang memakan waktu berkali-kali?

Ada beberapa hal yang dapat Anda lakukan untuk mempercepat pengimporan, tetapi saya akan memeriksa terlebih dahulu apakah komputer Anda tidak hibernasi atau yang serupa. Hanya membutuhkan waktu ~4 jam di laptop saya, yang sekarang sudah hampir 5 tahun. PC Windows saya berusia ~3 tahun dan butuh waktu yang sama.

Jika Anda masih mengalami masalah, ada banyak saran yang dapat Anda terapkan di sini: https://stackoverflow.com/questions/12206600/how-to-speed-up-insertion-performance-in-postgresql

Butuh lebih dari 24 jam untuk memuat data ke postgresql di macbook pro 2016 i5-8G Ram, satu proses postgre dengan satu utas sedang berjalan.
Saya mengikuti tutorial https://mimic.physionet.org/tutorials/install-mimic-locally-ubuntu/ , dan menginstal caffiene, mengapa windows 10 dan macbook pro keduanya memakan waktu lama? ada konfigurasi untuk postgresql?

Saya sama-sama menginstal postgresql 9.6.6 di macbook pro dan windows10 dengan konfigurasi default.

Sejujurnya saya tidak tahu harus berkata apa, selain dari "yah, ini berhasil untuk saya!". Komputer Anda terdengar lebih dari mampu mengimpor data jadi saya rasa masalahnya bukan pada skrip di sini atau secara khusus berkaitan dengan MIMIC-III.

Saya memiliki masalah yang sama di macbook pro saya. Tapi saya pernah membangun database di PC saya. Dan solusi saya adalah membuat cadangan database dan memulihkannya di MBP saya, menggunakan 'pg_dump dababase -U username -f dbdump.sql' dan 'psql -U username -d database -f dbdump.sql' di cmd dan terminal masing-masing.

Saya menjalankan macOS Sierra pada iMAC dan Postgres 10 yang cukup baru. Apa yang memperbaiki kelambatan ekstrem bagi saya adalah menggunakan skrip 'postgres_create_tables_pg10.sql' untuk membuat Tabel alih-alih skrip postgres_create_tables.sql . Karena saya menggunakan Makefile untuk membangun semuanya, saya mengedit baris 75 dan 115 di Makefile, mengganti 'postgres_create_tables_pg10.sql' untuk ' postgres_create_tables.sql . Skrip pemuatan saya kemudian berjalan dalam waktu sekitar 2 jam!

Menarik. Satu-satunya perbedaan adalah sintaks partisi deklaratif di
skrip pg10 (hanya pg10) versus pemicu saat disisipkan di skrip yang lebih lama.

Pada 22 Desember 2017 10:44, "sanfordbaran" [email protected] menulis:

Saya menjalankan macOS Sierra pada iMAC dan Postgres 10 yang cukup baru. Apa
memperbaiki kelambatan ekstrim bagi saya adalah dengan menggunakan
'postgres_create_tables_pg10.sql' skrip untuk membuat Tabel alih-alih
skrip postgres_create_tables.sql. Karena saya menggunakan Makefile untuk
membangun semuanya, saya mengedit baris 75 dan 115 di Makefile, menggantikan
'postgres_create_tables_pg10.sql' untuk 'postgres_create_tables.sql. Ku
memuat skrip kemudian berjalan dalam waktu sekitar 2 jam!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/MIT-LCP/mimic-code/issues/181#issuecomment-353622522 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABOSdEdkcKo55kz9nAfzc_m-keM4HRwbks5tC85lgaJpZM4MOwWg
.

Hanya ingin menimbang.

Butuh 29 jam untuk menjalankan setup.sh dalam wadah Docker. Saya menduga alasan mengapa butuh waktu lama adalah karena data ditulis ke HDD (membutuhkan 71 GiB dengan indeks). Juga, fakta bahwa saya tidak dapat membuat Docker menggunakan lebih dari 1 inti CPU (pada i7 4770k) saat menjalankan perintah COPY dari postgres (atau apa pun dalam hal ini).

Lihat #362 di mana kita mendiskusikan hal ini karena kemungkinan terkait dengan perubahan terbaru seputar peristiwa bagan partisi.

Kami masih menguji kecepatan pembuatannya, jadi akan sangat bagus untuk mendapatkan waktu Anda.