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

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

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

  1. player_mail
  2. player_mail_attachments
  3. player_bank
  4. player_inventory
  5. player_effects
  6. player_effects_temp
  7. player_quests
  8. player_quests_tasks
  9. ...

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

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

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

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

редактировать 2:

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


person 133794m3r    schedule 30.08.2011    source источник
comment
Вам не нужно беспокоиться об O-части ORDBMS. Вы можете использовать PostgreSQL как любую реляционную базу данных — действительно, это то, что делает подавляющее большинство развертываний. Затем вы можете также использовать объектно-реляционный материал, если хотите, но это никоим образом не является обязательным.   -  person Magnus Hagander    schedule 30.08.2011
comment
Ах хорошо, это хорошо знать. Мне нравится относительный способ мышления о вещах. Тогда я, вероятно, перейду на Postgres, так как буду в безопасности, зная, что ни одна крупная компания не владеет им, особенно оракулом. Даже с этой вилкой, как в mariadb, я не верю, что они не навредят мне позже.   -  person 133794m3r    schedule 31.08.2011
comment
Я подумал, что должен просто добавить комментарий здесь. После попытки настроить postgres, а затем использовать инструмент PHPPgAdmin, все происходит наоборот. Странно и странно. Нет настройки пользователя в качестве установки, нет информации о том, как это сделать. Мне пришлось гуглить, чтобы получить что-нибудь. MySQL по крайней мере работает логически. Мне нравятся вещи, которые работают с некоторым уровнем смысла. Я хочу использовать Postgres, но все... я имею в виду все... устроено нелогично. Mysql странный, но последовательный. Postgres составлен бессистемно, и я собираюсь придерживаться mariadb и переходить на aria, если понадобится. Не собираюсь использовать Postgres.   -  person 133794m3r    schedule 31.08.2011
comment
Не судите о движке СУБД по инструменту PHPpgAdmin. (Я предпочитаю не использовать инструменты, за исключением, может быть, просмотра) Для серьезной работы с базами данных просто придерживайтесь командной строки и вашего любимого редактора.   -  person wildplasser    schedule 31.08.2011
comment
командная строка. Я тоже сказал командную строку. Я смотрел на инструмент PHPPgAdmin как на крайний случай. Я предпочитаю командную строку для всего, кроме визуализации наборов данных. Это было ужасно. Ничто не было настроено логически, и мне пришлось прыгать через обручи, чтобы настроить это. Я боюсь, что остальная часть моего опыта будет такой же.   -  person 133794m3r    schedule 01.09.2011
comment
Это, очевидно, что-то, что отличается между людьми. Я лично находил MySQL крайне непоследовательным всякий раз, когда мне приходилось с ним работать, и я нахожу PostgreSQL гораздо более логичным и определенно намного более последовательным. Однако это явно не согласуется с тем, что делает MySQL, поэтому кто-то, имеющий опыт работы с MySQL, может быть сбит с толку. Мой опыт показывает, что люди, пришедшие из любой другой базы данных, кроме MySQL, находят это довольно логичным. (Опять же, говоря о PostgreSQL здесь - я не использую phppgadmin, поэтому не могу это комментировать)   -  person Magnus Hagander    schedule 02.09.2011


Ответы (3)


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

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

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

person J0HN    schedule 30.08.2011
comment
+1 для Postgre и связанных с масштабированием, новые облачные инструменты кажутся интересными: enterprisedb .com/solutions/postgres-plus-cloud-computing - person wildpeaks; 30.08.2011
comment
Ну, я не знаю, может, в конечном итоге я остановлюсь на этом, потому что я узнал, как он блокирует, и поэтому я нашел его действительно интересным и, вероятно, поможет с некоторыми вещами. - person 133794m3r; 30.08.2011

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

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

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

person jturmel    schedule 30.08.2011
comment
Обработка внешних ключей (или других ограничений, которые могут быть выражены с помощью SQL) в приложении — очень плохая идея. Если ваши данные важны, у вас будет более одного приложения для доступа к данным. И данные будут жить намного дольше, чем любое из приложений, которые обращаются к ним. Тогда управление правилами целостности очень быстро превращается в кошмар. Я не могу сосчитать раз, когда мне приходилось чистить базу данных, хотя разработчики приложения гарантировали, что все будет сделано правильно. - person a_horse_with_no_name; 30.08.2011
comment
@a_horse_with_no_name Это для игры, которую я пишу, и поэтому она будет обрабатываться этой игрой на каждом сервере. Сами данные в основном будут использоваться только для этого. И поэтому я не понимаю, о чем вы говорите. - person 133794m3r; 30.08.2011
comment
@ 133794m3r: мой комментарий был к заявлению jturmel о том, чтобы перестать полагаться на внешние ключи. Надеяться на приложение, чтобы убедиться, что все ограничения сохраняются, вызывает проблемы. - person a_horse_with_no_name; 30.08.2011
comment
@a_horse_with_no_name, если вы действительно ищете масштабирование, полагаясь на СУРБД для обработки ваших ограничений, быстро станет узким местом, поскольку он упомянул масштабирование, я поднял это. В этот момент вам, вероятно, не следует больше использовать СУБД, но это не цель этой темы. - person jturmel; 31.08.2011
comment
@a_horse_with_no_name а, хорошо. Мне было интересно, о чем вы говорили. jturmel, и да, я знаю, что это будет одна из самых больших вещей, которые мне предстоит сделать в будущем. По той же причине, по которой большинство людей в конечном итоге переходят на NoSQL, когда их вынуждают. Я просто интересовался общим масштабированием. И я не знаю, какой из них я собираюсь отметить как ответивший. Думаю, я выберу ту, что принадлежит Джону, так как там ее немного больше. Я понятия не имею, почему, но я чувствую, что это он, так как я хочу отметить один из них. Я хотел бы отметить оба, но я не могу, и на этот раз этот торт берет верх. - person 133794m3r; 31.08.2011

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

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

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

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

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

person baklarz2048    schedule 30.08.2011
comment
Я уже сделал это, но я присоединяюсь, чтобы получить указанные данные прямо сейчас, и все они делают это в соответствии со своими проектами. Это просто относительно. Это все player_id_* и тому подобное, поэтому у них такие имена. - person 133794m3r; 30.08.2011