Советы / ссылки / книги для проектирования очень большой базы данных с низкой степенью детализации? - PullRequest
3 голосов
/ 30 августа 2011

Программисты SAS в моей компании работают с исследователями, чтобы проанализировать данные, хранящиеся в текстовых файлах размером около 1 ТБ.В результате процессы SAS могут занять несколько дней.Всякий раз, когда исследователи хотят немного изменить вопрос, процессы должны быть перезапущены, что потребует дополнительных часов или дней.

Программисты SAS обратились к нашей команде DBA за способом хранения своих данных с целью значительногоПовышение производительности запросов.

Две основные трудности:

  1. У нас есть только несколько примеров запросов, и нет типичного набора ожидаемых запросов.
  2. Многие из запросов будут иметь форму, подобную

    ВЫБЕРИТЕ СЧЕТЧИК (DISTINCT id) ИЗ ТАБЛИЦЫ t ГДЕ a = true И b = 3 И c IN (от 3 до 10);

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

Iищу любые ресурсы, которые говорят о разработке баз данных с аналогичными ограничениями.В «1019 * Building Data Warehouse» Билла Инмона он кратко упоминает «хранилища данных» и «хранилища данных».Используя эти термины, я нашел эту статью, которая оказалась несколько полезной: «Проектирование хранилища данных для эффективного интеллектуального анализа данных» [ pdf ], но это более или менее так.Большая часть того, что я нахожу при поиске re: «интеллектуальный анализ данных», касается OLAP.

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

Спасибо!

Ответы [ 2 ]

1 голос
/ 02 сентября 2011

Читайте все, что можете, Ральф Кимбалл.

http://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimensional/dp/0471200247

Ваш типичный запрос (SELECT aggregate FROM fact JOIN dimension WHERE criteria) - самое подходящее место для звездной схемы.

Забудьте "интеллектуальный анализ данных". Это не полезный термин.

Сосредоточьтесь на «Звездной схеме». Создайте правильную структуру данных.

0 голосов
/ 01 сентября 2011

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

  • Сколько времени занимает чтение текстового файла?
  • Можно ли отправлять инкрементные текстовые файлы и поддерживать несколько наборов данных SAS, к которым вы добавляетеинкрементные данные?

Вот несколько предложений ...

Если финансирование не является проблемой, то переход на внутреннюю СУБД, такую ​​как Netezza, поможет решить эту проблему.

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

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

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Спасибо, М

...