Реально ли установить базу данных 100 ТБ (фактически около 90 ТБ) на PostgreSQL без сегментирование данных между несколькими узлами? Есть ли какие-нибудь истории успеха / примеры подобных установок?
50 Кбайт записи в секунду, которые необходимо усвоить, - это обычно более чем проблема. Даже в синтетических тестах с довольно простыми вставками ограничения PostgreSQL, как правило, достигают максимума примерно в 10 Кб / с - и там у вас даже нет такого большого зверя с точки зрения размера базы данных.
Также будет интересна система ввода-вывода для этого единственного узла PostgreSQL, так как даже с RAID 10 и при условии, что вставки 50K будут равны всего 50K IOPS (что, вероятно, неверно, но это зависит от схемы вашей базы данных и индексов. ) вам понадобится примерно сотня дисков в паре с очень хорошим массивом, который избавит вас от покупки нескольких сотен дисков для своевременного обслуживания этих операций записи.
Если сегментирование выполняется легко и вы ожидаете такой большой нагрузки на запись, переходите к сегментированию. Записи могут быть очень сложными для масштабирования.
Это реально и будет работать. Производительность в большей степени зависит от того, сколько у вас оперативной памяти. Чем больше ОЗУ, тем больше кеш и тем дольше PostgreSQL может кэшировать данные перед выгрузкой на диск.
PostgreSQL будет записывать данные в кеш и время от времени выгружать кеш. Таким образом, 50 000 INSERT в секунду не будут преобразованы в 50 000 IOPS. Это будет намного меньше, потому что он будет кластеризовать записи вместе и записывать их все одновременно.
База данных такого размера не проблема, если большая часть работы - это ВСТАВКА. PostgreSQL придется менять индексы здесь и там, но это действительно простая работа. Если бы у вас было много SELECT в базе данных такого размера, вам действительно нужно было бы сегментировать.
Однажды я работал над Oracle DB (Oracle 10g) с 400 ТБ на сервере 16 ГБ, только один экземпляр. Рабочей нагрузкой базы данных также были операции INSERT, поэтому несколько операций SELECT в день и миллионы операций INSERT каждый день. Производительность вовсе не была проблемой.
На 100 ТБ у вас есть несколько важных задач. Будет ли это работать для вас или нет, зависит от того, как вы хотите решить эти проблемы.
Вам нужно достаточное количество способов выдержать нагрузку записи. Это зависит от нагрузки записи. Но с достаточно классным хранилищем это решаемо. Скорость здесь большая проблема. Точно так же необходимо внимательно изучить доступ для чтения.
Большинство баз данных не состоят из множества небольших таблиц, но часто имеют одну или две действительно большие, которые могут составлять до половины размера базы данных. PostgreSQL имеет жесткое ограничение в 32 ТБ на таблицу. После этого у типа tid заканчиваются счетчики страниц. Это можно решить с помощью специальной сборки PostgreSQL или разделения таблицы, но это серьезная проблема, которую необходимо решить в первую очередь.
PostgreSQL имеет реальные ограничения на объем оперативной памяти, который он может использовать для различных задач. Таким образом, наличие большего количества оперативной памяти может помочь или не помочь вам после определенного момента.
Резервные копии .... Резервные копии интересны в этом масштабе. БД объемом 60 ТБ, который я знаю, должен был использовать резервные копии моментальных снимков fs, а затем подделывать резервные копии для barman для архивирования wal. Эти поддельные резервные копии были прокси для резервных копий снимков файловой системы. Как я уже сказал: «Это не поддельные резервные копии. Это альтернативные резервные копии!»
Есть люди с базами данных, приближающимися к этому диапазону. Я встречал по крайней мере одного человека, который работал в банке в Нидерландах, у которого была база данных PostgreSQL на 60 ТБ. Однако это действительно зависит от вашей рабочей нагрузки, и сам по себе размер не является проблемой.