Mysql: как выполнять тяжелые аналитические запросы в режиме реального времени
Я запускаю приложение crm, которое использует базу данных mysql. Мое приложение генерирует много данных в MySQL. Теперь я хочу предоставить своему клиенту раздел отчетности, где администратор может просматривать отчеты в реальном времени, они должны иметь возможность фильтровать в режиме реального времени. По сути, я хочу, чтобы мои данные были в режиме реального времени как можно быстрее.
Я реализовал отчетность, используя mysql и php. Но теперь, когда данных слишком много, запрос занимает слишком много времени и страница не загружается. После нескольких чтений я наткнулся на несколько терминов, таких как Nosql, mongoDb, cassandra, OLAP, hadoop и т. Д., Но я не знал, какой выбрать. Есть ли какой-нибудь механизм, который бы передавал мои данные из mysql в nosql, по которому я могу выполнить свой отчетный запрос и обслуживать моего клиента, сохраняя мою базу данных mysql такой, какая она есть?
Решение
Не имеет значения, какую технологию базы данных / хранилища данных вы используете для составления отчетов: вам все равно придется разработать ее для эффективного извлечения необходимой информации.
Повышение производительности путем переключения с MySQL на MongoDB или на одну из других масштабируемых систем хранения ключей / значений похоже на решение проблемы заторов в пешеходах путем строительства железной дороги. Потребуется много работы, чтобы это помогло ситуации. Я предлагаю вам сначала попытаться заставить вещи работать лучше в MySQL.
Прежде всего, вам нужно внимательно посмотреть, какие SQL-запросы в вашей системе отчетов вызывают проблемы. Вы можете оптимизировать их производительность, добавив индексы или выполнив другой рефакторинг. Это должно быть вашим первым шагом. MySQL имеет медленный журнал запросов. Посмотри на это.
Во-вторых, вы можете добавить ресурсы (оперативную память, более быстрые диски и т. Д.) В MySQL и настроить его для более высокой производительности. Есть книга под названием High Performance MySQL, в которой предлагается разумная методология для этого.
В-третьих, многие люди, которым необходимо добавить функцию отчетности в занятое приложение, используют репликацию MySQL. То есть они настраивают один или два подчиненных сервера MySQL для приема копий всех данных с главного сервера.
http://dev.mysql.com/doc/refman/5.5/en/replication-howto.html
Затем они используют подчиненный сервер или серверы для выполнения запросов отчетов. Рабы обычно на несколько секунд или минут отстают от хозяина (то есть они немного устарели). Но обычно этого достаточно, чтобы создать иллюзию пользователей в режиме реального времени.
Обратите внимание, что если вы используете MongoDB или какую-либо другую технологию, вам также придется копировать ваши данные.
Другие решения
Я добавлю эту ссылку, чтобы вы могли прочитать, что на самом деле дает определенные варианты использования: http://www.mongodb.com/use-cases/real-time-analytics но я буду говорить для более традиционной настройки только MongoDB.
Я использовал и MySQL, и MongoDB для аналитических целей, и я считаю, что MongoDB лучше подходит, если не нужно немного взломать, чтобы заставить его работать хорошо.
Самое замечательное в MongoDB, когда дело доходит до получения аналитических данных, заключается в том, что ей не требуется, чтобы ввод-вывод / память каждый раз записывали отдельный набор результатов. Это делает чтение на одном элементе набора реплик чрезвычайно масштабируемым, поскольку вы просто добавляете свои аналитические коллекции в рабочий набор (память a.k.a) и обслуживаете их напрямую из тех, которые используют пакетные ответы (это реализация драйверов по умолчанию).
Так что с MongoDB репликация редко дает преимущество с точки зрения чтения / записи, и на самом деле с MySQL я обнаружил, что это не так. Если это так, то вы делаете неправильные запросы, которые все равно не будут масштабироваться; в этот момент вы устанавливаете memcache на свои серверы баз данных и, смотри, у вас устаревшие данные, которые в любом случае обслуживаются из памяти в стиле NoSQL … ага, наверное.
Итак, у нас есть некоторые основные идеи изложены; время поговорить об этом взломать. Чтобы получить максимально возможную скорость от MongoDB, и поскольку он не имеет JOIN, вам нужно сгладить ваши данные, чтобы на вашей стороне не понадобился ни один набор результатов.
Есть много тактик для этого, но я упомяну здесь: http://docs.mongodb.org/ecosystem/use-cases/pre-aggregated-reports/ предварительно агрегированные отчеты. Этот метод также хорошо работает в технологиях SQL, так как он по сути аналогичен логическому разделению таблиц, чтобы сделать запросы быстрее и легче для большой таблицы.
Что вы делаете, так это то, что вы получаете свои аналитические данные, разбиваете их по размеру, например, по дням или месяцам (или обоим), а затем агрегируете свои данные по этим диапазонам ненормализованным образом, по существу, все в одну строку.
После этого вы можете показывать отчеты прямо из коллекции без необходимости создания результирующего набора для некоторых очень быстрых запросов.
Позже вы могли бы добавить шаг уменьшения карты для создания лучшей аналитики, но пока мне это не нужно, я выполнил полную аналитику на основе видео без такой необходимости.
Это должно начать вас.