Что хороший путь состоит в том, чтобы денормализовать mysql базу данных?
Благодаря Anant
я пришел к выводу:
Я полностью изменил свой старый файл database.php в папке config с новым:
From:
$db['default']['hostname'] = 'localhost';
$db['default']['username'] = '';
$db['default']['password'] = '';
$db['default']['database'] = '';
$db['default']['dbdriver'] = '';
$db['default']['dbprefix'] = '';
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = '';
$db['default']['char_set'] = 'utf8';
$db['default']['dbcollat'] = 'utf8_general_ci';
$db['default']['swap_pre'] = '';
$db['default']['autoinit'] = TRUE;
$db['default']['stricton'] = FALSE;
To:
$db['default'] = array(
'dsn' => '',
'hostname' => '',
'username' => '',
'password' => '',
'database' => '',
'dbdriver' => 'mysqli',
'dbprefix' => '',
'pconnect' => FALSE,
'db_debug' => (ENVIRONMENT !== 'production'),
'cache_on' => FALSE,
'cachedir' => '',
'char_set' => 'utf8',
'dbcollat' => 'utf8_general_ci',
'swap_pre' => '',
'encrypt' => FALSE,
'compress' => FALSE,
'stricton' => FALSE,
'failover' => array(),
'save_queries' => TRUE
);
И ошибка исчезла!
8 ответов
Я знаю больше о mssql, что mysql, но я не думаю количество соединений или количество строк, о которых Вы говорите, должен вызвать Вас слишком много проблем с корректными индексами на месте. Вы проанализировали план запросов, чтобы видеть, скучаете ли Вы по кому-либо?
http://dev.mysql.com/doc/refman/5.0/en/explain.html
Однако после того как Вы - satisifed со своими индексами и исчерпали все другие проспекты, денормализация могла бы быть правильным ответом. Если у Вас просто есть один или два запроса, которые являются проблемами, ручной подход является, вероятно, соответствующим, тогда как своего рода инструмент организации хранилищ данных мог бы быть лучше для создания платформы для разработки кубов данных.
Вот сайт, я нашел что касания к предмету:
http://www.meansandends.com/mysql-data-warehouse/?link_body%2Fbody=%7Bincl%3AAggregation%7D
Вот является простой техникой, которую можно использовать, чтобы продолжать денормализовывать простые запросы, если Вы просто делаете некоторых за один раз (и я не заменяю Ваши таблицы OLTP, просто создав новую для создания отчетов о целях). Скажем, у Вас есть этот запрос в Вашем приложении:
select a.name, b.address from tbla a
join tblb b on b.fk_a_id = a.id where a.id=1
Вы могли составить денормализованную таблицу и заполнить почти с тем же запросом:
create table tbl_ab (a_id, a_name, b_address);
-- (types elided)
Уведомление соответствие символов нижнего подчеркивания таблица искажает Вас использование
insert tbl_ab select a.id, a.name, b.address from tbla a
join tblb b on b.fk_a_id = a.id
-- no where clause because you want everything
Затем для фиксации приложения, чтобы использовать новую денормализованную таблицу, переключить точки для символов нижнего подчеркивания.
select a_name as name, b_address as address
from tbl_ab where a_id = 1;
Для огромных запросов это может сэкономить много времени и проясняет, куда данные прибыли из, и можно снова использовать запросы, которые Вы уже имеете.
Помнят, я только защищаю это как последнее средство. Я держал пари, что существует несколько индексов, которые помогли бы Вам. И когда Вы денормализовываете, не забывайте объяснять дополнительное пространство на своих дисках и фигуру при выполнении запроса для заполнения новых таблиц. Это должно, вероятно, быть ночью, или каждый раз, когда действие является низким. И данные в той таблице, конечно, точно никогда не будут актуальны.
[Еще одно редактирование] не забывает новые таблицы создание потребности, которая будет индексирована также! Хорошая часть - то, что можно индексировать к содержанию основы и не волноваться о конкуренции блокировки обновления, с тех пор кроме объемной вставки таблица будет только видеть, выбирает.
MySQL 5 действительно поддерживает представления , который может быть полезным в этом сценарии. Это кажется, что Вы уже сделали большую оптимизацию, но если не можно использовать MySQL , ОБЪЯСНЯЮТ синтаксис для наблюдения, какие индексы на самом деле используются и что замедляет запросы.
До движения о нормализации данных (используете ли Вы представления или просто копируете данные более эффективным способом), я думаю, начиная с самых медленных запросов, и прокладывание себе путь является хорошим подходом для взятия.
Я знаю, что это является немного тангенциальным, но Вы попытались видеть, существует ли больше индексов, которые можно добавить?
у меня нет большого количества фона DB, но я работаю с базами данных много недавно, и я находил, что много запросов может быть улучшено только путем добавления индексов.
Мы используем DB2, и существует команда, названная db2expln и db2advis, первое укажет, используются ли сканирования таблицы по сравнению с индексными сканированиями, и второе рекомендует индексы, которые можно добавить для улучшения производительности. Я уверен, что MySQL имеет подобные инструменты...
Так или иначе, если это - что-то, которое Вы еще не рассмотрели, помогало много со мной..., но если Вы уже пошли этим путем, затем я предполагаю, что это не то, что Вы ищете.
Другая возможность является "осуществленным представлением" (или как они называют ее в DB2), который позволяет Вам указать таблицу, которая по существу создается из частей от нескольких таблиц. Таким образом, вместо того, чтобы нормализовать фактические столбцы, Вы могли обеспечить это представление для доступа к данным..., но я не знаю, имеет ли это серьезное влияние производительности на, вставляет/обновляет/удаляет (но если это "осуществлено", затем это должно помочь с выборами, так как значения физически хранятся отдельно).
В соответствии с некоторыми из других комментариев, я определенно взглянул бы на Вашу индексацию.
Одна вещь я обнаружил ранее в этом году на наших базах данных MySQL, было питание сводных индексов. Например, если Вы сообщаете относительно номеров заказа по диапазонам даты, сводному индексу на номере заказа и приказываете, чтобы столбцы даты могли помочь. Я полагаю, что MySQL может только использовать один индекс для запроса поэтому, если бы у Вас просто были отдельные индексы на номере заказа и дате порядка, то это должно было бы выбрать только одного из них для использования. Используя EXPLAIN команда может помочь определить это.
Для предоставления признака производительности с хорошими индексами (включая многочисленные сводные индексы) я могу выполнить запросы, присоединяющиеся к 3 таблицам в нашей базе данных, и получить почти мгновенные результаты в большинстве случаев. Для более сложного создания отчетов о большинстве запросов, выполненных через менее чем 10 секунд. Эти 3 таблицы имеют 33 миллиона, 110 миллионов и 140 миллионов строк соответственно. Обратите внимание, что мы также уже нормализовали их немного для ускорения нашего наиболее распространенного запроса на базе данных.
[еще 113] информация относительно Ваших таблиц и типов создания отчетов о запросах может позволить дальнейшие предложения.
Для MySQL мне нравится этот разговор: сеть Реального мира: Производительность & Масштабируемость, MySQL Edition . Это содержит много различных советов для того, чтобы вытащить больше скорости из MySQL.
Вы могли бы также хотеть рассмотреть выбор во временную таблицу и затем выполнение запросов на той временной таблице. Это избежало бы потребности воссоединиться с Вашими таблицами для каждого запроса, который Вы выпускаете (предполагающий, что можно использовать временную таблицу для многочисленных запросов, конечно). Это в основном дает Вам денормализованные данные, но если Вы только делаете избранные вызовы, нет никакой озабоченности по поводу непротиворечивости данных.
В дополнение к моему предыдущему ответу другой подход, который мы проявили в некоторых ситуациях, должен хранить данные создания отчетов ключа в отдельных сводных таблицах. Существуют определенные запросы создания отчетов, которые просто будут медленными даже после денормализовывания и оптимизаций, и мы нашли, что составление таблицы и хранение рабочих общих количеств или сводной информации в течение месяца, поскольку это вошло, сделали конец месяца, сообщив намного более быстрый также.
Мы нашли этот подход легким реализовать, поскольку он не повредил ничего, что уже работало - это - просто дополнительная база данных, вставляет в определенные моменты.
Я играл со сводными индексами и видел некоторую реальную выгоду..., возможно, я установлю некоторые тесты, чтобы видеть, может ли это сохранить меня здесь.. по крайней мере, для немного дольше.