Меню

Mysql много таблиц или одна большая



Mysql много таблиц или одна большая

ИМХО, нормализация тут не при чём. Речь идёт о секционировании таблиц. Размер таблицы должен быть таким, чтобы таблицей можно было пользоваться (манипулировать записями, обслуживать, резервировать и пр.) в установленные регламентом сроки. Ну и естественно таблица должна отвечать ограничениям платформы и СУБД.

> а если не отправлять к «мануалам», а просто сказать свое экспертное
> мнение? ведь для этого и существуют форумы.

Говорю тебе своё экспертное мнение:

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

Как делать второе — тебе уже подсказали.

Posted via ActualForum NNTP Server 1.4

> Смысл в том что есть однотипные записи их можно хранить в одной таблице
> или в нескольких, потому что логически записи будут большими группами.
> есть ли смысл эти записи делить на таблицы по этим группам, простой
> пример есть записи допустим по городам, стоит ли делать для каждого
> города отдельную таблицу если для каждого такого города будет по 10 000
> записей. То есть для 10 городов 100 000записай, но вобще городов может
> быть больше 10 например 40 или 50.

Это — уже гораздо более другой вопрос.

Нет, не стоит, если ты не делаешь VLDB. А если ты делаешь VLDB,
то её не стоит делать на MySQL и там уже этого не нужно делать
по другим причинам: там поддерживается партицирование таблиц.

Posted via ActualForum NNTP Server 1.4

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

Но если для поиска использовать индекс, положим BTree, то скорость такого запроса будет очень слабо зависеть от числа записей — хоть 10, хоть 10000000 — скорость уменьшается на 1 при увеличении числа записей в 10 раз. Такой запрос выполняется за доли секунды.

Если использовать хэш, то скорость от числа записей вообще почти не зависит.

было 3 таблицы по 35, 47, и 25 млн записей соответственно. Все на mySQL. выборка по полю дата + id. Таблицы не обновляются, по сути — это архив данных.
Поля для выборки проиндексированны. выборка всегда за конкретный день или период. Разбил все на 30 таблиц примерно по 2-3 млн записей.

И вот сижу смотрю на хостинге графики нагрузки на БД и понимаю, что она стала больше(как мне кажется) хотя я ожидал, что будет меньше. Количество запросов тоже, таблицы меньше, по-моему должно стать меньше. или я чет не понимаю..

Источник

Форум пользователей MySQL

Задавайте вопросы, мы ответим

  • Список
  • Пользователи
  • Правила
  • FAQ (ЧаВо)
  • Поиск
  • Регистрация
  • Зайти

Страниц: 1

  • Список
  • » Оптимизация производительности MySQL
  • » Что лучше, несколько мелких таблиц или одна крупная?

#1 23.12.2009 15:06:46

Что лучше, несколько мелких таблиц или одна крупная?

Здравствуйте уважаемые пользователи форума! Помогите советом. Проектирую базу данных на MySQL, задался простым, но очень важным вопросом — что лучше, одна большая таблица или много маленьких? (с точки зрения дальнейшей обработки и пр.). Допустим есть данные их можно поместить в 1 таблицу 100 000 записей или в 100 по 1000 или в 10 по 10000. Будет стандартная работа с базой: добавление, удаление, несложный поиск в ней.
И еще, скажите пожалуйста сколько записей в таблице в MySQL максимально допустимо?
Спасибо большое, жду ответов от знающих людей.

#2 23.12.2009 15:48:26

Re: Что лучше, несколько мелких таблиц или одна крупная?

Смысл в том что есть однотипные записи их можно хранить в одной таблице или в нескольких, потому что логически записи будут большими группами. есть ли смысл эти записи делить на таблицы по этим группам, простой пример есть записи допустим по городам, стоит ли делать для каждого города отдельную таблицу если для каждого такого города будет по 10 000 записей. То есть для 10 городов 100 000записай, но вобще городов может быть больше 10 например 40 или 50. Более всего важна именно выборка из таблиц, поиск второстепенная задача и не особо важен Или все записи в том числе из разных городов слоить в одну кучу, или раскидать по отдельным таблицам.

#3 23.12.2009 15:55:23

Re: Что лучше, несколько мелких таблиц или одна крупная?

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

Читайте также:  Таблица для родословного дерева

#4 23.12.2009 16:30:36

Re: Что лучше, несколько мелких таблиц или одна крупная?

Города я просто так привел, как бы логически если делить. но смысл не в том. Есть объем данных которому не нужна нормализация и так далее. Добавление новых данных и прочее мы сейчас не рассматриваем. Есть объем данных, положим он не меняется. мне нужно выбирать массивы данных из этого набора. где это бустрее будет происходить из таблицы размерностью 100 000 записаей, или из 10 таблиц размерностью 10 000 записаей.

Важное замечание: выборка всегда только из ОДНОЙ таблицы. Тоесть если я делю на 10 то выбирать мне нужно будет только из одной, мне известной таблицы. А не из нескольких. По сути вопрос сводитьс к тому откуда будет выборка быстрее из большой или из мальнекой таблицы. Ответ очевиден, из маленькой, но мне важна именно разница скоростей, на сколько она будет существенна, или наоборот принебрежительно мала. Интересует именно если таблица будет довольно таки большой в 300 000 тыщ записей.

#5 23.12.2009 20:58:09

Re: Что лучше, несколько мелких таблиц или одна крупная?

Скорость выборки не зависит от количества строк в таблице; скорость добавления
новых строк зависит от количества строк уже в таблице (пустые таблицы заполняются
быстрее). Почитайте про PARTITIONING, возможно, Вам стоит остановиться на одной
таблице, а потом, если понадобится, побить ее на кусочки.

Источник

одна большая или много маленьких таблиц?

Avdoshyn

Новичок

одна большая или много маленьких таблиц?

Может кто подскажет — что лучше и оптимальнее для mysql: несколько маленьких таблиц или одна большая.

Большая — это например 20000 записей по 20-30 кб запись

chira

Новичок

20000 — это маленькая таблица!
Если ты хочешь продолжить тему о news_2002, news_2003, то как вариант «размножения» однаковых таблиц (с одинаковой структурой) можешь попробовать схему:
table1 — актуальные новости
table2 — архивные новости

но если для тебя таблица с 20000 записями — большая, то все держи в одной теблице как тебе уже советовали.

Avdoshyn

Новичок

да спасибо, совет действительно по теме — я имею ввиду про актуальные новости.

а почему если таблица с 20000 записями большая — то хранить лучше в одной?

Скажем если человек читает конкретную новость, то разве скорость доступа не будет больша если эта новость будет не в таблице с 20000 записями а в таблице с 500 записями?

Автор оригинала: chira
20000 — это маленькая таблица!
Если ты хочешь продолжить тему о news_2002, news_2003, то как вариант «размножения» однаковых таблиц (с одинаковой структурой) можешь попробовать схему:
table1 — актуальные новости
table2 — архивные новости

но если для тебя таблица с 20000 записями — большая, то все держи в одной теблице как тебе уже советовали.

Источник

Что лучше, несколько мелких таблиц или одна крупная?

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

Одна или несколько таблиц?
Всем доброго времени суток. Подскажите как поступить в таком случае: нужно автоматически.

Что лучше: две подобные таблицы или одна с дополнительным уточняющим столбцом?
В случае одной таблицы с дополнительным уточняющим столбцом этот столбец будет заполняться.

Один большой или несколько мелких, что лучше?
Добрый день. Решил прикупить себе новый жесткий диск на 2 Тб. И встал вопрос. Как лучше поступить.

Что лучше одна большая планка ОЗУ или несколько маленьких?
Есть три слота, одна планка на 1гб, две другие по 512 mb. Хочу поставить 3 гб, что лучше — три.

Смысл в том что есть однотипные записи их можно хранить в одной таблице или в нескольких, потому что логически записи будут большими группами. есть ли смысл эти записи делить на таблицы по этим группам, простой пример есть записи допустим по городам, стоит ли делать для каждого города отдельную таблицу если для каждого такого города будет по 10 000 записей. То есть для 10 городов 100 000записай, но вобще городов может быть больше 10 например 40 или 50. Более всего важна именно выборка из таблиц, поиск второстепенная задача и не особо важен Или все записи в том числе из разных городов слоить в одну кучу, или раскидать по отдельным таблицам.

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

Города я просто так привел, как бы логически если делить. но смысл не в том. Есть объем данных которому не нужна нормализация и так далее. Добавление новых данных и прочее мы сейчас не рассматриваем. Есть объем данных, положим он не меняется. мне нужно выбирать массивы данных из этого набора. где это бустрее будет происходить из таблицы размерностью 100 000 записаей, или из 10 таблиц размерностью 10 000 записаей.

Читайте также:  Формы изменения частей речи таблица

Важное замечание: выборка всегда только из ОДНОЙ таблицы. Тоесть если я делю на 10 то выбирать мне нужно будет только из одной, мне известной таблицы. А не из нескольких. По сути вопрос сводитьс к тому откуда будет выборка быстрее из большой или из мальнекой таблицы. Ответ очевиден, из маленькой, но мне важна именно разница скоростей, на сколько она будет существенна, или наоборот принебрежительно мала. Интересует именно если таблица будет довольно таки большой в 300 000 тыщ записей.

Источник

Что более эффективно: несколько таблиц MySQL или одна большая таблица?

Я храню различные данные пользователя в моей базе данных MySQL. Первоначально он был настроен в разных таблицах, что означает, что данные связаны с UserIds и выводятся с помощью иногда сложных вызовов для отображения и управления данными по мере необходимости. Создавая новую систему, почти разумно объединить все эти таблицы в одну большую таблицу связанного контента.

  • Это будет помощь или препятствие?
  • Вопросы скорости при вызове, обновлении или поиске/манипулировании?

Вот пример некоторых из моих табличных структур:

  • пользователи – UserId, имя пользователя, адрес электронной почты, зашифрованный пароль, дата регистрации, ip
  • user_details – данные cookie, имя, адрес, контактные данные, принадлежность, демографические данные
  • user_activity – вклад, последний онлайн, последний просмотр
  • user_settings – параметры отображения профиля
  • user_interests – рекламные целевые переменные
  • user_levels – права доступа
  • user_stats – hits, tallies

Изменить: Я до сих пор поддерживал все ответы, все они имеют элементы, которые по существу отвечают на мой вопрос.

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

Будут ли проблемы, если таблица охватывает более 100 столбцов, если большая часть этих ячеек, вероятно, останется пустой?

Несколько таблиц помогают в следующих случаях/случаях:

(a) если разные люди будут разрабатывать приложения, содержащие разные таблицы, имеет смысл разделить их.

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

(c) Для перемещения данных в разные места, особенно во время разработки, может иметь смысл использовать таблицы, что приводит к меньшим размерам файлов.

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

(e) Это возможность: то, что вы считали единичными данными, может оказаться в конечном счете множеством ценностей. например Кредитный лимит – это одно значение поля на данный момент. Но завтра вы можете изменить значения как (дата от, дата до, значение кредита). Сплит-таблицы теперь могут пригодиться.

Мое голосование будет за несколько таблиц – с соответствующими данными.

Объединение таблиц называется денормализацией.

Он может (или не может) помогать делать некоторые запросы (которые заставляют много JOIN s) работать быстрее за счет создания аддона поддержки.

MySQL способен использовать только метод JOIN , а именно NESTED LOOPS .

Это означает, что для каждой записи таблицы вождения MySQL находит соответствующую запись в ведомой таблице в цикле.

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

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

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

Поддержка ада, с другой стороны, гарантируется.

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

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

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

Читайте также:  Ms sql связи между таблицами просмотр

У все этих таблиц есть отношение 1-to-1 ? Например, будет ли каждая строка пользователя иметь одну соответствующую строку в user_stats или user_levels ? Если это так, то может иметь смысл объединить их в одну таблицу. Если отношение не 1 to 1 , хотя, вероятно, было бы нецелесообразно объединять (денормализовать) их.

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

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

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

Создание одной массивной таблицы идет вразрез с принципами реляционных баз данных. Я бы не объединил их всех в один стол. Вы получите несколько экземпляров повторяющихся данных. Например, если у вашего пользователя три интереса, у вас будет 3 строки с теми же данными пользователя, что и для хранения трех разных интересов. Определенно переходим к множественному “нормализованному” подходу к таблице. См. this Страница Wiki для нормализации базы данных.

Edit:
Я обновил свой ответ, так как вы обновили свой вопрос… Я согласен с моим первоначальным ответом еще больше, потому что…

большая часть этих клеток вероятно, останется пустым

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

Я работал в телефонной компании, где было много таблиц, для получения данных может потребоваться много соединений. Когда производительность чтения из этих таблиц была критической, тогда создаваемые процедуры, которые могли бы генерировать плоскую таблицу (т.е. Денормализованную таблицу), которая не требовала бы соединений, вычислений и т.д., На которые могли указывать отчеты. Они затем используются вместе с агентом SQL-сервера для выполнения задания через определенные промежутки времени (например, недельный просмотр некоторых статистических данных будет выполняться один раз в неделю и т.д.).

Почему бы не использовать тот же подход, который WordPress делает с помощью таблицы пользователей с базовыми данными пользователя, которые есть у каждого, а затем добавляет таблицу “user_meta”, которая может быть в основном любой парой ключей, значений, связанной с идентификатором пользователя. Поэтому, если вам нужно найти всю метаинформацию для пользователя, вы можете просто добавить это к вашему запросу. Вам также не обязательно добавлять дополнительный запрос, если он не нужен для таких вещей, как вход в систему. Преимущество этого подхода также оставляет вашу таблицу открытой для добавления новых функций для ваших пользователей, таких как хранение их твиттера или каждого отдельного интереса. Вам также не придется иметь дело с лабиринтом связанного идентификатора, потому что у вас есть одна таблица, которая управляет всеми метаданными, и вы ограничиваете ее только одной ассоциацией, а не 50.

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

Я думаю, что это одна из тех ситуаций, которые зависят от этого. Наличие нескольких таблиц чище и, вероятно, теоретически лучше. Но когда вам нужно присоединиться к 6-7 таблицам, чтобы получить информацию об одном пользователе, вы можете начать переосмысливать этот подход.

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

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

Мне кажется, что вы можете пропустить User_Details, поскольку это, вероятно, отношение 1 к 1 с пользователями.
Но остальное, вероятно, много строк на пользователя?

Источник

Adblock
detector