MySQL: Многие таблицы или многие базы данных?

Question

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

• Создание новой базы данных для каждого бассейна (около 15-25 столов)
• Создание всех таблиц в одной базе и отличаются бассейны именами таблиц.

Какой из них проще и быстрее обрабатывать MySQL?

EDIT: Я не интересуюсь вопросами проектирования баз данных, я просто заинтересован в том, какая из двух возможностей выполняется быстрее.

EDIT 2: Я постараюсь сделать это более понятным. Как сказано, у нас будут данные, где часть даты редко принадлежит вместе в разных пулах. Сопоставив все данные одного типа в одной таблице, и связывая его с бассейном ID не является хорошей идея:

• Трудно резервного копирование/удаление определенного пула (и мы ожидаем, что мы бежим из первичных ключей через некоторое время (даже при использовании большого int)

Итак, идея состоит в том, чтобы создать базу данных для каждого пула или создать множество таблиц в одной базе данных. 50% запросов к базе данных будут простыми inserts. 49% будут простыми selects на первичном ключе.

Вопрос в том, что быстрее обрабатывать для MySQL? Многие таблицы или многие базы данных?

Answer 1

Не должно быть существенной разницы в производительности между несколькими таблицами в одной базе данных и несколькими таблицами в разных базах данных.

В MySQL базы данных (стандартный SQL использует термин «схема» для этого) служат главным образом как пространство имен для таблиц. База данных имеет только несколько атрибутов, например. набор символов по умолчанию и сортировка. И это использование GRANT позволяет управлять правами доступа к каждой базе данных, но это не имеет ничего общего с производительностью.

Вы можете получить доступ к таблицам в любой базе данных из одного соединения (при условии, что они управляются одним и тем же экземпляром MySQL Server). Вам просто нужно определить название таблицы:

SELECT * FROM database17.accounts_table; 

Это чисто синтаксическое различие. Он не должен влиять на производительность.

Что касается хранения, вы не можете организовать таблицы в файл-за-базу данных, как это делает @Chris. При использовании механизма хранения MyISAM у вас всегда есть файл для каждой таблицы. С движком хранения InnoDB у вас либо есть один набор файлов хранилища, которые объединяют все таблицы, либо у вас есть файл для таблицы (он настроен для всего сервера MySQL, а не для каждой базы данных). В любом случае нет никакого преимущества или недостатка производительности для создания таблиц в одной базе данных по сравнению со многими базами данных.

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

Что касается резервных копий, вы можете указать подмножество таблиц в качестве аргументов команды mysqldump. Может оказаться более удобным резервное копирование логических наборов таблиц на базу данных, без необходимости указывать все таблицы в командной строке. Но это не должно иметь никакого значения для производительности, только удобство для вас при вводе команды резервного копирования.

Answer 2

Почему бы не создать отдельную таблицу для отслеживания ваших пулов (с идентификаторами PoolID и PoolName в виде столбцов и всего, что вы хотите отслеживать), а затем на ваших 15-25 таблицах вы бы добавили столбец на всех которые будут внешним ключом к вам в бильярдный стол, чтобы вы знали, к какому пулу принадлежит эта конкретная запись.

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

Answer 3

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

Таким образом, вы ограничиваете разницу между доступом различных пулов к исходной инструкции «use database», вам не придется каждый раз перекодировать ваши SELECT или иметь динамический sql.

Другие преимущества этого подхода являются:

• Простое резервное копирование/восстановление
• Легкий старт/остановка экземпляра базы данных.

Недостатки:

• немного больше админ работы, но не так много.

Я не знаю, что ваше приложение, но на самом деле действительно тщательно подумайте, прежде чем создавать все таблицы в одной базе данных. Таким образом безумие.

Редактировать: Если производительность - это единственное, что касается вас, вам необходимо ее измерить. Возьмите представительный набор запросов и оцените их производительность.

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

Мой (наш? - не может говорить для кого-либо еще) указывает на то, что для хорошо настроенных баз данных практически не будет различий в производительности между тремя параметрами (poolid в таблице, несколькими таблицами, несколькими базы данных), поэтому вы можете выбрать наиболее удобный для вас вариант в краткосрочной и долгосрочной перспективе.

Для меня лучшим вариантом является по-прежнему одна база данных с poolId, как предложила TheTXI, а затем несколько баз данных, в зависимости от ваших потребностей (в основном администрирования). Если вам нужно точно знать, какая разница в производительности между двумя вариантами, мы не можем дать вам этот ответ. Вам нужно настроить его и проверить.

В нескольких базах данных для повышения производительности становится проще использовать оборудование.

Answer 4

Я не уверен, что полностью понимаю ваш сценарий. Вы хотите, чтобы все пулы использовали одни и те же таблицы, но просто отличались отличительным ключом? Или вам нужны отдельные пулы таблиц в одной базе данных с суффиксом в каждой таблице, чтобы отличать пулы?

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

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

Кроме того, безопасность доступа к серверу базы данных может быть более плотно заблокирована.

Все эти вещи могут быть выполнены без использования отдельных баз данных, но разделение сделает все это проще и уменьшит сложность умственного отслеживания тех таблиц, на которых вы хотите работать.

Answer 5

Я не очень хорошо знаю mysql, но я думаю, что мне придется дать стандартный ответ производительности - «Это зависит».

Некоторые мысли (касающиеся только производительность/обслуживания, а не проектирования баз данных):

• Создание новой базы данных означает отдельный файл (или файлы) в файловой системе. Эти файлы можно было бы поместить в разные файловые системы, если производительность одного должна быть отделена от других и т. Д.
• Новая база данных, вероятно, будет обрабатывать кэширование по-разному; например. Все таблицы в одной БД означают общий кэш для БД, тогда как разделение таблиц на отдельные базы данных означает, что каждая база данных может иметь отдельный кеш [очевидно, что все базы данных будут использовать одну и ту же физическую память для кеша, но может быть предел на базу данных и т. д.].
• Относительно отдельных файлов это означает, что если один из ваших наборов данных становится более важным, чем другие, его можно легко отнести на новый сервер.
• Разделение баз данных дает дополнительное преимущество, позволяя вам быстрее развертывать обновления по сравнению с единой базой данных.

Однако, для сравнения, наличие нескольких баз данных означает, что сервер, вероятно, будет использовать больше памяти (поскольку он имеет несколько кешей). Я уверен, что существует много «минусов» для подхода с несколькими базами данных, но сейчас я рисую пробел.

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

Answer 6

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

Answer 7

FTR, в нормальных условиях Я бы взял подход, описанный TheTXI.

В ответ на ваш конкретный вопрос, однако, я нашел, что это зависит от использования. (Копай, я знаю, но выслушай меня.)

Единственная база данных, вероятно, проще. Вам нужно будет беспокоиться только по одному соединению и все равно придется указывать таблицы. Однако при определенных условиях несколько баз данных могут быть быстрее.

Если бы я был вами, я бы попробовал оба. Мы не сможем дать вам полезный ответ.

Answer 8

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

Как уже упоминалось, отдельные базы данных позволят вам перемещать вещи и создавать оптимизацию, специфичную для определенного пула (т. Е. Сжатых таблиц). Это лишний админ, но есть гораздо большая гибкость.

Кроме того, вы всегда можете «объединять» таблицы, которые находятся в разных базах данных, используя таблицы объединения или объединения, чтобы упростить запрос, если это необходимо.

Что касается истечения первичных ключей, вы всегда можете использовать составной первичный ключ, если используете таблицы MyISAM. Например, если у вас есть поле с именем groupCode (любой тип) и другое с именем sequenceId (auto increment) и создайте свой первичный ключ как groupCode + sequenceId. Последовательность будет увеличиваться на основе следующего уникального идентификатора в наборе групповых кодов. Например: AAA 1 AAA 2 BBB 1 AAA 3 CCC 1 AAA BBB 2 ...

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

Answer 9

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

Здесь есть действительно важный общий принцип: Не думайте о том, как быстро это будет, профайл.