Postgres лучше MySql, когда нужно добавить столбец в таблицу с миллионами строк?

Question

У нас проблемы с Mysql.Когда я ищу вокруг, я вижу много людей, имеющих ту же проблему.

Я присоединился к продукту, в котором в базе данных есть несколько таблиц, содержащих до 150 миллионов строк.Одним из примеров нашей проблемы является то, что в одной из этих таблиц содержится более 30 столбцов, и около половины из них больше не используются.При попытке удалить столбцы или переименовать столбцы, mysql хочет скопировать всю таблицу и переименовать.При таком количестве данных это заняло бы много часов, и сайт почти все время находился в автономном режиме.Это только первая из нескольких крупных миграций для улучшения схемы.Они не предназначены как обычная вещь.Просто большая часть очистки, которую я унаследовал.

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

Answer 1

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

Answer 2

Когда единственный инструмент, который вы знаете, это молоток, все ваши проблемы выглядят как гвоздь. Для этой проблемы PostgreSQL намного лучше справляется с такими изменениями. И дело в том, что неважно, насколько хорошо вы спроектировали свое приложение, вам когда-нибудь придется изменить схему в действующей базе данных. В то время как различные движки MySQL действительно хороши для определенных угловых случаев, здесь ни один из них не помогает. Очень тесная интеграция PostgreSQL между различными уровнями означает, что у вас могут быть такие вещи, как транзакционный ddl, которые позволяют вам откатывать все, что не является изменением / созданием базы данных / табличного пространства. Или очень очень быстро изменить таблицы. Или не препятствуя созданию индексов. И так далее. Он ограничивает PostgreSQL теми вещами, которые он делает хорошо (традиционная обработка транзакционной нагрузки на БД является сильной стороной), и не так хорош в вещах, которые MySQL часто заполняет пробелы, таких как живое сетевое кластерное хранилище с механизмом ndb.

В этом случае ни один из различных движков в MySQL не позволяет вам легко решить эту проблему. Самая универсальность нескольких механизмов хранения означает, что уровень лексера / синтаксического анализатора / верхнего уровня БД не может быть настолько тесно интегрирован с механизмами хранения, и поэтому многие интересные вещи, которые pgsql может здесь делать, mysql не может.

У меня есть таблица 118 Гигабайт в моей базе данных. В нем 1,1 миллиарда строк. Он действительно должен быть разбит на части, но он не читается много, и когда это произойдет, мы можем подождать. При скорости 300 МБ / с (скорость, с которой может считываться массив) чтение занимает приблизительно 118 * ~ 3 секунд, или около 5 минут. Эта машина имеет 32 ГБ ОЗУ, поэтому она не может держать таблицу в памяти.

Когда я запустил простое утверждение для этой таблицы:

изменить таблицу mytable добавить тестовый текст;

оно висело в ожидании вакуума. Я убил вакуум (выберите pg_cancel_backend (12345) (<- pid там), и он сразу же закончился. Вакуум на этом столе занимает много времени между прочим. Обычно это не имеет большого значения, но при внесении изменений в структуру таблицы , ты должен ждать в вакууме или убивать их. </p>

Отбрасывание столбца так же просто и быстро.

Теперь мы подошли к проблеме с postgresql, и это хранилище MVCC в куче. Если вы добавите этот столбец, а затем выполните обновление таблицы set test = 'abc', он обновит каждую строку и точно удвоит размер таблицы. Если HOT не может обновить строки на месте, но тогда вам нужна таблица коэффициента заполнения 50%, которая для начала имеет двойной размер. Единственный способ вернуть пространство назад - это подождать и позволить вакууму восстановить его со временем и повторно использовать по одному обновлению за раз, или запустить кластер или полный вакуум, чтобы уменьшить его.

Вы можете обойти это, запуская обновления по частям таблицы за раз (обновление, где pkid между 1 и 10000000; ...) и запуская вакуум между каждым запуском, чтобы освободить пространство.

Итак, в обеих системах есть бородавки и неровности.

Answer 3

возможно, потому что это не должно быть обычным явлением.

возможно, читая между строк, вам нужно добавить строку в другую таблицу вместо столбцов в большую существующую таблицу ...