Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
28.11.2005, 16:18
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Уважаемые спецы! Подскажите пожалуйста, строил ли кто-нить из Вас Хранилище Данных на базе MS SQL - сервера? Насколько вообще правильно использовать MS SQL для построения DWH? Какие плюсы и минусы есть у него по сравнению с другими системами для построения DWH? В дальнейшем планируется использовать данные из хранилища в MS AS и в Экселе, или другом олап - клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.11.2005, 17:59
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
мало фич у него, и много ограничений, относящихся к DWH, если сравнивать MS 2000 с Oracle 9i. Если вопрос цены и железок не стоит - берите Oracle :) C другой стороны, если ваше "хранилище" - на пару десятков миллионов записей - то нечего огород городить, MS справится вполне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.11.2005, 18:02
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Не, переход на Oracle в планы не входит:) Правда, объем данных еще не ясен, только начинаем думать о DW. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.11.2005, 18:38
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
_zxНе, переход на Oracle в планы не входит:) Правда, объем данных еще не ясен, только начинаем думать о DW. Оценка объёма данных в данном случае очень важна. Если будет гигабайт 10-20, то в принципе можно сделать неплохо, по опыту знаю. Если больше - лучше не надо. Слышал я и терабайтных хранилищах на MS SQL, но слабо верится. В общем считайте гигабайты. И учтите, что нормализация не всегда хороша, если речь идёт о хранилищах данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.11.2005, 20:43
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Могу сказать про реляционное хранилище: Для начала вполне неплохой выбор. Объёмы несколько гигабайт с несложной схемой и несложными запросами потянет. Плюс грамотная политика по агрегатам, индексам, partitioning - до 80-100 Гб вполне можно разогнать, потом проблемы будут практически не решаемые, по крайней мере на версии 2000 :( Из плюсов - DTS, этот форум :) Из явных минусов: никакой partitioning, вообще с DWH фичами труба, никакая масштабируемость во всех смыслах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 10:24
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
MSTR_FanМогу сказать про реляционное хранилище: Для начала вполне неплохой выбор. Объёмы несколько гигабайт с несложной схемой и несложными запросами потянет. Плюс грамотная политика по агрегатам, индексам, partitioning - до 80-100 Гб вполне можно разогнать, потом проблемы будут практически не решаемые, по крайней мере на версии 2000 :( Из плюсов - DTS, этот форум :) Из явных минусов: никакой partitioning, вообще с DWH фичами труба, никакая масштабируемость во всех смыслах. Кстати о DTS. В 2005 версии я его пока не обнаружил. От него остался Import-Export Wizard. Может быть кто знает, куда он подевался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 10:43
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
Он теперь называется Inegration Services(SSIS). Ирина <BR> <BR>---------------------------------------------------- <BR>This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 12:54
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Уважаемые гуру, из всего вышесказанного я так понял, что у меня работать все будет очень плохо, даже если будет работать вообще? ( У меня MSAS2K. Объемы примерно следующие: Кол-во строк в одной самой большой таблице будет превышать 150 млн. записей. Общий объем всего хранилища будет примерно около 50 Гигов (это только данные без агрегатов и т.д.). Объемы с каждым днем растут :( Стоит задача построения отчетов с использованием ОЛАПа. Сейчас OLTP работает на MS AS 7.0 (2K). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:07
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
2 dmitry_kz: из всего вышесказанного я так понял, что у меня работать все будет очень плохо. У меня MSAS2K. Объемы примерно следующие: Кол-во строк в одной самой большой таблице будет превышать 150 млн. записей. Стоит задача построения отчетов с использованием ОЛАПа. Я бы сказал, что вопрос не в том, какая СУБД используется для создания хранилища данных, а какое OLAP-средство работает поверх хранилища... Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей, и все будет работать с 5-секундным откликом на каждый запрос пользователя. Просто чтобы это достичь, я буду использовать OLAP-сервер, который преобразует реляционные данные в формат MOLAP-куба. Так что 150 миллионов для MS SQL при правильном выборе OLAP-сервера - это небольшой объем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:22
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
2 Jurii: Ага, понял... Тогда если для такой ситуации выбирают MS AS2K, то это приемлимо? Ведь он же преобразовывает реляционные данные в MOLAP... :) Т.е. если схема такая: OLTP (MS SQL 7.0/2K) -> Хранилище данных (MS SQL 2K) -> OLAP (MS AS2K) то она вполне способна жить, и даже очень хорошо жить... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:35
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
dmitry_kz2 Jurii: Ага, понял... Тогда если для такой ситуации выбирают MS AS2K, то это приемлимо? Ведь он же преобразовывает реляционные данные в MOLAP... :) Т.е. если схема такая: OLTP (MS SQL 7.0/2K) -> Хранилище данных (MS SQL 2K) -> OLAP (MS AS2K) то она вполне способна жить, и даже очень хорошо жить... :) Вы абсолютно правы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:40
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
JuriiЯ могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей, и все будет работать с 5-секундным откликом на каждый запрос пользователя. Просто чтобы это достичь, я буду использовать OLAP-сервер, который преобразует реляционные данные в формат MOLAP-куба. Супер. Запрос - distinct count по таблице детального уровня с группировкой по 3-4 полям. Без ограничений. (Смотрим активность торговых точек по времени суток за всю историю, в деньгах и штуках) Размер таблицы - 1 млрд строк, для ровного счета :) Решение в студию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:42
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
2 dmitry_kz: Ага, понял... Тогда если для такой ситуации выбирают MS AS2K, то это приемлимо? Т.е. если схема такая: OLTP (MS SQL 7.0/2K) -> Хранилище данных (MS SQL 2K) -> OLAP (MS AS2K) то она вполне способна жить, и даже очень хорошо жить... :) MS AS - это один из двух самых мощных в мире OLAP-серверов, поэтому Ваша схема приемлема. Есть конечно тонкости, которые могут всплыть, если Вы будете решать сложные аналитические задачи. Поэтому полезно заранее анализировать потребности пользователей, и только на основе этого выбирать OLAP-инструментарий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 13:52
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
2 MSTR_Fan: Супер. Запрос - distinct count по таблице детального уровня с группировкой по 3-4 полям. Без ограничений. (Смотрим активность торговых точек по времени суток за всю историю, в деньгах и штуках) Размер таблицы - 1 млрд строк, для ровного счета :) Решение в студию! Если Вы представляете компанию S&T, которая недавно стала партнером Cognos, Вы должны знать, что такое Cognos PowerPlay. В MOLAP-куб PowerPlay можно закачать миллиард записей, и PowerPlay умеет считать Distinct Count и делать группировки. Задача по торговым точкам и часам суток - популярна и давно обкатана в PowerPlay. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 14:07
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Jurii Если Вы представляете компанию S&T, которая недавно стала партнером Cognos, Вы должны знать, что такое Cognos PowerPlay. Я не представляю здесь компанию S&T, хотя и хорошо к ней отношусь :) Jurii В MOLAP-куб PowerPlay можно закачать миллиард записей, и PowerPlay умеет считать Distinct Count и делать группировки. Задача по торговым точкам и часам суток - популярна и давно обкатана в PowerPlay. То есть Вы утверждаете что Cognos PowerPlay способен сделать full table scan таблицы любых размеров за 5 секунд, я правильно понял? И время закачивания мы считаем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 14:53
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
2 MSTR_Fan: Я не представляю здесь компанию S&T, хотя и хорошо к ней отношусь :) То есть Вы не обижаетесь на S&T за то что она Вас предала и подружилась с Cognos? Если так - то Вы пока еще не фан МСТР :) То есть Вы утверждаете что Cognos PowerPlay способен сделать full table scan таблицы любых размеров за 5 секунд, я правильно понял? И время закачивания мы считаем? PowerPlay не делает full table scan, эта операция для MOLAP-куба не актуальна. Те данные, которых бывает много (записи CDR, строки чеков и т.п.), не корректируются задним числом, поэтому их можно подкачивать инкрементально, и за счет этого минимизируется время обновления MOLAP-куба. Обычно большие кубы обновляются по ночам, когда пользователи спят и никуда не торопятся, но можно их обновлять и по факту поступления свежих данных в ХД. В дневное время суток уже обеспечивается 5-секундный отклик, так как все показатели во всех разрезах заранее просчитаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 15:41
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Jurii То есть Вы не обижаетесь на S&T за то что она Вас предала и подружилась с Cognos? Если так - то Вы пока еще не фан МСТР :) "Держи друзей близко, а врагов - ещё ближе" :) Jurii PowerPlay не делает full table scan, эта операция для MOLAP-куба не актуальна. Те данные, которых бывает много (записи CDR, строки чеков и т.п.), не корректируются задним числом, поэтому их можно подкачивать инкрементально, и за счет этого минимизируется время обновления MOLAP-куба. Обычно большие кубы обновляются по ночам, когда пользователи спят и никуда не торопятся, но можно их обновлять и по факту поступления свежих данных в ХД. В дневное время суток уже обеспечивается 5-секундный отклик, так как все показатели во всех разрезах заранее просчитаны. Очень интересно, а как происходит initial load? Предположим пришло изменение задним числом. И ещё такой момент: инкремент может приходить нецелостным - пришел факт, а в справочнике записи нет. Как с этим? Может PP обеспечить целостность или это возлагается на источник? Спасибо за ответы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 16:23
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
2 MSTR_fan: Очень интересно, а как происходит initial load? Первоначальная загрузка данных в MOLAP-куб конечно же требуется, и может занимать значительное время (для сотен миллионов записей может занять несколько часов). Но как мы понимаем, если строить серьезное реляционное ХД, то там есть аналогичные этапы - и полная загрузка, и обновление, и поднятие базы из бэкапа. Для одной знакомой мне крупной розничной сети требовалось чуть ли не 2 недели, чтобы поднять из бэкапа большую реляционную БД Oracle... Предположим пришло изменение задним числом. И ещё такой момент: инкремент может приходить нецелостным - пришел факт, а в справочнике записи нет. Как с этим? Может PP обеспечить целостность или это возлагается на источник? Конечно это экзотика, когда чек, пробитый месяц или год назад правится задним числом... Но если такое произойдет, то можно изменить соответствующие показатели в ячейках MOLAP-куба с помощью операции сторнирования. То же самое можно сказать про случай, если в исходных данных была запись с неправильным кодом товара или просто с непроставленным кодом - сторнирование и возможность в PowerPlay делать запись данных в произвольные ячейки куба, а также создавать новые ячейки в кубе без полного перепроцессинга куба, решают эти проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 17:32
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
JuriiКонечно это экзотика, когда чек, пробитый месяц или год назад правится задним числом... Но если такое произойдет, то можно изменить соответствующие показатели в ячейках MOLAP-куба с помощью операции сторнирования. То же самое можно сказать про случай, если в исходных данных была запись с неправильным кодом товара или просто с непроставленным кодом - сторнирование и возможность в PowerPlay делать запись данных в произвольные ячейки куба, а также создавать новые ячейки в кубе без полного перепроцессинга куба, решают эти проблемы. Спасибо, как происходит сторнирование (корректирующая запись) по изменившемуся чеку понятно. Но вот задача с distinct count: data quality assurance tool дал нам знать что определенная порция документов не валидна - нужно их удалить. Если предположить что для проведения инкрементальной подгрузки distinct count агрегата Cognos хранит все distinct значения отдельно, где-то в кубе, то как он определяет какие из distinct значений нужно корректировать? И ещё вопрос: какой интерфейс дает Cognos для сторнирования? API? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 17:58
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Виктор СаковичИ учтите, что нормализация не всегда хороша, если речь идёт о хранилищах данных Виктор, я всю жизнь думал, что хранилище денных должно быть нормализованным для обеспечения той самой единственной версии правды, о которой упомянул Моша. Интересно, ради чего, по-твоему, нужно в хранилищах жертвовать нормализацией? Уж не ради производительности же? JuriiЯ бы сказал, что вопрос не в том, какая СУБД используется для создания хранилища данных, а какое OLAP-средство работает поверх хранилища... Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей, и все будет работать с 5-секундным откликом на каждый запрос пользователя. Юрий, это для бедных. Есть задачи, которые не решаются средствами ОЛАП, а требуют реляционного хранилища. Вам это должно быть известно. 2 _zx: Присоединяюсь к вышесказанному - SQL Server ещё не готов как платформа для построения хранилищ данных. Недостаточно соответствующих фич. Существуют СУБД, способные работать на порядок быстрее на тех же вычислительных мощностях. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 18:09
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Константин Лисянский Виктор СаковичИ учтите, что нормализация не всегда хороша, если речь идёт о хранилищах данных Виктор, я всю жизнь думал, что хранилище денных должно быть нормализованным для обеспечения той самой единственной версии правды, о которой упомянул Моша. Интересно, ради чего, по-твоему, нужно в хранилищах жертвовать нормализацией? Уж не ради производительности же? JuriiЯ бы сказал, что вопрос не в том, какая СУБД используется для создания хранилища данных, а какое OLAP-средство работает поверх хранилища... Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей, и все будет работать с 5-секундным откликом на каждый запрос пользователя. Юрий, это для бедных. Есть задачи, которые не решаются средствами ОЛАП, а требуют реляционного хранилища. Вам это должно быть известно. 2 _zx: Присоединяюсь к вышесказанному - SQL Server ещё не готов как платформа для построения хранилищ данных. Недостаточно соответствующих фич. Существуют СУБД, способные работать на порядок быстрее на тех же вычислительных мощностях. С уважением, Константин Лисянский http://lissianski.narod.ru А что за СУБД Вы имеете в виду? Кроме Oracle 9i. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 18:10
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Например, СУБД Teradata. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 18:24
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
судя по этой статье: http://www.citforum.ru/database/kbd98/glava5.shtml к Teradata Вы имеете непосредственное отношение, наверное внедряете:) что не может не влиять на Вашу объективность:) в нете как-то не густо информации об этой СУБД, у Вас нет ссылки на ее поставщика? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 18:26
|
|||
|---|---|---|---|
DWH в MS SQL Server |
|||
|
#18+
Костя, я с тобой спорить не хочу (но если ты настаиваешь, то проблем никаких нет, я готов в деталях, так сказать :-)). НИКТО ЕЩЕ НЕ СДЕЛАЛ СУБД, которорая работает на платформе Microsoft быстрее, чем MS SQL. Я не понимаю, о чем тут сыр-бор завелся. Зачем создавать проблему из ничего? Я навскидку могу назвать пять компаний в Москве, у которых обычный Navision Attain с его совершенно тупой схемой данных (кто сталкивался, тот знает) дорос до 200 гигабайт. И ничего, живет себе и не пыхтит, притом что вся обработка в Attain фактически производится на клиенте. А вы разводите философию "будет хранилище работать, не будет хранилище работать". Главное - свое хранилище спроектируйте с умом, и тогда distinct count даст вам гарантированный ответ за те же 5 секунд. Просто придется потратить на железо на 2000$, а чуть поболее. А потом вам Юрий правильно сказал - купите хорошего клиента и радуйтесь удовольствиям жизни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2005, 18:29
|
|||
|---|---|---|---|
|
|||
DWH в MS SQL Server |
|||
|
#18+
Jurii Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей Юра, Вы когда сказки рассказываете, то не забывайте сначала в шпаргалку по физическим ограничениям Access и DBF поглядеть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=49&mobile=1&tid=1870779]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
61ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 262ms |
| total: | 428ms |
| 0 / 0 |
