Ограничения масштабируемости PostgreSQL и MySQL

Я слышал, что производительность нераспределенной реляционной базы данных, такой как MySQL или PostgreSQL, «ломается» выше 10 ТБ.

Я подозреваю, что существуют ограничения как таковые, поскольку никто не придумал Netezza, Greenplum или Vertica и т. д., однако я хотел бы спросить, есть ли у кого-нибудь здесь ссылка на любой исследовательский документ или формальные тематические исследования, в которых эти ограничения количественно.

38 голосов | спросил Edmon 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 10 Sep 2012 18:14:49 +0400 2012, 18:14:49

1 ответ


46

Нет простого ответа на ваш вопрос, но вот несколько вещей, о которых нужно подумать.

Во-первых, масштаб - это не единственное, о чем можно беспокоиться. Что вы делаете с вашими данными. Если у вас 500 таблиц 30 ТБ данных, и вы делаете простой OLTP с очень небольшим количеством отчетов, я не думаю, что у вас будет слишком много проблем. Там есть базы данных 32TB на PostgreSQL. Тем не менее, в то же время производительность будет несколько ухудшаться, потому что ей нужно нажимать диск на все. Точно так же, если у вас есть 50TB, если данные, но имеют общий набор около 100 ГБ, тогда вы можете построить сервер с достаточным количеством ОЗУ, чтобы сохранить эту часть памяти в памяти, и вы золотые.

С другой стороны, если вы пытаетесь принять режим (наиболее распространенное значение) из 1 ТБ данных, не имеет значения, какая система вы используете, это будет болезненным с или без осколков. (Edit: Sharding может, по сути, сделать эту проблему хуже. )

Основные проблемы, с которыми вы столкнулись с огромными db на MySQL и PostgreSQL, связаны с тем, что ни один из них не поддерживает параллельный параллелизм. Другими словами, запрос выполняется как один блок одним потоком, и его нельзя разбить на части и запустить отдельно. Это чаще всего возникает при запуске больших аналитических запросов по большим объемам данных. Именно здесь Postgres-XC и Green Plum приходят на помощь, поскольку они отделяют хранилище от исполнения и могут делать это на уровне координатора. Обратите внимание, что Postgres-XC и Green Plum по сути используют осколки внутри, но координаторы обеспечивают соблюдение всей согласованности во всем мире.

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

Во-вторых, некоторые системы, такие как Vertica или Greenplum, хранят столбцы информации вместе. Это делает систему более сложной в использовании с точки зрения OLTP и снижает ее производительность, но она значительно повышает производительность при больших аналитических нагрузках. Таким образом, это компромисс, зависящий от рабочей нагрузки.

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

Это, конечно, означает, что пределы обычно не поддаются количественному определению.

Изменить : теперь я работал с базой данных 9 ТБ, которая обрабатывает смешанную поддержку решений и транзакционную обработку в PostgreSQL. Самая большая проблема заключается в том, что если у вас есть вопросы, которые попадают в большие части набора данных, вам придется подождать некоторое время для ответа.

Однако с уделением особого внимания основным принципам (включая индексы, autovacuum, как они работают на низком уровне и т. д.) и достаточным вычислительным ресурсам, они полностью управляемы (и, по моим оценкам, можно хорошо управлять диапазоном 30TB в Pg) .

Edit2 : как только вы перейдете к 100TB, хотя то, что работает, будет зависеть от вашего набора данных. Я сейчас работаю над тем, что не будет масштабироваться в этом диапазоне, потому что он впервые попадет в предел 32 Тбайт на таблицу в PostgreSQL.

ответил Chris Travers 1 +04002012-10-01T07:22:13+04:00312012bEurope/MoscowMon, 01 Oct 2012 07:22:13 +0400 2012, 07:22:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132