Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
У кого-нибудь есть такой опыт? Данные думаю перекачивать из куба в таблицу, предположительно будет несколько миллиардов записей, канал очень широкий - это либо по 100 мегабитной сетке либо вообще на одном компе. Мне интересен порядок цифр, возможно это за несколько часов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2004, 22:43 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Зависит не только от канала, но и чем и куда будете перекачивать. Идеальный вариант, к которому можно стремиться это тот, что время будет равно 1000000000*длина записи/пропускная способность канала (если я ничего не путаю). Но в реальности время будет всегда больше, так как все системы накладывают свои потери. Как то раз я экпериментировал с перекачками одного и того же массива используя разные средства (естественно на той же самой сети и даже компьютере) и получил разницу в скорости в 4 раза. Так что... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2004, 23:13 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Интерено на какой задаче такой объем. Похожие объемы мы получили в GSM-логах, но там исторические данные не по сети носили, а съемными дисками перенесли. Вообще говоря если это MS AS очень сильно зависит от сделанной оптимизации. На неоптизированном решении вообще может быть крах. Кривые запросы уходящие в SQL-сервер в принципе будут приводить к time-out уже на 20 млн. записей. Если кривые. А так время загрузки примерно такое. Microsoft (Моша меня поправит если я не прав) хвалился скоростью загрузки 100 млн. записей в час и закачкой с такой скоростью 5 млрд. записей. На моей практике скорость очень зависит от оптимизаций и уровня "кривизны" решения. От 60 млн. в час до 1 млн. час. Все утыкается не столько в сеть, сколько в SQL-запрос (если куб конечно не детский). Отмечу, что если хранилище уже кривое, то можно почти застрелиться, т.к. индекс поверх 50 млн. записей на хорошом сервере может строиться несколько часов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2004, 00:27 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Владимир Иванов Что значит 100 миллионов записей в час? На каком железе? С каким объемом памяти, на какой сетке? Я как-то тут уже писал про то что на простой персоналке с МС АС делал загрузку и построение куба с Distinct Count на 40 миллионов записей. И это без оптимизаций. Сама загрузка длилась несколько минут, а час потом построение куба. (Сейчас уже не помню точнее, давно это было, неск. лет назад) В SQL запрос все тоже упирается, но здесь то вопрос задавался (как я понял) о скорости закачки, при условии что обработка SQL завершена. Также, очень сомнительно утверждение, что индекс на 50 миллионов на современном сервере будет строиться часами. Хотя, может быть зависит от того что это за индекс, но все равно сомнительно. Постараюсь проверить - напишу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2004, 00:40 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2Birkhoff. Надеюсь мы обсуждаем промышленные решения, а не куб собранный студентом на коленке. В первом случае очень сильная зависимость от дизайна решения. Индекс в Лукойле у нас строился по консолидированному хранилищу над Nordis примерно 20 минут. Там было всего 30 млн. записей и приличный сервер. Правда потом все 30 млн. фактов MS AS "хапнул" за 3 минуты. Это результат в конкретном практическом случае, а не в абстрактном тесте. Тест Microsoft на 5 млрд. фактов был опубликован ранее на microsoft.com. Поищите. Любопытно, что с microsoft.com сняли часть перезентаций, где была описана архитектура развертывания для такого решения. Но сам тест вроде еще лежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2004, 01:10 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Владимир Иванов Два дня назад наткнулся на ваш топик про GSM-логи. У меня аналогичная задача. Есть список пользователей - 200 миллионов, которые ходят в инете по разным разделам. Разделов немного, на данный момент 24. В любом случае их будет не более 1000. Ходят по одному разу, по 2, по три и так далее. Так вот есть отчет в котором нужно вывести число пользователей посетивших разделы по 1 разу, по 2 раза, по 3 и т.п. Если использовать динамический запрос, то он примерно в 3 - 10 раз медленнее SQL. Построить особый куб, в котором это уже было бы посчитано, не удалось и никто ничего аналогичного не подсказал, возможно такого нет. Недавно пришла в голову идея, построить куб на основе другого куба, который считает количество визитов, в качестве фактов указать запрос из первого куба, в котором вытащить куб целиком. Тогда можно будет меру визиты использовать как измерение. Итак пользователей 200 миллионов, секций (разделов) несколько десятков-сотен, листьями дат являются дни. Если все перемножить то получится громадная цифра, но спасает то что далеко не каждый пользователь ежедневно ходит по всем секциям, так что получится не такое большое увеличение. Полагаю, что не более нескольких миллиардов. Кроме того давность данных более месяца-кватрала уже не актуально и можно вытаскивать только последний квартал. Можно конечно попробовать вытащить весь этот список, но на данный момент у меня пользователей полмиллиона. Как считаете, это не авантюрное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2004, 12:09 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Попробуйте сначала метод, который предложил Моша. Путь, которым пошел я (создание хитрого DWH) сложнее и дороже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2004, 22:14 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Если использовать динамический запрос, то он примерно в 3 - 10 раз медленнее SQL А чем Вас SQL не устраивает? Мы тут, вроде бы, выяснили, что на таких задачах SQL не хуже работает. Так зачем же лишнюю работу делать в виде создания кубов? За ними, ведь, ухаживать придётся. Кстати, а у Вас задача анализа внутри дня не стоит? Например, на предмет оптимизации показа рекламных банеров в разное время суток в зависимости от того, как и кем посещается сайт? Интересно, если добавить такое измерение в этот куб, он выживет? Владимир ИвановПуть, которым пошел я (создание хитрого DWH) сложнее и дороже. А что за "хитрое DWH"? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 01:02 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
У Иванова все сплошь хитрое и оптимированное.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 01:55 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Константин Лисянский Сейчас задача решается с помощью SQL, именно это и привело к тому, что решили от него отказаться, так как не справляется. 2 Владимир Иванов А что за метод предложил Моша? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 10:41 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Сейчас задача решается с помощью SQL, именно это и привело к тому, что решили от него отказаться, так как не справляется. А можете SQL привести? А что значит "не справляется"? Это MS SQL? А железо какое? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 10:46 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Лисянский База конечно не совсем оптимально спроектирована. Я пробовал оптимальную структуру, время отклика увеличилось от 2 до 4 раз, в зависимости от отчета, но это далеко не 5 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 10:58 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
To Old Nick: Сейчас задача решается с помощью SQL, именно это и привело к тому, что решили от него отказаться, так как не справляется. А что значит не справляется? Один из вариантов, к которому я пришел в ходе общения с представителями российской компании - владельца популярной поисковой системы, так это вычислять все на уровне РСУБД, и записывать результаты в ячейки куба. В OLAP-сервере Cognos PowerPlay это называется External Rollup. Например, вычисляете c помощью SQL следующее: Раздел1, День1, зашли 1 раз, ЧислоПосетителей1 Раздел1, День1, зашли 2 раза, ЧислоПосетителей2 Раздел1, День2, зашли 1 раз, ЧислоПосетителей3 Раздел1, День1, зашли 2 раза, ЧислоПосетителей4 И этот массив можно закачать в куб... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 10:59 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Этот массив сначала надо получить. Это не мыслимо для всех пересечений всех измерений со всеми уровнями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 11:01 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
База конечно не совсем оптимально спроектирована. Я пробовал оптимальную структуру, время отклика увеличилось от 2 до 4 раз, в зависимости от отчета, но это далеко не 5 сек. Не пожалейте времени - опишите, как она спроектирована и SQL, который испеользуется для отчёта. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 11:07 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Использовал NonEmptyCrossjoin(Customers.CustomerKey.Members) Результат потрясающий, превзошел все ожидания. Самый долгий отклик 20 сек, самый быстрый 1 сек. У меня в фактах действительно довольно много пользователей, у которых количество посещений null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 11:34 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
Огромное спасибо Моше за подсказку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 11:35 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Владимир Иванов Надеюсь мы обсуждаем промышленные решения, а не куб собранный студентом на коленке. Я вообще то считал, что "промышленные решения", базирующиеся на дорогом железе отличаются от "студенческих" не тем, что работают заведомо медленнее "студенческих", как следует из вашего поста, а в основном тем, что обладают в сравнении со "студенческими" повышенной надежностью, производительностью, масштабируемостью и проч. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 22:09 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
На мой взгляд промышленные решения не должны в первую очередь быть масштабируемы, надежны, производительны и пр. Промышленные решения не плод академизма, а ИС находящие в реальных эксплуатациях на предприятиях. Такие решения должны в первую очередь отвечать бизнес-потребностям пользователей. В первую очередь это бизнес-функции. Чем больше бизнес-функций в системе тем сложнее подерживать масштабируемость, надежность и пр. В идеале (у студента) конечно просто, но на практике где бизнес-требования противоречивы и изменчивы это на 100% не достижимо. Большое количество разных бизнес-функций утяжеляют дизайн и меняют его поведение в сравнение с простыми моделями и прототипами. Я всячески привествую правильную архитектуру. Но идеальная архитектура и реальное выполнение и реализация бизнес-задач довольно разные вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2004, 03:54 |
|
||
|
Сколько времени будет перекачиваться миллиард записей?
|
|||
|---|---|---|---|
|
#18+
2 Владимир Иванов В моем примере это была не академическая задача - посмотреть, выдержит или не выдержит сервер, а такова была постановка задачи. Но у них не использовалось дорогого железа, в качестве сервера работала обычная персоналка. А то, что загружалось 40 миллионов в distinct count, просто побочный эффект этой постановки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2004, 12:29 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32588048&tid=1872459]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 408ms |

| 0 / 0 |
