Каков наилучший способ хранения данных тренда? - PullRequest
7 голосов
/ 20 апреля 2011

В настоящее время я создаю приложение, в которое импортирую статистические данные для (в настоящее время) около 15 000 продуктов.В настоящее время, если бы мне нужно было поддерживать одну таблицу базы данных для статистики каждого дня из одного источника, она была бы увеличена на 15 000 строк данных (скажем, 5-10 полей в строке, в основном с плавающей запятой, int) в день.Очевидно, что приравнивается к более чем 5 миллионам записей в год в одной таблице.

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

Теперь данные представляют собой статистические данные / данные, основанные на тенденциях, и будут иметь в основном 1 запись в день на запись и много операций чтения.Однако для целей создания отчетов и составления графиков на лету мне необходим быстрый доступ к подмножествам данных на основе правил (диапазоны дат, диапазоны значений и т. Д.).

Вопрос в том, является ли это лучшим способом храненияданные (таблицы MySQL InnoDb), или есть лучший способ хранить и обрабатывать статистические данные / данные трендов?

Другие варианты, которые я выбрасывал на этом этапе: 1. Несколько баз данных (по одной на продукт), сотдельные таблицы для каждого источника данных в.(т. е. база данных: ProductA, таблица (ы): Source_A, Source_B, Source_C) 2. Одна база данных, несколько таблиц (по одной для каждого продукта / источника данных) (т. е. база данных: Products, таблицы (таблицы): ProductA_SourceA, ProductA_SourceB и т. д.) 3. Вся factual или конкретная информация о продукте в базе данных и все statistical данные в csv, xml, json, (плоские файлы) в отдельных каталогах.

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

Ответы [ 2 ]

2 голосов
/ 14 ноября 2013

Это немного зависит от того, как выглядят ваши данные, и от того, какие агрегаты / тренды вы хотите использовать.Большинство реляционных баз данных прекрасно работают для такого рода хронологических данных.Даже при наличии миллиардов записей правильная индексация и разбиение могут быстро найти нужные вам записи.БД, такие как Oracle, MySQL, SQL-Server, подпадают под эту категорию.

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

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

По аналогии с идеей хранилища данных, если агрегация занимает слишком много времени, вы можете быстро объединить агрегаты в структуру, к которой можно быстрее выполнять запросы.В моем предыдущем примере вам может понадобиться получать нечасто только большие фрагменты данных, но чаще - некоторую агрегацию, например, 52-недельный максимум.Вы можете хранить большое количество необработанных данных в одном формате, а затем каждую ночь выполнять работу, отрабатывая только то, что вам нужно, в таблицу, которая вместо тысяч точек данных на одну акцию теперь имеет 3 или 4.

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

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

2 голосов
/ 20 апреля 2011

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

http://en.wikipedia.org/wiki/Column-oriented_DBMS

У нас был хороший опыт работы с InfiniDB:

http://infinidb.org/

, и Infobright выглядит хорошо:

http://www.infobright.com/

У InfiniDB и Infobright есть бесплатные выпуски с открытым исходным кодом для сообщества, поэтому я бы порекомендовал использовать их для оценки производительности, которую вы можете получить.

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

...