Запуск PostgreSQL только в памяти

Я хочу запустить небольшую базу данных PostgreSQL, которая работает только в памяти, для каждого написанного мной модульного теста. Например:

@Before
void setUp() {
    String port = runPostgresOnRandomPort();
    connectTo("postgres://localhost:"+port+"/in_memory_db");
    // ...
}

В идеале у меня должен быть один исполняемый файл postgres, зарегистрированный в системе контроля версий, который будет использовать модульный тест.

Что-то вроде HSQL, но для postgres. Как я могу это сделать?

Могу ли я получить такую ​​версию Postgres? Как я могу запретить ему использовать диск?

Это невозможно с Postgres. Он не предлагает движок внутри процесса / в памяти, такой как HSQLDB или MySQL.

Если вы хотите создать автономную среду, вы можете поместить двоичные файлы Postgres в SVN (но это больше, чем просто один исполняемый файл).

Вам нужно будет запустить initdb для настройки вашей тестовой базы данных, прежде чем вы сможете что-либо с этим делать. Это можно сделать из командного файла или с помощью Runtime.exec (). Но учтите, что initdb - это не то, что быстро. Вы определенно не захотите запускать это для каждого теста. Однако вы можете уйти от этого до своего набора тестов.

Однако, хотя это можно сделать, я бы рекомендовал иметь специальную установку Postgres, в которой вы просто воссоздаете свою тестовую базу данных перед запуском тестов.

Вы можете воссоздать тестовую базу данных, используя базу данных шаблонов, что делает ее создание довольно быстрым ( намного быстрее, чем запуск initdb для каждого тестового запуска)

(Перемещаю свой ответ из раздела Использование PostgreSQL в памяти и обобщаю его):

Вы не можете запустить Pg в процессе, в памяти

Я не могу понять, как запустить базу данных Postgres в памяти для тестирования. Является ли это возможным?

Нет, это невозможно. PostgreSQL реализован на C и скомпилирован в код платформы. В отличие от H2 или Derby, вы не можете просто загрузить jarи запустить его как одноразовую базу данных в памяти.

В отличие от SQLite, который также написан на C и скомпилирован в код платформы, PostgreSQL также не может быть загружен в процессе. Для этого требуется несколько процессов (по одному на соединение), потому что это многопроцессорная, а не многопоточная архитектура. Требование многопроцессорности означает, что вы должны запускать postmaster как отдельный процесс.

Вместо этого: предварительно настройте соединение

Я предлагаю просто написать ваши тесты, ожидая, что определенное имя хоста / имя пользователя / пароль будет работать, и иметь тестовую привязку CREATE DATABASEк одноразовой базе данных, а затем DROP DATABASEв конце запуска. Получите сведения о подключении к базе данных из файла свойств, целевых свойств сборки, переменной среды и т. Д.

Безопасно использовать существующий экземпляр PostgreSQL, который у вас уже есть базы данных, о которых вы заботитесь, если пользователь, который вы указываете для своих модульных тестов, не является суперпользователем, а только пользователем с CREATEDBправами. В худшем случае вы создадите проблемы с производительностью в других базах данных. По этой причине я предпочитаю запускать полностью изолированную установку PostgreSQL для тестирования.

Вместо этого: запустите одноразовый экземпляр PostgreSQL для тестирования

С другой стороны , если вы действительно острыми вы могли бы иметь свой тест Жгут определить местонахождение initdbи postgresбинарных файлов, запускать , initdbчтобы создать базу данных, изменить , pg_hba.confчтобы trust, запустить , postgresчтобы запустить его на произвольный порт, создать пользователь, создать базу данных, и запустить тесты . Вы даже можете связать двоичные файлы PostgreSQL для нескольких архитектур в банке и распаковать файлы для текущей архитектуры во временный каталог перед запуском тестов.

Лично я считаю, что этого следует избегать; проще настроить тестовую БД. Однако с появлением include_dirподдержки стало немного легче postgresql.conf; теперь вы можете просто добавить одну строку, а затем написать сгенерированный файл конфигурации для всех остальных.

Более быстрое тестирование с PostgreSQL

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

Диалект PostgreSQL H2 не является настоящей заменой

Некоторые люди вместо этого используют базу данных H2 в режиме диалекта PostgreSQL для запуска тестов. Я думаю, что это почти так же плохо, как и люди из Rails, использующие SQLite для тестирования и PostgreSQL для производственного развертывания.

H2 поддерживает некоторые расширения PostgreSQL и имитирует диалект PostgreSQL. Однако это всего лишь эмуляция. Вы найдете области, где H2 принимает запросы, а PostgreSQL - нет, где поведение отличается и т . Д. Вы также найдете множество мест, где PostgreSQL поддерживает выполнение того, что H2 просто не может - например, оконных функций на момент написания.

Если вы понимаете ограничения этого подхода и у вас простой доступ к базе данных, H2 может подойти. Но в этом случае вы, вероятно, лучший кандидат на ORM, который абстрагирует базу данных, потому что вы все равно не используете ее интересные функции - и в этом случае вам больше не нужно так сильно заботиться о совместимости базы данных.

Табличные пространства - это не ответ!

Вы не использовать табличный для создания базы данных «в памяти». Это не только не нужно, так как это не сильно повлияет на производительность, но и отличный способ нарушить доступ к любому другому, что может вас заинтересовать в той же установке PostgreSQL. Документация 9.4 теперь содержит следующее предупреждение :

ПРЕДУПРЕЖДЕНИЕ

Несмотря на то, что табличные пространства расположены вне основного каталога данных PostgreSQL, они являются неотъемлемой частью кластера базы данных и не могут рассматриваться как автономный набор файлов данных. Они зависят от метаданных, содержащихся в основном каталоге данных, и поэтому не могут быть присоединены к другому кластеру базы данных или для индивидуального резервного копирования. Точно так же, если вы потеряете табличное пространство (удаление файла, сбой диска и т. Д.), Кластер базы данных может стать нечитаемым или не сможет запуститься. Размещение табличного пространства во временной файловой системе, например на виртуальном диске, ставит под угрозу надежность всего кластера.

потому что я заметил, что слишком много людей делали это и сталкивались с проблемами.

(Если вы это сделали, вы можете mkdirуказать отсутствующий каталог табличного пространства, чтобы снова запустить PostgreSQL, а затем DROPнедостающие базы данных, таблицы и т. Д. Лучше просто не делать этого.)

Или вы можете создать TABLESPACE в ramfs / tempfs и создать там все свои объекты.
Недавно мне указали на статью о том, как делать именно это в Linux .

Предупреждение

Это может поставить под угрозу целостность всего кластера базы данных .
Прочтите добавленное предупреждение в руководстве.
Так что это только вариант для расходных данных.

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

Теперь можно запускать экземпляр PostgreSQL в памяти в ваших тестах JUnit через встроенный компонент PostgreSQL из OpenTable: https://github.com/opentable/otj-pg-embedded .

Добавляя зависимость к встроенной библиотеке otj-pg ( https://mvnrepository.com/artifact/com.opentable.components/otj-pg-embedded ), вы можете запускать и останавливать собственный экземпляр PostgreSQL в ваших @Before и @Afer крючки:

EmbeddedPostgres pg = EmbeddedPostgres.start();

Они даже предлагают правило JUnit для автоматического запуска и остановки JUnit вашего сервера базы данных PostgreSQL:

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

Вы можете использовать TestContainers, чтобы развернуть контейнер докеров PosgreSQL для тестов: http://testcontainers.viewdocs.io/testcontainers-java/usage/database_containers/

TestContainers предоставляет JUnit @ Rule / @ ClassRule : этот режим запускает базу данных внутри контейнера перед вашими тестами и затем разрывает ее.

Пример:

public class SimplePostgreSQLTest {

    @Rule
    public PostgreSQLContainer postgres = new PostgreSQLContainer();

    @Test
    public void testSimple() throws SQLException {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(postgres.getJdbcUrl());
        hikariConfig.setUsername(postgres.getUsername());
        hikariConfig.setPassword(postgres.getPassword());

        HikariDataSource ds = new HikariDataSource(hikariConfig);
        Statement statement = ds.getConnection().createStatement();
        statement.execute("SELECT 1");
        ResultSet resultSet = statement.getResultSet();

        resultSet.next();
        int resultSetInt = resultSet.getInt(1);
        assertEquals("A basic SELECT query succeeds", 1, resultSetInt);
    }
}

Теперь есть версия PostgreSQL в памяти от российской поисковой компании под названием Яндекс: https://github.com/yandex-qatools/postgresql-embedded.

Он основан на процессе встраивания Flapdoodle OSS.

Пример использования (со страницы github):

// starting Postgres
final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6);
// predefined data directory
// final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6, "/path/to/predefined/data/directory");
final String url = postgres.start("localhost", 5432, "dbName", "userName", "password");

// connecting to a running Postgres and feeding up the database
final Connection conn = DriverManager.getConnection(url);
conn.createStatement().execute("CREATE TABLE films (code char(5));");

Я пользуюсь им некоторое время. Это работает хорошо.

ОБНОВЛЕНО : этот проект больше не поддерживается

Please be adviced that the main maintainer of this project has successfuly 
migrated to the use of Test Containers project. This is the best possible 
alternative nowadays.

Вы также можете использовать параметры конфигурации PostgreSQL (например, подробно описанные в вопросе и принятый ответ здесь ) для достижения производительности, не обязательно прибегая к базе данных в памяти.

Если вы используете NodeJS, вы можете использовать pg-mem (отказ от ответственности: я являюсь автором) для имитации наиболее распространенных функций базы данных postgres.

У вас будет полная в памяти, изолированная, независимая от платформы база данных, реплицирующая поведение PG (она даже работает в браузерах ).

Я написал статью , чтобы показать , как использовать его для ваших модульных тестов здесь .