Postgresql против MySQL в простоте масштабирования и полезности для высокореляционных (тонны внешних ключей) баз данных

Question

Хорошо, я прочитал довольно много вещей о PostgresSQL, и у него, похоже, есть несколько функций, которые кажутся довольно удивительными, мне очень нравится идея иметь возможность обновлять таблицу и добавлять столбец / индекс без необходимости ждать для базы данных и его заблокировали. Также, похоже, он работает примерно так же быстро, как MySQL, когда дело доходит до производительности. Но меня больше всего беспокоит легкость его масштабирования так же, как и моей системы.

Сейчас у меня есть таблицы, у которых все есть внешние ключи и для простоты использования они связаны друг с другом, и я использую внешние ключи много . Например, у меня есть таблица «игроки», в которой много таблиц, которые связаны с ней. У меня есть следующие таблицы:

1. players_mail
2. players_mail_attachments
3. players_bank
4. players_inventory
5. players_effects
6. players_effects_temp
7. players_quests
8. players_quests_tasks
9. ...

и список продолжается. У меня есть несколько других таблиц, и все они используют идентификатор таблицы игроков в качестве одного из своих индексов и относятся к столбцу player.id. Также у почты один внешний ключ к почте, а другие также как реляционные. Хорошо ли масштабируется PostgreSQL с этой реляционной базой данных? У меня также есть несколько индексов на большинстве таблиц. У всех таблиц, которые не являются «корневыми» таблицами (как у игроков), есть два индекса первичного ключа, а затем также индексы для внешних ключей.

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

Изменить, чтобы добавить:

Я в первую очередь смотрю на это, потому что он обрабатывает блокировку во время записи, а также потому, что я не знаю, что я чувствую к оракулу, и как полагаюсь на xtradb в качестве формата базы данных. Хотя я знаю, что MariaDB работает над собственным форматом базы данных, мне все еще не нравится, что мой любимый формат базы данных находится под контролем компании, которая может просто убить ее или, что еще хуже, сделать ее полностью закрытым источником. После того, как я пройду через postgresql и посмотрю, как я могу легко перенести в него свои базы данных, и найду инструменты для него, я выберу, какой ответ был наилучшим, я также оставлю его открытым на 24 часа, чтобы люди могли вносить изменения в любое они хотят.

изменить 2:

Я только что наконец-то действительно начал смотреть на сам формат базы данных, и хотя мне действительно нравятся некоторые вещи, которые я не выношу объектной ориентации, это сводит меня с ума. Я был полностью готов перейти к postgres, пока не понял, что он смоделирован после половины ориентации объекта. Думаю, один из моих последних вопросов - не заставляет ли я правильно использовать классы и объекты? Википедия говорит, что это «мост» между ООП и RDMB, поэтому я понимаю, что все равно могу делать все так, как мне нравится. Если это так, то я, скорее всего, полюблю базу данных, если не смогу, то возненавижу. И я бы предпочел не ненавидеть инструмент, который так важен для успеха этой вещи.

Answer 1

300 таблиц с множеством внешних ключей и индексов, около 150 таблиц с более чем 1000 записей, около 20 таблиц с более чем 100000 записей - это достаточно много для вас?

Никогда не сталкивался с проблемами производительности, вызванными самим PostgreSQl. Чудовищные 400+ строк запросов с примерно 15 подвыборками выполняются за секунду.

Подводя итог: PostgreSQL очень хорошо масштабируется. Конечно, не подходит для Oracle, но он выполняет свою работу. Единственный совет: если вы ОЧЕНЬ обеспокоены производительностью - замените триггеры на правила и по возможности используйте представления вместо хранимых процедур

Answer 2

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

Что касается масштабирования MySQL против Postgres, вы, в основном, столкнетесь с одними и теми же препятствиями, поскольку они действительно быстрые и стабильные СУБД.

Все это говорит о том, что Postgres гораздо более совместим с ACID, чем MySQL, он обрабатывает FK точно так же, как вам нужно, и я обычно рекомендую его на основе того, что вы выразили в своем посте.

Answer 3

Неважно, что вы используете.Все зависит от приложения и архитектуры.Например, внешние ключи не сильно повредят, если вы сделаете небольшую избыточность.пример:

players(id, ....)
players_quests(id, player_id, ....)
players_quests_tasks(id,player_quest_id, ...)

Чтобы найти Players_quests_tasks принадлежит какому-либо игроку, вам нужно присоединиться.Решение: добавьте player_id в таблицу Players_quests_tasks.Это нормализация разрыва, но нет соединения:

players_quests_tasks(id,player_quest_id, player_id,...)
SELECT * FROM players_quests_tasks WHERE player_id=:player_id_to_find;

Это имеет смысл, если у вас гораздо больше операций чтения, чем записи.