|
Задавайте вопросы, мы ответим
Вы не зашли.
Что будет работать быстрее, partitioning или несколько таблиц? В моем случае я разбил таблицу на 4 штуки по определенному параметру, параметр числовой, сейчас он можт принимать значения от 1 до 4. Я разбил таблицу на 4 отдельных таблицы. Делаю из них выборки по ID, он не пересекается (первоначально все данные льются в одну большую таблицу, потом разносятся процедурой на 4 в соответствии с указанным признаком). Все бы ничего но мне пришлось перерабатывать приложение и если появится еще одна такая таблица, т.е. количество признаков увеличится, не важно на сколько, это потребует дорабатывать приложение, чего делать конечно не хочется.
Запросы у меня сейчас выглядят примерно так:
(select * from table1 where id in (1,2,4))
union all
(select * from table1 where id in (5,8,9))
union all
...
конечно если мне нужно вывсти записи которые находятся в одной таблице то union не делаю, выяснить в какие таблицы входят затребованные записи я могу, есть спец. поле.
И вот повторю свой вопрос: что лучше, делать union или добавить partitioning в одну большую таблицу?
При использовании отдельных таблиц плюс. что их можно сделать federation и разнести на разные сервера, при партициях тут кажется только на разные винты в пределах одного сервера Но минус использования отдельных таблиц в сущестенной доработке системы при добавлении дополнительной таблиц(ы).
Спасибо.
Неактивен
Как Вы правильно заметили, partitioning является несколько другим взглядом на разбиение
таблиц вручную. С точки зрения сервера это разные таблицы - так, как если бы Вы их разбили
руками. Как следствие - никакого прироста в скорости Вы не выиграете ни в одном из случаев.
Что касается federated - способы обработки этих таблиц сейчас находятся в таком состоянии, что
нельзя говорить об увеличении производительности при переходе на federated. Более того, в
большинстве случаев это будет уменьшением производительности.
Переписывать приложение под различные разбиения, разумеется, неблагодарная работа - куда
лучше, когда за Вас это делает сервер. Другое дело, что в стабильной ветке MySQL он это не делает 
Неактивен
Я наверное нправильно выразился, federated я привел как один из плюсов в сторону использования отдельных таблиц против partitioning.
По поводу прироста в скорости: Вы хотите сказть, что хоть я использую одну большую таблицу, хоть одну большую с разбиением на партиции хоть : отдельных разницы в производительности не будет? Не верится что то, ведь 4 отдельные таблицы должны, при условии что используются не все 4 в раз, работать быстре чм одна большая без партиций. Вот меня и интересует что будет быстрее - несколько маленьких или одна большая с партициями или одна большая без партици (одно из трех)? И что значит стабильная ветка этого не делает? там нет partitioning?
Неактивен
В 5.0 partitioning нет. Совсем не разбитая таблица будет работать на добавление и изменение записей
медленнее разбитой (хотя, заметно это становится при достаточно больших объемах данных). Разницы
между разбитой вручную таблицей и таблицей разбитой с помощью partitioning Вы заметить не должны.
Если у Вас большие объемы данных и Вы можете себе позволить работать на бета-версии сервера, то
Ваш выбор - partitioning 
Неактивен
Спасибо за ответ
Объем данных у меня планируется приличный? по позволить себе рботать на выделенном сервере пока не могу, значит буду маяться с несколькими таблицами.
Неактивен
С несколькими таблицами существует такой плюс, что можно логику всего приложения перестроить так, чтобы связь между ними была минимальна, а потенциально разнести их на разные машины (без federated, конечно). Но судя по вопросу, все это не в Ваших интересах.
Неактивен
Почему же не в моих? как раз в моих, просто я разнесение таблиц по разным серверам додумался пока только используя federated таблицы, на создание кластера ума не хватает.
В общем то у меня идея разбаить одну большую таблицу на несколько маленьких по определенному признаку, пока я остановился на одном - тип записи (пока их 4). Логика работы в БД следующая: записи добавляются в одну общую таблицу, затем над ними производится ряд операция, довольно ресурсоемких, после этого записи рассовываются по своим таблицам согласно типу ну и оттуда уже они доступны конечным пользователям. А разместить их на разных серверах это очень даже хорошо, я и подумал что меня спасет система:
Серверв1 содержит временные таблицы и ту самую которая большая и процедуры для обработки + federated ссылки на окончательные таблицы которые находятся на Сервере(, доступном уже пользователям и инсерт после обработки производится уже в эти таблицы. Вот такое разделение на таблицы-сервера я придумал.
Достаточно ли это оптимальное решение?
Количество записей может исчисляться в миллионы или дсятки миллионов в перспективе, причем недалекой.
Неактивен
Я написал так как, ИМХО, если проблему можно решить покупкой одного хорошего сервера, то не стоит связываться с разделением логики приложения. FEDERATED и большие таблицы - гремучая смесь, так как federated часто выполняет SELECT *;
Неактивен
Смею заметить, что не только выполняет SELECT *, но и материализует на другой машинке во временную
табличку, а потом сносит. Очень неэффективное использование ресурсов.
Что касается десятков миллионов строк в таблице - число 4 Вас вряд ли спасет. Думаю, стоит задуматься
о 256 или 1024
P.S. А про выделенный сервер подумайте серьезно - база будет очень жестко прогибать диск (если, конечно,
данные будут использоваться).
Неактивен
Данные будут пользоваться конечно. По поводу того что материализует табличку и потом сносит - federated таблицы у меня будут в служебной БД и только для того что бы делать в них insert из общей, большой таблицы и потом в этой общей удалять эти записи, а select из этих 4 таблиц уже будет делаться только на сервере откуда запрашивают пользователи. И еще возник вопрос - мне нужно из одной таблицы ПЕРЕМЕСТИТЬ записи по нескольким таблицам (пока 4) на основании некоторого признака. Я сейчас делаю insert ... select а потом delete. меня это не очень устраивает т.к. пока я делаю insert в большой таблице могут появиться записи еще не обработанные и не скопирвоанные на боевой сервер, а удовлетворяющие условию при удалении. можно ли как то именно перенести данные а не скопировать и потом удалить?
наверное я опять не точно выразился. могу задать этот вопрос в отдельном топике. похоже к этому он уже не сильно относится.
Неактивен
Можно удалить только те записи, которые вставлены.
Неактивен
Спасибо, такой вариант я рассматривал. Получается приличное количество операций.
Неактивен
Как вариант - InnoDB + REPEATABLE READ. Повторное чтение (оно же удаление) из той же
таблицы увидит тот же набор строк
Неактивен
