Разумно ли хранить длинные уникальные текстовые строки в кубах OLAP для детализированного поиска (особенно в SSAS)?

У меня есть мотивация хранить несколько длинных текстовых строк в кубе OLAP, длиной порядка 1000 или 10 000 символов, но мне интересно, не введет ли это меня в заблуждение. (Мне также любопытно узнать немного больше о том, как механизмы OLAP обрабатывают строки.) Конкретный вариант использования, который я имею в виду, заключается в том, что у меня есть уникальное, ранее существовавшее «описание записи» для каждого из моих фактов OLAP, и я хочу поместить эти описания в куб, чтобы у меня была возможность вернуть их, когда я выполняю операцию DRILLTHROUGH. Напротив, мне не нужно, чтобы описания записей появлялись при выполнении обычных операций со сводной таблицей / типом агрегата. (Описания слишком длинные для разумного отображения в сводной таблице, плюс каждый факт имеет уникальное описание, а это означает, что нет смысла объединять описания.) В моем текущем наборе данных около 700000 фактов, хотя мне также любопытно, если ответ изменится для больших наборов данных.

Я надеялся, что сервер OLAP сможет сделать что-нибудь разумное, если я помещу эти длинные строки в куб. В частности, в случае Sql Server / SSAS я подумал, что, возможно, я поместил бы их в измерение, помеченное как ROLAP, чтобы сэкономить использование памяти, и использовать вырожденное измерение (также известное как «измерение фактов» в терминологии SSAS), чтобы избежать ненужные сложности с ETL. Но мне любопытно, будет ли это по какой-то причине считаться ужасной практикой или есть какие-то скрытые ошибки.

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


olap ssas drillthrough
person Chris    schedule 23.12.2011    source источник
comment
Я наткнулся на эту страницу и вынужден упомянуть (с опозданием!), Что это невероятно плохая идея. И это еще мягко сказано.   -  person    schedule 15.09.2013
comment
@TomChester Я ценю (без иронии), насколько выразительный ваш комментарий, и, возможно, вы правы. Если бы вы хотели добавить ответ, вкратце объясняющий, ПОЧЕМУ это ужасно, это было бы даже лучше!   -  person Chris    schedule 22.09.2013

Ответы (4)


arrow_upward
3
arrow_downward

Вот что мне удалось узнать о последствиях хранения таких строк в SSAS, особенно в SSAS 2008. Когда я рассматриваю структуры данных, они сосредоточены исключительно на хранилище MOLAP, с чем я экспериментировал.

Во-первых, стандартные инструменты MS ETL (извлечение / преобразование / загрузка, т.е. импорт данных), такие как Business Intelligence Development Studio, могут попытаться помешать вам импортировать большие текстовые поля, особенно поля varchar (max), но есть обходной путь, и он доказал свою эффективность для меня. (Для BIDS это включает в себя ручную настройку элемента DataSize в XML-файле, потенциально на магический размер 163315555 байт. Реквизит для Matija Lah, чтобы выяснить это.)

Во-вторых, насколько я могу судить, хранение большого количества длинных уникальных строк не должно наносить ущерб структурам данных на диске, используемым SSAS. Кроме того, размер строковых данных на диске должен быть того же порядка величины, что и размер строковых данных в вашем источнике данных. Вот приблизительная информация о том, как SSAS обрабатывает строки:

  • Базовые структуры данных OLAP (например, для атрибутов измерения или для фактов групп мер) не содержат напрямую строк; вместо этого содержат смещения в файлы «строкового хранилища» (расширения .ksstore, .asstore, .bsstore или .string.data), которые содержат фактические строковые данные.
  • В данном хранилище строк каждая строка представлена ​​только один раз. Если несколько строк в таблицах исходных данных содержат повторяющиеся строки, то на уровне SSAS / MOLAP это будет преобразовано в повторяющиеся смещения файлов, а не в повторяющиеся строковые значения.
  • Если исходная строка имеет длину n, то соответствующая структура данных в хранилище строк имеет 8-ми байтов служебных данных плюс 2 * n байтов на символ. (Строки по своей природе хранятся в 2-байтовом формате Unicode в SSAS.)
  • Чтобы получить фантастические подробности об этом, я предлагаю книгу Microsoft SQL Server 2008 Analysis Services Unleashed, в частности, глава 20 «Физическая модель данных».
  • По крайней мере, в моих экспериментах файлы строкового хранилища не кажутся сжатыми - по крайней мере, они не намного меньше, чем было бы несжатое строковое хранилище.

Я экспериментально подтвердил, что текстовые данные занимают один и тот же порядок байтов независимо от того, хранятся ли они в SSAS MOLAP или в таблице sql. В частности, я сделал «выбор суммы (len (myfield)) из mytable» из одной из моих таблиц измерений, а затем сравнил ее с размером файлов соответствующего атрибута в моем каталоге данных SSAS. Размер был 172 МБ в SQL и 304 МБ в SQL-сервере. (Размер sql составлял 147 МБ, если я суммировал все уникальные строки, а не все строки.) В моем случае разница в размере в основном объяснялась кодировкой символов; мои исходные данные sql хранятся с одним байтом на символ, тогда как SSAS хранит все строки с двумя байтами на символ. Я обнаружил, что файл .kssstore полностью преобладает над всеми другими файлами, связанными с этим атрибутом, по размеру, независимо от того, оптимизировал ли я атрибут с помощью AttributeHierarchyOptimizedState = FullyOptimized.

В-третьих, существует ограничение в 4 ГБ на размер файлов строкового хранилища, что ограничивает количество уникального текста, который может быть связан, например, с определенным измерением / атрибутом. В моем случае я прошел менее 10% пути к пределу, но это может повлиять на некоторых людей. (Быстрый расчет порядка величины для исходного сообщения: 1 миллион фактов * 10 000 байт / факт = 10 ГБ текста.) Если вы действительно достигнете этого предела, вы, очевидно, достигнете его во время «обработки» куба. Судя по всему, это относится даже к размерам ROLAP. Для решения этой проблемы могут быть некоторые хитрости. См. здесь. Обратите внимание, что Sql Server 2012 может снять это ограничение 4 ГБ.

В-четвертых, похоже, что если длинные уникальные строки создают проблему в SSAS, они делают это на уровне представления в памяти. Одна потенциальная проблема (которую я не рассматривал подробно) заключается в том, что наличие этих дополнительных строк, кэшированных в памяти, будет препятствовать SSAS сохранять в памяти другие важные структуры данных и, таким образом, снижать производительность. Другая проблема, предложенная в книге The Microsoft Data Warehouse Toolkit (хотя я еще не нашел это утверждение в другом месте) заключается в том, что SSAS выполняет расширенное строковое заполнение своих структур данных в памяти:

«В реляционной базе данных хранятся строковые столбцы переменной длины ... Однако другие части набора инструментов SQL Server будут заполнять эти столбцы до их полной ширины. Примечательно, что службы Integration Services и Analysis Services заполняют строковые столбцы пробелами по мере их загрузки в память. И службам Integration Services, и службам Analysis Services нравится физическая память, поэтому объявление строковых столбцов, которые намного шире, чем они должны быть, требует затрат ».

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

person Chris    schedule 23.12.2011

arrow_upward
1
arrow_downward

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

добавьте суррогат целого числа в UDM и создайте действие SSRS Drillthrough

http://msdn.microsoft.com/en-US/library/ms174526(v=SQL.90).aspx

который ищет текстовое поле по значению ключа.

person Jason Horner    schedule 31.12.2011
comment
Изначально я представлял, что могу заставить SSAS делать что-то подобное от моего имени, просто выбрав правильный вариант из выпадающего списка конфигурации в Business Intelligence Dev Studio. (например, я изначально надеялся, что что-то подобное может произойти, если я создам измерение RecordDescription и помечу его как ROLAP - хотя теперь я думаю, что это, вероятно, основано на непонимании того, как работают измерения ROLAP.) Но если это не может быть так просто если изменить раскрывающийся список, то ваше предложение действительно звучит умно. - person Chris; 01.01.2012

arrow_upward
0
arrow_downward

Я бы использовал вырожденное измерение, но скрывал бы его через SSAS, пока не запрошено с помощью Drillthrough Action.

Я не могу рассказать вам о внутреннем хранилище строк для механизма AS, но что касается их хранения в SQL, я бы позаботился о том, чтобы ваш столбец varchar (MAX) находился в конце ваших столбцов, чтобы ускорить сканирование этих строк механизмами SQL. ряды.

При 700 000 строк, достаточном объеме памяти и дискового ввода-вывода вы не слишком сильно обременяете SQL.

person Michael Rice    schedule 23.12.2011
comment
Является ли скрытие затемнения просто установкой Visible = False (скажем, в Business Intelligence Dev Studio), или есть какой-то более ориентированный на производительность способ сделать это? Я знаю, что на уровне атрибутов есть различие между AttributeHierarchyVisible и AttributeHierarchyEnabled. Последнее выглядит лучше для производительности, если вам не нужно нарезать / нарезать кубики на атрибут (как я этого не делаю в моем случае). К сожалению, AttributeHierarchyEnabled = False, по-видимому, означает, что вы не может детализировать. - person Chris; 01.01.2012

arrow_upward
0
arrow_downward

Еще не проработали все описанные возможности и ссылки на них, но эта ветка 2007 года посвящена той же теме и кажется довольно актуальной:

http://www.sqldev.org/sql-server-analysis-services/discussion-about-how-to-create-a-fact-drillthrough-dimension-the-best-way-34857.shtml

Одна новая возможность, возникшая здесь, заключается в том, что вместо того, чтобы рассматривать текст, хранящийся в таблице фактов, как вырожденное измерение, вы потенциально можете рассматривать его как текстовое (а не числовое) измерение < / em>. Первоначальный поиск в Google предполагает, что SSAS может поддерживать это, но есть некоторые уловки, чтобы сделать это правильно, например вы, вероятно, захотите отключить агрегацию для этой меры, вам может потребоваться что-то нестандартное, чтобы поле появилось при детализации, и для этого может потребоваться корпоративная версия SSAS.

person Chris    schedule 31.12.2011