Я слышал, что производительность неосколенной реляционной базы данных, такой как MySQL или PostgreSQL, «ломается» за пределы 10 ТБ.
Я подозреваю, что лимиты как таковые существуют, так как никто не придумал бы Netezza, Greenplum или Vertica и т. Д., Однако я хотел бы спросить, есть ли у кого-нибудь здесь ссылка на какой-либо исследовательский документ или формальные тематические исследования, где эти лимиты количественно определены.
Ответы:
Там нет простого ответа на ваш вопрос, но вот несколько вещей для размышления.
Во-первых, масштаб - это не единственное, о чем нужно беспокоиться. Что вы делаете с вашими данными. Если у вас 500 таблиц по 30 ТБ данных, и вы делаете простой OLTP с очень небольшим количеством отчетов, я не думаю, что у вас будет слишком много проблем. На PostgreSQL есть базы данных по 32 ТБ. Тем не менее, в то же время производительность будет несколько ухудшаться, потому что он должен ударить диск по всему. Точно так же, если у вас есть 50 ТБ данных, но обычно используется набор размером около 100 ГБ, то вы можете построить сервер с достаточным количеством оперативной памяти, чтобы сохранить эту часть базы данных в памяти, и вы - прекрасное решение.
С другой стороны, если вы пытаетесь извлечь режим (наиболее распространенное значение) из 1 ТБ данных, не имеет значения, какую систему вы используете, это будет болезненно с шардингом или без него. (Edit: Sharding может, на самом деле, усугубить эту проблему . )
Основные проблемы, с которыми вы столкнетесь при работе с огромными базами данных в MySQL и PostgreSQL, связаны с тем, что ни один из них не поддерживает внутризапросный параллелизм. Другими словами, запрос выполняется как один блок одним потоком, и его нельзя разбить на части и выполнить отдельно. Это чаще всего проблема при выполнении больших аналитических запросов на больших объемах данных. Именно здесь Postgres-XC и Green Plum приходят на помощь, поскольку они отделяют хранилище от выполнения и могут делать это на уровне координатора. Обратите внимание, что Postgres-XC и Green Plum по существу используют шардинг внутри, но координаторы обеспечивают глобальную согласованность.
С помощью параллелизма внутри запросов вы можете разбить запрос, сделать так, чтобы разные процессоры / каналы ввода-вывода диска выполняли его части, и сообщать о частях набора результатов, которые нужно собрать и передать обратно приложению. Опять же, это обычно наиболее полезно в аналитических, а не нагрузках обработки транзакций.
Во-вторых, некоторые системы, такие как Vertica или Greenplum, хранят вместе столбцы информации. Это усложняет использование системы с точки зрения OLTP и снижает производительность, но резко повышает производительность для больших аналитических рабочих нагрузок. Так что это компромисс для конкретной нагрузки.
Таким образом, ответ заключается в том, что, как только вы получите больше 1-2 ТБ, вы можете столкнуться с рядом компромиссов между системами и рабочими нагрузками. Опять же, это относится к базам данных, размеру рабочих наборов и т. Д. Однако на этом этапе вам действительно нужно использовать системы снежинок, то есть системы, уникальные и адаптированные к вашей рабочей нагрузке.
Это, конечно, означает, что пределы, как правило, не поддаются количественной оценке.
Изменить : Теперь я работал с базой данных 9 ТБ, которая обрабатывает смесь поддержки принятия решений и обработки транзакций в PostgreSQL. Самая большая проблема заключается в том, что если у вас есть вопросы, которые затрагивают большие части набора данных, вам придется подождать некоторое время для ответа.
Однако, при тщательном внимании к основам (включая индексы, автовакуум, как они работают на низком уровне и т. Д.) И достаточным вычислительным ресурсам, они полностью управляемы (и я полагаю, что это вполне подойдет для диапазона 30 ТБ в Pg).
Edit2 : как только вы перейдете к 100TB, то, что работает, будет зависеть от вашего набора данных. Сейчас я работаю над одним из них, который не будет масштабироваться в этом диапазоне, потому что сначала он достигнет предела 32 ТБ на таблицу в PostgreSQL.