Комментарии 44
Ради интереса, приведите пожалуйста параметры железа?
Для кубов под Analysis Services серьезного железа не надо. Я сейчас в отпуске и параметры сервера точно не скажу. Однако, пилотный проект разворачивали на клиентской машине они уже вертелись нормально. То же могу сказать и про AspxPivotGrid, он тоже неприхотлив (его правда настраивать посложнее, чтобы он работал шустро, в частности сортировку по умолчанию отключать).
Oracle стоит на 64 процессорном сервере, но производительность машин связанна не с этой задачей. В компании где я работаю все железо довольно мощное и обновляется раз в 3 года, это политика компании.
Oracle стоит на 64 процессорном сервере, но производительность машин связанна не с этой задачей. В компании где я работаю все железо довольно мощное и обновляется раз в 3 года, это политика компании.
Копаем сейчас похожую проблему, но на OpenSource стеке. Показы рекламы на площадках, доходы, правообладатели и т.д. Объем данных достаточно большой, чтобы в лоб из сырых данных отчет считался сутки. Рассматривали: Google BigQuery (вкусно, быстро, но дорого и нет OFFSET в синтаксисе чревато санкциями), Impala (чуть-чуть не дотянула по необходимому функционалу, чего-то там с группировками не хватало), решения на базе Hadoop (собственно, до тестов не добрались из-за проблем с развертыванием — возможно, решаемых — но по слухам далеко не real-time). Пока остановились на MySQL на схеме предварительных агрегатов по основным фильтрам плюс хранение в одной строке за месяц 31 колонки значений за день.
Ждём статью.
Очень рекомендую Analysis Services. Соберите куб и просто к нему через Excel подключитесь, посмотрите как работать будет.
Было бы интересно, если бы не задача обойтись без покупки дополнительного софта. Разрабатываемый функционал бесплатен, бюджет на проект по принципу «а не завалялся ли где-то еще один старый сервер?». Ну и немножко лень рыться в 5 гайдах по покупке SQL Server.
Пробовали HP Vertica вместо MySQL? Если «предварительные агрегаты» полезны не только для расчёта, это может быть выгодно.
Отдельно, сколько у вас данных или что у вас с алгоритмами, что подсчёт сутки? Агрегаты/словари в память не помещаются, считаете на каком-нибудь супер-быстром питоне, или алгоритм подсчёта нелинейный и немасштабируемый?
Отдельно, сколько у вас данных или что у вас с алгоритмами, что подсчёт сутки? Агрегаты/словари в память не помещаются, считаете на каком-нибудь супер-быстром питоне, или алгоритм подсчёта нелинейный и немасштабируемый?
Просто соберите куб. Это OLAP там всё по другому если вкратце. Главное — это построить факты и измерения по схеме звезда, без снежинок. Можно вьюхи сделать, чтобы как звезда были. Куб в процессе построения сам всё разобьёт на агрегаты и фактически будет хранить уже готовые значения (OLAP). 1 день на данный момент строиться 7 минут. Но построение идёт в отдельной транзакции. Т.е. работать с кубом пользователь может постоянно, просто с каким-то интервалом в нём формируются новые данные. Т.е. отставание от реальных данных будет около часа. В задачи которую я решал отставание могло быть 1-2 дня, т.к. просрочка по кредиту не сразу начисляется, пока там разберутся — точно клиент не заплатил или технический сбой какой-то дня 3 проходит.
Если нужно в реальном времени — это ROLAP. Так тоже можно, но это уже отдельный разговор.
Расскажите нам, как масштабируется создание/обновление куба.
Обновление данных — партиции делаются.
Изменение структуры — тут перестроить надо будет. Поэтому для куба делается витрина в базе (набор таблиц под куб, с максимально близкой структурой).
Изменение структуры — тут перестроить надо будет. Поэтому для куба делается витрина в базе (набор таблиц под куб, с максимально близкой структурой).
Не поделитесь ссылкой на то, как научить Analysis Services обрабатывать разные партиции для одного куба на разных серверах (не хранить, а обрабатывать)?
Не совсем понял вопрос. На вход партиции подается селект. А вот база, откуда селект, может стоять на нескольких серверах. А у Вас тормозит обработка партиций?
В свое время тормозила. Логика расчета значения может быть иногда весьма сложной, и выгодно ее параллелить. А еще бывают распределенные входные данные.
Там 2 места где расчет ведется — часть рассчитывается в базе до заливки в куб, часть в самом кубе. Надо смотреть расчет, это уже вопрос оптимизации. Я стараюсь всё рассчитать в витрине в базе данных, а уже оттуда забираю всё в куб. Та же история с распределенными данными, попытаться собрать всё в одну витрину. Хотя проект куба весь в xml, отсюда кое-что можно в нем менять на лету.
Ну то есть давайте переложим работу на сервер БД, а сам OLAP пусть отдыхает. Ну предположим. А нагрузка в СУБД как масштабируется?
Я не совсем понимаю, что и почему у Вас не получается. Всё зависит от задачи которую Вы решаете.
Интересный вариант, обязательно попробую.
Данные: 6 млн единиц контента, сотня площадок, сотня правообладателей, итого 20 млн событий за сутки. Запросы в целом достаточно простые
Проблема в чтении с диска овер-дофига-данных при построении результата по неполным месяцам с последующей группировкой по месяцам. Так что копали в сторону работающих из коробки агрегатов и уменьшения чтений с диска.
Данные: 6 млн единиц контента, сотня площадок, сотня правообладателей, итого 20 млн событий за сутки. Запросы в целом достаточно простые
SELECT MONTH(date) as dt, SUM(income) as s, content_id, rightholder_id, platform_id FROM tbl WHERE date BETWEEN '15-08-2014' AND '15-09-2014' [AND platform_id = ...] [AND rightholder_id = ...] [AND content_id = ...] GROUP BY dt, content_id, rightholder_id, platform_id ORDER BY s LIMIT 10 OFFSET 1000;
Проблема в чтении с диска овер-дофига-данных при построении результата по неполным месяцам с последующей группировкой по месяцам. Так что копали в сторону работающих из коробки агрегатов и уменьшения чтений с диска.
Если нужные агрегаты помещаются в терабайт (ну или несколько терабайт по разным кластерам), возьмите вертику — она решит ваши проблемы — там действительно быстро (секунды на сотни гигабайт исходных данных, засчёт колонок и сжатия) работают запросы даже при автоматически построенных проекциях. БД очень крутая, для аналитики из бесплатных (да и платных, $/Tb) — лучшая.
Ну и оффсеты зло — лучше кешировать результаты больших запросов без оффсетов и выдавать частями.
Если вам особо не требуются группировки, а просто надо хранить и отдавать куб — подойдёт любой распределённый key-value. Отдельно, есть эластик, у некоторых перемалывает терабайты данных, может, вам поможет.
Кстати, мне всё ещё непонятно, как у вас расчёт считается сутки — это какие-то запредельные числа для 600кк событий без длинных строк и большого числа полей.
Ну и оффсеты зло — лучше кешировать результаты больших запросов без оффсетов и выдавать частями.
Если вам особо не требуются группировки, а просто надо хранить и отдавать куб — подойдёт любой распределённый key-value. Отдельно, есть эластик, у некоторых перемалывает терабайты данных, может, вам поможет.
Кстати, мне всё ещё непонятно, как у вас расчёт считается сутки — это какие-то запредельные числа для 600кк событий без длинных строк и большого числа полей.
Посмотрите в сторону Kaffka + Cassandra, хорошо показывает себя (пример — gumgum.com).
Ну ничего себе! Сделали куб (стандартными средствами) и отобразили (взяв готовое решение).
Да еще и и оркаловый провайдер неумеючи использовали (можно вообще не трогать реестр и вообще ничего не ставить (xcopy оракловый нативный провайдер уже давно умеет)).
Лично я жду продолжения в виде статей «как я записал файл на диск»…
Да еще и и оркаловый провайдер неумеючи использовали (можно вообще не трогать реестр и вообще ничего не ставить (xcopy оракловый нативный провайдер уже давно умеет)).
Лично я жду продолжения в виде статей «как я записал файл на диск»…
Все же намного лучше по сравнению с тем, какой статья была до переделки.
=
Про xcopy я тоже много чего знаю. А в реестре лезли не затем чтобы править, а чтобы tnsnames 2-жды не писать. В дровах для оракла я просто хотел акцент сделать на обязательность перезагрузки. Можно и без неё, только возни побольше.
Как отобразить 350 миллионов строк из базы данных на Web-форме
Никак, потому что это не нужно. Человек не может работать с таким объемом информации. BI-системы как раз ориентируются на то, чтобы показывать человеку только необходимое.
Ну а дальше, как уже сказано выше, решение типовое — DWH, куб, BI-компонент на интерфейсе.
Это мне говорили и не раз. Но я сделал и они работают. Понятно что возможно им это не понадобится, но тут дело принципа и желание заказчика.
Работают в каких условиях? Какой канал между сервером и клиентом?
И все-таки, присоединяюсь к вопросу, неужели их не удовлетворила бы простая постраничная навигация, можно даже и на аяксе для комфорта? Может виной всему просто типичное незнание заказчика? Не хотел бы наполучать минусов, что так практикуется на Хабре, ибо он не предусматривает какое-либо обучение новичков… А-то прямо никто новичками не был… И все же.
Советую попробовать, благо триал версия ASPXPivotGrid есть, Analysis Services достать тоже не сложно. Я поэтому и написал, что действительно очень неплохой выход при малых затратах получился.
Почему не Qlikview, например?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как отобразить 350 миллионов строк из базы данных на Web-форме