Как работать с большими наборами данных для аналитики и с разным количеством столбцов?

Question

Я строю аналитическую систему для мобильного приложения, и мне было трудно решить, как хранить и обрабатывать большие объемы данных.

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

Я рассмотрел Amazon SimpleDb, который хорошо обрабатывает различное количество атрибутов, но не поддерживает GROUPBY и, кажется, не очень хорошо работают при подсчете строк.Генерация месячного графика с 30 точками данных потребует запроса для каждого дня для каждого набора данных.

MySQL намного лучше обрабатывает модификаторы COUNT и GROUP, но дополнительные атрибуты требуют хранения в таблице ссылок и JOIN для получения представлений, где атрибутысопоставить заданное значение, которое не очень быстро.Функция секционирования 5.1 может помочь немного ускорить процесс.

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

Я что-то упустил в своих исследованиях и есть ли лучший способ сделать это, чем использовать MySQL?Это не похоже на правильную задачу для работы, но я не могу найти ничего способного как к запросам GROUP / COUNT, так и к гибкой структуре таблиц.

Answer 1

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

Я предлагаю вам сохранить ваши данные в CouchDB по следующим причинам:

• Его столы не имеют структуры
• Его запросы предварительно обработаны
• Его поддержка map-redund позволяет вашим запросам обрабатывать группу на
• Он имеет модель доступа к сервису REST, которая позволяет подключаться практически ко всему, что обрабатывает HTTP-запросы

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

Answer 2

Сохранение в MySQL: если количество записей ограничено / чтения встречаются чаще, а данные относительно просты (т.е. вы можете предсказать возможные символы), вы можете попробовать использовать столбец text / blob в главномтаблица, которая обновляется значениями, разделенными запятыми, или парами ключ / значение с триггером AFTER INSERT / UPDATE в таблице соединений.Фактические данные хранятся в отдельной таблице, поэтому поиск дополнительных / дополнительных атрибутов MAX все еще можно выполнить относительно быстро, но получение полного набора данных для одного из ваших «представлений» будет одной строкой в ​​основной таблице, котораяВы можете разделить отдельные значения с помощью используемого вами сценария / приложения, что избавит вас от значительной нагрузки на саму базу данных.

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

UPDATE join_table
JOIN main_table
ON main_table.id = join_table.main_id
SET main_table.cache  = GROUP_CONCAT(CONCAT(join_table.key,'=',join_table.value) SEPARATOR ';')
WHERE join_table.main_id = 'foo' GROUP BY main_table.id`).

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