Насколько быстрее работает база данных в оперативной памяти?

Question

Я хочу запустить PostgreSQL в оперативной памяти для повышения производительности. База данных не превышает 1 ГБ и не должна увеличиваться до 5 ГБ. Стоит ли это делать?

Моя вторая главная проблема: насколько легко создавать резервные копии, когда она работает исключительно в оперативной памяти. Это похоже на использование ОЗУ в качестве HD 1-го уровня или это намного сложнее?

Answer 1

Это может стоить, если ваша база данных связана с вводом / выводом. Если он привязан к процессору, ОЗУ не будет иметь значения.

Но обо всем по порядку, вы должны убедиться, что ваша база данных настроена правильно, вы можете получить огромный прирост производительности, не теряя при этом никаких гарантий. Даже база данных на основе ОЗУ будет работать плохо, если она не настроена должным образом. См. PostgreSQL wiki на этом , в основном shared_buffers ,ffective_cache_size, checkpoint_ *, default_statistics_target

Во-вторых, если вы хотите избежать синхронизации дисковых буферов при каждом коммите (как кодека объяснила в своем комментарии), отключите опцию конфигурации synchronous_commit. Когда ваша машина теряет мощность, это приведет к потере некоторых последних транзакций, но ваша база данных будет на 100% согласованной. В этом режиме ОЗУ будет использоваться для буферизации всех записей, включая записи в журнал транзакций. Так что с очень редкими контрольными точками, большими shared_buffers и wal_buffers, он может фактически приближаться к скоростям, близким к скорости RAM-диска.

Также аппаратные средства могут иметь огромное значение. Диски со скоростью 15000 об / мин на практике могут быть в 3 раза быстрее, чем дешевые диски для рабочих нагрузок базы данных. RAID-контроллеры с кэш-памятью с батарейным питанием также имеют большое значение.

Если этого все еще недостаточно, , тогда может иметь смысл рассмотреть возможность обращения к энергозависимому хранилищу.

Answer 2

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

Лично я не стал бы беспокоиться об этой оптимизации, пока не столкнулся с проблемами производительности. Мне это просто кажется рискованным.

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

С точки зрения производительности кластеризация по сети на другую СУБД, которая выполняет всю запись на диск, кажется гораздо более неэффективной, чем просто наличие обычной СУБД и ее настройка для максимально возможного хранения в оперативной памяти. .

Answer 3

от 5 до 40 раз быстрее, чем дисковые СУБД. Ознакомьтесь с магическим квадрантом Gartner для операционных СУБД 2013. Gartner показывает, кто силен и, что более важно, отмечает серьезные предостережения ... ошибки. .errors ... недостаточная поддержка и трудные в использовании поставщики.

Answer 4

На самом деле ... пока у вас достаточно памяти, ваша база данных уже будет полностью запущена в ОЗУ. Ваша файловая система полностью буферизует все данные, поэтому это не будет иметь большого значения.

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

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