(Memindahkan jawaban saya dari Menggunakan PostgreSQL dalam memori dan menggeneralisasikannya):
Anda tidak dapat menjalankan Pg dalam proses, dalam memori
Saya tidak tahu cara menjalankan database Postgres dalam memori untuk pengujian. Apakah mungkin?
Tidak, itu tidak mungkin. PostgreSQL diimplementasikan dalam C dan dikompilasi ke kode platform. Tidak seperti H2 atau Derby Anda tidak bisa hanya memuat jar dan jalankan sebagai DB dalam memori sekali pakai.
Tidak seperti SQLite, yang juga ditulis dalam C dan dikompilasi ke kode platform, PostgreSQL juga tidak dapat dimuat dalam proses. Ini membutuhkan banyak proses (satu per koneksi) karena ini adalah arsitektur multiprosesor, bukan multithreading. Persyaratan multiprosesing berarti Anda harus luncurkan postmaster sebagai proses mandiri.
Sebaliknya:konfigurasikan koneksi terlebih dahulu
Saya sarankan hanya menulis tes Anda untuk mengharapkan nama host/nama pengguna/kata sandi tertentu berfungsi, dan memiliki test harness CREATE DATABASE database sekali pakai, lalu DROP DATABASE di akhir lari. Dapatkan detail koneksi database dari file properti, bangun properti target, variabel lingkungan, dll.
Aman untuk menggunakan instance PostgreSQL yang sudah ada, Anda sudah memiliki database yang penting bagi Anda, selama pengguna yang Anda berikan untuk pengujian unit Anda tidak pengguna super, hanya pengguna dengan CREATEDB hak. Paling buruk Anda akan membuat masalah kinerja di database lain. Saya lebih suka menjalankan instalasi PostgreSQL yang sepenuhnya terisolasi untuk pengujian karena alasan itu.
Sebaliknya:Luncurkan instance PostgreSQL sekali pakai untuk pengujian
Atau, jika Anda benar-benar tertarik Anda dapat meminta harness uji Anda menemukan initdb dan postgres binari, jalankan initdb untuk membuat database, modifikasi pg_hba.conf untuk trust , jalankan postgres untuk memulainya di port acak, buat pengguna, buat DB, dan jalankan tes. Anda bahkan dapat menggabungkan biner PostgreSQL untuk beberapa arsitektur dalam toples dan membongkar yang untuk arsitektur saat ini ke direktori sementara sebelum menjalankan pengujian.
Secara pribadi saya pikir itu adalah rasa sakit utama yang harus dihindari; jauh lebih mudah untuk hanya memiliki DB uji yang dikonfigurasi. Namun, ini menjadi sedikit lebih mudah dengan munculnya include_dir dukungan di postgresql.conf; sekarang Anda cukup menambahkan satu baris, lalu menulis file konfigurasi yang dihasilkan untuk sisanya.
Pengujian lebih cepat dengan PostgreSQL
Untuk informasi lebih lanjut tentang cara aman meningkatkan kinerja PostgreSQL untuk tujuan pengujian, lihat jawaban terperinci yang saya tulis tentang topik ini sebelumnya:Optimalkan PostgreSQL untuk pengujian cepat
Dialek PostgreSQL H2 bukanlah pengganti yang sebenarnya
Beberapa orang malah menggunakan database H2 dalam mode dialek PostgreSQL untuk menjalankan tes. Saya pikir itu hampir sama buruknya dengan orang-orang Rails yang menggunakan SQLite untuk pengujian dan PostgreSQL untuk penyebaran produksi.
H2 mendukung beberapa ekstensi PostgreSQL dan mengemulasi dialek PostgreSQL. Namun, hanya itu - sebuah emulasi. Anda akan menemukan area di mana H2 menerima kueri tetapi PostgreSQL tidak, di mana perilaku berbeda, dll. Anda juga akan menemukan banyak tempat di mana PostgreSQL mendukung melakukan sesuatu yang tidak bisa dilakukan H2 - seperti fungsi jendela, pada saat menulis.
Jika Anda memahami keterbatasan pendekatan ini dan akses database Anda sederhana, H2 mungkin baik-baik saja. Tetapi dalam hal ini Anda mungkin kandidat yang lebih baik untuk ORM yang mengabstraksi basis data karena Anda tidak menggunakan fitur-fiturnya yang menarik - dan dalam hal ini, Anda tidak perlu terlalu peduli dengan kompatibilitas basis data lagi.
Ruang tabel bukanlah jawabannya!
Jangan jangan gunakan tablespace untuk membuat database "dalam memori". Tidak hanya itu tidak perlu karena tidak akan membantu kinerja secara signifikan, tetapi juga cara yang bagus untuk mengganggu akses ke yang lain yang mungkin Anda pedulikan di instalasi PostgreSQL yang sama. Dokumentasi 9.4 sekarang berisi peringatan berikut:
PERINGATAN
Meskipun terletak di luar direktori data PostgreSQL utama, tablespace merupakan bagian integral dari cluster database dan tidak dapat diperlakukan sebagai kumpulan file data yang otonom. Mereka bergantung pada metadata yang terkandung dalam direktori data utama, dan oleh karena itu tidak dapat dilampirkan ke cluster database yang berbeda atau dicadangkan satu per satu. Demikian pula, jika Anda kehilangan tablespace (penghapusan file, kegagalan disk, dll), cluster database mungkin menjadi tidak terbaca atau tidak dapat untuk memulai.Menempatkan tablespace pada sistem file sementara seperti ramdisk berisiko terhadap keandalan seluruh cluster.
karena saya melihat terlalu banyak orang yang melakukan ini dan mengalami masalah.
(Jika Anda telah melakukannya, Anda dapat mkdir direktori tablespace yang hilang untuk membuat PostgreSQL memulai lagi, lalu DROP database yang hilang, tabel dll. Lebih baik tidak melakukannya.)
