База данных 100 терабайт на PostgreSQL без шардинга

Реально ли настроить базу данных объемом 100 ТБ (на самом деле около 90 ТБ) на PostgreSQL без разделения данных между несколькими узлами? Есть ли истории успеха / примеры подобных установок?

database postgresql

— voidlizard
источник

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

— Фрэнк Фармер

Что ж, профиль нагрузки может быть описан как частые вставки (около 50K в секунду в пике), которые выбираются относительно редко (диапазон строк по пользователю и метка времени). Данные могут быть легко защищены / разделены пользователем и датой / отметкой времени

Ответы:

50 тыс. Записей в секунду, которые нужно поглощать, - это больше, чем просто задача. Даже в синтетических тестах с довольно простыми вставками ограничения PostgreSQL, как правило, составляют максимум около 10 К / с - и там у вас даже нет такого большого зверя с точки зрения размера базы данных.

Кроме того, система ввода-вывода для этого единственного узла PostgreSQL будет интересна, как и для RAID 10, и предполагается, что 50K-вставки будут равны всего лишь 50K-IOPS (что, вероятно, неправильно, но зависит от схемы и индексов вашей базы данных. ) вам понадобится примерно сто дисков в сочетании с очень хорошим массивом, который избавляет вас от покупки нескольких сотен дисков для своевременного обслуживания этих записей.

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

— PFO
источник

Согласен. Это домен системы типов ExaData. Это печально, но получить 50 тыс. IOPS в наши дни с SSD довольно тривиально - да, это будет дорого. Я ожидаю, что здесь будет более 7-значный бюджет для аппаратного обеспечения, включая SAN среднего и высокого уровня.

— TomTom

Да, ExaData - это вариант, если вы хотите использовать «вертикально интегрированный стек решений», что, вероятно, не так уж и плохо с учетом требований.

— PFO

Да. Существуют серьезные преимущества для чего-то подобного: и 100 ТБ, и 50 000 iops на самом деле не кричат "дешево" ´. Что делает Exadata - 1 миллион IOPS при полной загрузке с SSD?

— TomTom

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

— Чоппер3

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

— TomTom

Это реально и будет работать. Производительность во многом зависит от того, сколько у вас оперативной памяти. Чем больше ОЗУ, тем больше кэш, и тем дольше PostgreSQL может кэшировать данные перед выгрузкой на диск.

PostgreSQL будет записывать данные в кеш и время от времени выгружать кеш. Таким образом, 50 тыс. INSERT в секунду не будут переведены в 50 тыс. IOPS. Это будет намного меньше, потому что он будет кластеризовать записи вместе и записывать их все одновременно.

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

Однажды я работал над БД Oracle (Oracle 10g) с 400 ТБ на сервере 16 ГБ, только один экземпляр. Основная нагрузка на базу данных также была основной INSERT, поэтому несколько SELECTs в день и миллионы INSERT каждый день. Производительность была далеко не проблемой.

— ThoriumBR
источник

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

Вам нужны достаточные способы для поглощения нагрузки записи. Это зависит от загрузки записи. Но с достаточно удивительным хранилищем это можно решить. Скорость здесь большая проблема. Точно так же доступ к чтению должен внимательно рассматриваться.
Большинство баз данных не состоят из множества маленьких таблиц, но часто имеют одну или две действительно большие таблицы, которые могут достигать половины размера базы данных. PostgreSQL имеет жесткое ограничение 32 ТБ на таблицу. После этого у типа tid заканчиваются счетчики страниц. Это может быть выполнено с помощью пользовательской сборки PostgreSQL или секционирования таблиц, но это серьезная проблема, которую нужно решить в первую очередь.
PostgreSQL имеет реальные ограничения в объеме оперативной памяти, которую он может использовать для различных задач. Таким образом, наличие большего объема оперативной памяти может помочь, а может и не помочь вам за пределами определенного момента.
Резервные копии .... Резервные копии интересны в этом масштабе. ДБ 60 ТБ, о которых я знаю, должен был использовать резервные копии снимков fs, а затем подделывать резервные копии для бармена для архивации wal. Эти поддельные резервные копии были прокси для резервных копий с помощью моментальных снимков fs. Как я уже сказал: «Это не поддельные резервные копии. Это альтернативные резервные копии!»

Есть люди с базами данных, приближающиеся к этому диапазону. Я встречал по крайней мере одного человека, который работал в банке в Нидерландах, который имел базу данных PostgreSQL объемом 60 ТБ. Однако это действительно, действительно зависит от вашей рабочей нагрузки, и размер сам по себе не является проблемой.

— Крис Траверс
источник