Здравствуйте, Paulmay, Вы писали:
P>Для тех, кто в танке, объясняю: добавление одного оператора в графической среде займет в среднем около 2-5 секунд (надо как минимум найти курсором этот оператор и перетащить его обратно). Это время будет постоянно увеличиваться из-за износа мышки, у которой не больше пяти кнопок. В то же время набор этого оператора на клавиатуре займет не более секунды, кроме того, у клавиатуры больше срок работы, так как у нее больше клавиш. Таким образом, скорость работы в графической среде только понизится.
Никого не интересует программирование в операторах.
Я тут много ссылок давал: Re[4]: Исправлен "рисунок"
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Мне вообще-то плевать как именно это сделано у вас. Я спросил — вы по быстродейтсвию сравнивать свои алгоритмы в вашей системе с оными в Cache пробовали, прежде чем воротить свое аналогичное?
_JK>>конкретно с кэш не пробовали, скажу честно, уверен что кэш будет медленней, ибо у нас скорость расчета равна скорости чтения данных с носителя. т.е если для рассчета необходимо зачитать 1гб данных, то рассчет закончится с той же скоростью как и закончится копирование этих данных в /dev/null.
V>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
V>Если ты обратил внимание, то я упирал больше на middle-ware, а это немного не то, что ты озвучил. Это — наработанные способы решения типовых мелочей. Магазин из них строится, хотя сам может быть блоком, разумеется. Насчет "залить в базу" — это не для красного словца, надеюсь понимаешь? Большинство классов приложений так или иначе обрабатывают данные, и базы -это пока безальтернативный способ надежного их хранения и более-менее быстрой массовой обработки. (свой пример с Ораклом и вашим императивным алгоритмом не приводи, насколько я понял, у вас там всего несколько отчетов так строятся, для сравнени — в средней ERP разновидностей отчетов более тысячи). И тем не менее, тонны рукописной работы до сих пор в ORM наблюдается. Почти в любом топике здесь, где кто-либо показывает пример удачной кодогенерации по шаблонам, по базам, автор срывает самые бурные апплодисменты зала. Поневоле призадумаешься, как же так выходит-то, что самая востребованная вещь (судя по реакции) как-то сбоку, неинтегрированно, жутко узкоспециализированно и вообще, сто раз подумаешь, а стоит ли связываться.
не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
отчетов у нас тысячи а могут быть и миллионы, мы из не создаем они абсолютно динамические юзер их сам строит.
V>>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
_JK>именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах".
_JK> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
_JK>>именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
V>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах".
читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
_JK>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента.
если очень интересно — 26.
Здравствуйте, BlackTigerAP, Вы писали:
BTA>Твой вопрос, вообще, даже не технического плана, а, скорее, филосовского. Наш мир не состоит из блоков, хотя это и может так показаться. Наш мир фрактальный. А мы — порождение нашего мира со всеми вытекающими. Если бы мир был блочным, то всё кругом состояло бы из кубов и квадратов, как самых приспособленных для сборки. Никаких закругленностей и угловатостей, за исключением прямых углов. Ан нет, куда не посмотри — фракталы, самый неблочный тип, самый порядочно-беспорядочный. Вроде бы посмотришь — вот он блок! А присмотришься по-ближе — ё моё... Короче, фракталы рулят этим миром, а не блоки. Любая попытка унификации и блокоизации этого мира обречена на провал изначально.
Ты умудрился однобоко посмотреть на правила построения мира. Рулит по-прежнему декомпозиция, просто эта декомпозиция бывает разного характера. Бывает блочного (структурного), а бывает функционального. Почему законы построения любых организмов записаны всего в одной клетке ДНК?
V>>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах". _JK>читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
Позволь усомнится, ok? Пока ты не приведешь, как именно вы это делали в ORACLE, не поверю. Плоские таблицы большого размера ORACLE читает не медленнее, чем ты бы читал бинарные файлы (создай динамический курсор, пропиши хинты для однонаправленного чтения без блокировок, и наслаждайся). Речь о том, как и где вы организовали собственно вычисления, обычно тормоза в этом кроются, а не в скорости зачитки плоских таблиц из ORACLE. Кстати, когда ваша OLAP система будет периодически пересчитывать OLTP-данные и менять эти ваши "плоские файлы", то за счет фрагментации диска при нормальной нагрузке на сервак твое чтение бинарных файлов через OS будет серьезно "сливать" зачитке плоских таблиц из ORCALE, если речь действительно идет о гигах данных. Тема отдельная и весьма серьезная.
_JK>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента. _JK>если очень интересно — 26.
Вот оставил твой выпад из предыдущего поста, чтобы он был на одной странице с цифрой 26... в надзидание.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах". _JK>>читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
V>Позволь усомнится, ok? Пока ты не приведешь, как именно вы это делали в ORACLE, не поверю. Плоские таблицы большого размера ORACLE читает не медленнее, чем ты бы читал бинарные файлы (создай динамический курсор, пропиши хинты для однонаправленного чтения без блокировок, и наслаждайся). Речь о том, как и где вы организовали собственно вычисления, обычно тормоза в этом кроются, а не в скорости зачитки плоских таблиц из ORACLE. Кстати, когда ваша OLAP система будет периодически пересчитывать OLTP-данные и менять эти ваши "плоские файлы", то за счет фрагментации диска при нормальной нагрузке на сервак твое чтение бинарных файлов через OS будет серьезно "сливать" зачитке плоских таблиц из ORCALE, если речь действительно идет о гигах данных. Тема отдельная и весьма серьезная.
полный бред.., во первых на одинаковом железе НИКОГДА ORACLE не прочитает большую плоскую таблицу быстрее чем её-же грамотно прочитать из плоского файла. не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
_JK>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
_JK>>>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>>>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента. _JK>>если очень интересно — 26.
V>Вот оставил твой выпад из предыдущего поста, чтобы он был на одной странице с цифрой 26... в надзидание.
короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
Здравствуйте, _JoKe_, Вы писали:
_JK>не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
Cами по себе фильтруются?
_JK>>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
Ну ты же отослал меня к OLAP, правильно? Назначение OLAP — это хранение превычесленных данных по интересующим срезам с целью мгновенного получения отчетов. Неотъемлимой частью OLAP — является еще куча индексов в актуальном (по статистике) состоянии. Нафига читать гиг данных, если можно воспользоваться индексами и зачитать пару кил всего (при вычислениях с фильтрацией). Самописную систему имеет смысл писать только в том случае, если не нужны услуги базы данных, а именно: индексация, поддержание бинарных страниц в оптимальном порядке, адекватная по времени фильтрация из очень больших наборов.
Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей.
_JK>короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
Как раз-таки несколько наоборот. Просто я отношусь ко всему этому очевидно "легче" тебя, ибо скоро лет 10 как впервые с этой темой столкнулся. А ты еще весь в своей важности, ИМХО (судя по тону предыдущих писаем). Ну так будет озвучена задача которая валит Оракл, или мы только заочно круты? Кстати, не забудь рассказать, как вы данные в своем самописном ОЛАПе обновляете.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
_JK>>не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
V>Cами по себе фильтруются?
_JK>>>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>>>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>>как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
V>Ну ты же отослал меня к OLAP, правильно? Назначение OLAP — это хранение превычесленных данных по интересующим срезам с целью мгновенного получения отчетов. Неотъемлимой частью OLAP — является еще куча индексов в актуальном (по статистике) состоянии. Нафига читать гиг данных, если можно воспользоваться индексами и зачитать пару кил всего (при вычислениях с фильтрацией). Самописную систему имеет смысл писать только в том случае, если не нужны услуги базы данных, а именно: индексация, поддержание бинарных страниц в оптимальном порядке, адекватная по времени фильтрация из очень больших наборов.
просто балдею какая умная мысль V>зачитать пару кил всего (при вычислениях с фильтрацией).
скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет.
V>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP?
я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг.
по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
V>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей.
очень пафосно....
_JK>>короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
V>Как раз-таки несколько наоборот. Просто я отношусь ко всему этому очевидно "легче" тебя, ибо скоро лет 10 как впервые с этой темой столкнулся. А ты еще весь в своей важности, ИМХО (судя по тону предыдущих писаем). Ну так будет озвучена задача которая валит Оракл, или мы только заочно круты? Кстати, не забудь рассказать, как вы данные в своем самописном ОЛАПе обновляете.
ну ну, прям похоже все наоборот.... ты столкнулся а наша контора в этом бизнесе уже 15 лет, я в ней работаю уже 6, и важность мне не к чему...
если ты думаешь что все так просто — привожу факты
наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
ЗЫ: можешь не отвечать, смысла в разговоре не вижу, больше доказывать ничего не хочу, вести разговор в этой ветке прекращаю.
_JK>скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
Например, в доке по MS SQL очень даже подробно описано, как он хранит данные, как индексы, и как по индексам выбирает данные. Дока настолько подробная, что вплоть до бинарных подрбностей описано, как хранятся и обрабатываются данные.
_JK>я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет.
Трудно понять, что ты имел ввиду, но если ты про индексы, то это как бы основы.
V>>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? _JK>я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг. _JK>по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
_JK>данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
Но как это возможно? Тогда надо на ковер тех, кто составлял вашу схему данных (к технолдогии этот вопрос уже никакого отношения не имеет). У меня при обновлении пересчитывались данные только за день, затем из уже пересчитанных данных за день пересчитывались месяц, а из месячных данных — год. Да, пришлось немного попотеть и ввести кое-где избыточность (т.н. "исторические" или "архивные" зеркала данных), чтобы при обновлениях данных не надо было пересчитывать за год целиком все транзакции. А пересчет итогов из промежуточных... это смешно, ибо в месяце не более 30 дней (а не сотен тысяч транзакций, понимаешь о чем речь?), а в году не более 12 месяцев (а не миллионы транзакций). А пространств тоже не многие тысячи, дай бог десятки в самой навороченной системе.
V>>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей. _JK>очень пафосно....
А сам почитай, что ты там написал. Ты же признал, по-сути, что ваша система обладает св-вами решения общего плана (раз вы динамически отчеты строите), и при этом круче ОРАКЛа на несколько порядков.
_JK>если ты думаешь что все так просто — привожу факты _JK>наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
Замечательно. Тогда почему вы до сих пор не побили ОРАКЛ, и всякое другое г-но?
У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
_JK>>скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
V>Например, в доке по MS SQL очень даже подробно описано, как он хранит данные, как индексы, и как по индексам выбирает данные. Дока настолько подробная, что вплоть до бинарных подрбностей описано, как хранятся и обрабатываются данные. _JK>>я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет. V>Трудно понять, что ты имел ввиду, но если ты про индексы, то это как бы основы.
хорошо — для тех кто в танке....
допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос
хочу все числа больше 10.
ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок
теперь тебе надо все четные числа
новый индекс — все ок.
а теперь числа оканчивающиеся на 0,
а теперь те из которых можно извлеч корень
а теперь только простые
... и т.д.
сколько ты индексов строить будешь?
(числа это только пример чтобы ты понял что невозможно все индексы построить иногда надо и все данные просмотреть чтобы фильтр наложить)
V>>>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? _JK>>я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг. _JK>>по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>>>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
_JK>>данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
V>Но как это возможно? Тогда надо на ковер тех, кто составлял вашу схему данных (к технолдогии этот вопрос уже никакого отношения не имеет). У меня при обновлении пересчитывались данные только за день, затем из уже пересчитанных данных за день пересчитывались месяц, а из месячных данных — год. Да, пришлось немного попотеть и ввести кое-где избыточность (т.н. "исторические" или "архивные" зеркала данных), чтобы при обновлениях данных не надо было пересчитывать за год целиком все транзакции. А пересчет итогов из промежуточных... это смешно, ибо в месяце не более 30 дней (а не сотен тысяч транзакций, понимаешь о чем речь?), а в году не более 12 месяцев (а не миллионы транзакций). А пространств тоже не многие тысячи, дай бог десятки в самой навороченной системе.
не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой...
в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением.
представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
V>>>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей. _JK>>очень пафосно....
V>А сам почитай, что ты там написал. Ты же признал, по-сути, что ваша система обладает св-вами решения общего плана (раз вы динамически отчеты строите), и при этом круче ОРАКЛа на несколько порядков.
есть большая разница — оракл это база данных
а наша система это analytical processing в нее нельзя запросто данные добавить чтобы они тут же в расчетах начали учавствовать....
OLTP и OLAP немного разные вещи, и решают разные задачи.
ты вспомни с чего разговор начинался я сказал что правильное специализированное решение эффективней общего. вот и все.
наша система заточенная под обработку определенных данных для решения определенных задач, бьет по всем позициям оракл и любые другие продукты предназначенные для обработки абстактных данных
_JK>>если ты думаешь что все так просто — привожу факты _JK>>наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
V>Замечательно. Тогда почему вы до сих пор не побили ОРАКЛ, и всякое другое г-но?
давно уже в своей нише рынка побили и оракл и другое г-но., а насчет большего охвата это не ко мне существует еще маркетинг лоббирование и много чего еще чем я и остальная команда разработчиков не занимается.
вопрос из той же серии что и
-почему есть юникс и виндовс и один не бьет другого
-.net и java
-Intel и AMD
-pc и mac
-СШA & others
и т.д.
V>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь.
ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
_JK>допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос _JK>хочу все числа больше 10. _JK>ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок _JK>теперь тебе надо все четные числа _JK>новый индекс — все ок. _JK>а теперь числа оканчивающиеся на 0, _JK>а теперь те из которых можно извлеч корень _JK>а теперь только простые _JK>... и т.д. _JK>сколько ты индексов строить будешь?
Это для бизнес-системы такие параметры запросов?
Если уж на то пошло, и дейтсвительно по этим признакам часто выполняются сложные запросы (а только профайлер даст ответ на этот вопрос), то при положительном ответе профайлера я не просто индекс сделаю, если формула индекса сложная (например — "простые числа"), я сделаю избыточные битовые поля в OLAP, по одному на каждый интересующий сложный признак. Ну а по ним — индекс.
_JK>не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой... _JK>в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением. _JK>представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
_JK>есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
Странно, насчет "задаваемым логическим выражением". А обычная модель раздачи списка грантов пользователям и группам? Ведь эта модель не спроста так популярна — она естественным образом ложится на реляционную базу и легко участвует в запросах (у меня так было). Т.е., хоть юзверей и сотни было, но уникальных наборов прав совсем не много (просекаешь?). Поэтому вовсе не накладно было все срезы хранить/пересчитывать, тем более что система прав участвует обычно в менее половины отчетов (т.е. для другой половины права действуют целиком на отчет, и принимается решение — можно показать такой-то отчет целиком, или нет). Даже если у вас все так специфично, хочешь сказать, что набор прав уникален для каждого юзера из тысячи? Как минимум это немного странно, я могу предположить такое только если у фирмы-клиента много "серого" бизнеса и есть потребность в сокрытии информации для соседствующих направлений собственной деятельности, очевидно вам приходится делить права не только горизонтально, но и вертикально, т.е. делить данные из каждой таблицы буквально построчно, так? Сталкивался я однажды с подобным. Встроенными ср-вами безопасности или аналогичными эмулируемыми такую задачу эффективно не решить, есть такое. Более-менее эффективно решается построчное разделение данных, если удасться все существующие права представить в виде однонаправленной иерархии и жестко пронумеровать их.
V>>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь. _JK>ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
Дык, давно бросил. Если бы жил в большом городе, наверняка бы постоянно находились бы весьма уникальные и специфичные клиенты. А так приходится сейчас рыночные коробочные продукты клепать... Самый что ни на есть ширпотреб. При удачном раскладе уехать можно очень далеко.
_JK>>допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос _JK>>хочу все числа больше 10. _JK>>ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок _JK>>теперь тебе надо все четные числа _JK>>новый индекс — все ок. _JK>>а теперь числа оканчивающиеся на 0, _JK>>а теперь те из которых можно извлеч корень _JK>>а теперь только простые _JK>>... и т.д. _JK>>сколько ты индексов строить будешь? V>Это для бизнес-системы такие параметры запросов?
V>Если уж на то пошло, и дейтсвительно по этим признакам часто выполняются сложные запросы (а только профайлер даст ответ на этот вопрос), то при положительном ответе профайлера я не просто индекс сделаю, если формула индекса сложная (например — "простые числа"), я сделаю избыточные битовые поля в OLAP, по одному на каждый интересующий сложный признак. Ну а по ним — индекс.
не выкидывай мои слова я тебе написал ЭТО ПРИМЕР! для бизнес данных совсем другие запросы, просто ты не знаешь специфику поэтому они тебе ни о чем не скажут
так вот я тебе и говорю невозможно построить все индексы по всем запросам.
_JK>>не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой... _JK>>в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением. _JK>>представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
_JK>>есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
V>Странно, насчет "задаваемым логическим выражением". А обычная модель раздачи списка грантов пользователям и группам? Ведь эта модель не спроста так популярна — она естественным образом ложится на реляционную базу и легко участвует в запросах (у меня так было). Т.е., хоть юзверей и сотни было, но уникальных наборов прав совсем не много (просекаешь?). Поэтому вовсе не накладно было все срезы хранить/пересчитывать, тем более что система прав участвует обычно в менее половины отчетов (т.е. для другой половины права действуют целиком на отчет, и принимается решение — можно показать такой-то отчет целиком, или нет).
никого не волнует что, как и куда естественным образом ложится. заказчиков интерисует эффективное решение их проблем, и их не волнуют вопросы sql, срезов, моделей что и как в программе устроено.
я тебе про фому а ты мне про ерему....
я тебе говорю что делает заказчик и что ему надо...
я бы посмотрел что бы ты и кому продал, если бы тебе заказчик сказал мне нужен фильтр по данным на каждого юзера — у нас такой бизнес, а ты ему в ответ — "у вас бизнес не правильный вы роли введите у меня тогда система будет соответствовать моим представлениям об олап", да они тебя на ... пошлют.
пойми что есть и другие задачи кроме тех которые ты когда то решал.
V>Даже если у вас все так специфично, хочешь сказать, что набор прав уникален для каждого юзера из тысячи? Как минимум это немного странно, я могу предположить такое только если у фирмы-клиента много "серого" бизнеса и есть потребность в сокрытии информации для соседствующих направлений собственной деятельности, очевидно вам приходится делить права не только горизонтально, но и вертикально, т.е. делить данные из каждой таблицы буквально построчно, так?
я же тебе объясняю в олапе нет таблиц, ну нету у нас базы данных. данные специальным образом препарированы, нету и sql запросов. потому что V>Сталкивался я однажды с подобным. Встроенными ср-вами безопасности или аналогичными эмулируемыми такую задачу эффективно не решить, есть такое. Более-менее эффективно решается построчное разделение данных, если удасться все существующие права представить в виде однонаправленной иерархии и жестко пронумеровать их.
вот в этом месте ораклу очень тяжело.
и все таки не более-менее, а очень эффективно все это решается.
права есть на данные, на объекты, на действия. бизнес абсолютно нормальный. собирают данные и потом продают доступ в систему, в которой каждый юзер может анализировать данные из купленной им области. кроме того есть права на действия, на объекты, гранты на пользователей и на группы, много чего еще, некоторое из них тоже в расчетах учавствует, например скидки и т.п.
V>>>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь. _JK>>ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
V>Дык, давно бросил. Если бы жил в большом городе, наверняка бы постоянно находились бы весьма уникальные и специфичные клиенты. А так приходится сейчас рыночные коробочные продукты клепать... Самый что ни на есть ширпотреб. При удачном раскладе уехать можно очень далеко.
вот теперь становится понятно. клепая ширпотреб очень тяжело оценивать уникальные решения, а хочется получить собсвенно то что в начале топика предлагают сделать.
только для клепания ширпотреба это уже давно есть....
пошел на sourceforge кода набрал, кое как соплями скрепил, и дальше начинается самое интересное — втюхивание этого добра лохам, путем запудривания мозгов.
только после того как пузырь доткомов лопнул такой бизнес уже тяжело вести... лохов все меньше никто не хочет деньги на ветер выбрасывать.
_JK>вот теперь становится понятно. клепая ширпотреб очень тяжело оценивать уникальные решения, а хочется получить собсвенно то что в начале топика предлагают сделать.
Кстати, наконец вернулись к теме топика после обсуждения конкретно твоего случая. Разумеется, ср-ва автоматизации как класс имеют право на жизнь только при условии их многократного применения, т.е. для целей широкого потребления.
_JK>только для клепания ширпотреба это уже давно есть.... _JK>пошел на sourceforge кода набрал, кое как соплями скрепил, и дальше начинается самое интересное — втюхивание этого добра лохам, путем запудривания мозгов.
Это ты из головы вариант приводишь, очевидно. Решение задачи должно соответствовать условиям той самой задачи. Если решение соответсвует условию, то это не втюхивание, а вполне добросовестный бизнес. Кстати, у нас и спор-то начался от того. что ты считаешь, буд-то все задачи уникальны. Я наоборот считаю, что классов задач удивительно мало. Даже абсолютно разные задачи строятся из удивительно одинаковых блоков.
_JK>только после того как пузырь доткомов лопнул такой бизнес уже тяжело вести... лохов все меньше никто не хочет деньги на ветер выбрасывать.
Он лопнул не от плохого качества сайтов. Кстати, качество сайтов того времени до сих пор гораздо выше качества российских сайтов времени настоящего. Особенно это проявляется там, где приходится возвращаться и уточнять данные.
Так вот, доткомы лопнули от неготовности рынка, т.е. потребителей, этими доткомами пользоваться. Неожиданно выяснилось (ну надо же!!! ), что каждый отдельный чел регулярно посещает лишь очень ограниченный круг сайтов. От того в бизнесе доткомов теперь покупают не столько компании, сколько бренды, т.е. URL-и. Если кто и покупает компании, дык только лишь с целью покупки раскрученного URL-я.
К некачественному "лабанию" сайтов провал доткомов отношения не имеет. Да, многие непрограммисты выучили PHP, но ты просто не в курсе как там на западе делают сайты. Там десятки человек над одним сайтом работали, плюс жесточайший QA. Это только у нас сайты делаются 1-3-мя разработчиками, что сразу видно по качеству.
В общем, то, что задача решается легко (как это было на PHP), не говорит о том, что задача легкая. Просто эта задача может оказаться типовой и уже решенной и вылизанной многократно, от того легко повторяемой. Ведь эти самые "кухарки на PHP" именно этим и занимались — использовали готовые, вовсе не ими разработанные блоки. Вполне нормальное явление, особенно если эта "кухарка" как раз-таки является прикладным спецом не в программировании, а в той области, для обслуживания которых лепится сайт. Тут надо знать и понимать еще одну тонкость доткомов того времени: исполнителей подбирали конкретно под сайт, что немаловажно. Это у нас еще как-то очень статичный народ, и переход из фирмы в фирму — целое дело. Как побочный эффект — запросто могут уйти посреди проекта ибо разницы не делают.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Как вам задумка, а?
От:
Аноним
Дата:
29.01.07 16:10
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира. А>Просьба, высказаться "за" или "против". Ну и так просто мнения пишите. А>Итак по порядку:
А>Тип: объектно-ориентированная среда разработки А>Платформа: .NET А>Компилятор: встроенный C# А>Цель 1*: абстракция от кода на каком-либо языке А>Цель 2**: отсутствие ошибок компиляции А>Цель 3***: устранение многих логических ошибок, таких как разорванные связи А>Цель 4*: более быстрая разработка приложений А>Результат: исполняемый образ .NET
А>* достигается за счёт сбора программы не из исходного кода, а из предопределённых элементов А>часть элементов является элементами алгоритма (циклы, условия, вызов метода и т.п.), но другая (бОльшая) часть является более высокоуровневыми элементами, которые реализуют в себе несколько других того же или более низкого уровня.
А>** достигается за счёт того, что исходный код, который будет скомпилирован, пишется не программистом, а генерируется ядром среды на основе структуры программы, заданной программистом. А>понятно, что этот код всегда будет правильным.
А>*** перед компиляцией и генерацией кода, структура приложения, собранная программистом из преопределённых элементов, будет проверяться на валидность и на бессмысленость. А>поскольку среда является объектно-ориентированной, это значит, что в ней все элементы (класс, структура, метод, цикл и т.д.) в ядре представленны объектами. А>например, если мы имеем метод method1, в котором есть инструкция вызова метода method2, то инструкция передставлена объектом, имеющим ссылку на method2, т.о. если программист впоследствии изменит имя метода method2 на method13, то никакой ошибки компиляции не будет, т.к. в инструкции сидит ссылка и инструкция, когда генерирует код, берёт имя метода по ссылке и оно оказывается method13. А>это всего лишь один пример, хотя на самом деле такая схема построения программ имеет много других преимуществ.
А>Самое главное — не надо будет тратить время на строчки кода. Потому что есть много готовых элементов, и программу можно составлять даже мышкой.
А>Эта среда планируется в будущем как если не замена, то серьёзная альтернатива Visual Studio. А>Кстати, модель кода (языка) будет содержать все элементы языка C# (for, foreach, is, as, switch, if, int, bool, и другие), так что перейти на эту среду смогут все те, кто уже знаком с C# или хотя бы с платформой .NET.
А>Если есть вопросы — задавайте.
А>А теперь критику и мнения в студию!
Мудро все как-то. С другой стороны, если посмотреть, то уже многое из этого есть. В той же VS можно многое делать визуально. Вопрос только в наличии таких компонент.Можно, конечно, попытаться визуализировать алгоритм, но от этого алогоритмических ошбок не избежать. Мало того, для визуализации программы и ее структуры можно пользоваться реверс инжинирингом в UML.
Поэтому, мне кажется, что нужно просто подобрать удобные продукты и эффективно их использовать.
Re[35]: Как вам задумка, а?
От:
Аноним
Дата:
05.01.07 15:00
Оценка:
ну так и где сие чудо ?!?!?!
или ниче не будет ?
и вобще че тема умерла...
Ну и где этот чуду-программист? Так "хочется посмотреть в его честные глаза". Надо будет запомнить эту ссылку и раздавать всем создающим компонент TProgrammer.
ЗЫ Да простят меня за флуд.
Здравствуйте, kpomka, Вы писали:
K>ну так и где сие чудо ?!?!?! K>и вобще че тема умерла...
Тема не умерла. Просто мне как автору этого чуда очень сложно писать всё одному. Охотников и энтузиастов мне помогать так и не нашлось.
K>или ниче не будет ?
Будет. Но когда — вот это для меня самого большой вопрос.
Соглашусь с предыдущим оратором — БРЕД.
Для того чтобы сделать нечто подобное надо как минимум реализовать искусственный интеллект. То есть задача сводится к воплощению в жизнь идей из фильма "Матрица".
не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
Тогда надо на ковер тех, кто составлял вашу схему данных (к технолдогии этот вопрос уже никакого отношения не имеет). У меня при обновлении пересчитывались данные только за день, затем из уже пересчитанных данных за день пересчитывались месяц, а из месячных данных — год. Да, пришлось немного попотеть и ввести кое-где избыточность (т.н. "исторические" или "архивные" зеркала данных), чтобы при обновлениях данных не надо было пересчитывать за год целиком все транзакции. А пересчет итогов из промежуточных... это смешно, ибо в месяце не более 30 дней (а не сотен тысяч транзакций, понимаешь о чем речь?), а в году не более 12 месяцев (а не миллионы транзакций). А пространств тоже не многие тысячи, дай бог десятки в самой навороченной системе.
