Петер Менгель: Мы ищем "невозможные" проекты Опции

[NewsBot]

CNews: В чем вам видятся минусы SQL, если приходится временами от него отказываться? Петер Менгель: С недостатками и ограничениями этой технологии мы столкнулись во время работы со многими нашими крупными заказчиками по всему миру. В частности, мы работаем с такими клиентами, как инвестиционный банк Credit Suisse, Европейское космическое агентство (ЕКА), компанией BTC, одним из крупнейших...

Читать статью на CNews

Круто!

MUMPS, M ... жив!

Круто!

MUMPS, M ... жив!

Типа того )

Мне в этом контексте понравилась характеристика из одного блога (правда не про Cache а про GT.M): что это как крокодил, - они жили в одно время с динозаврами, но динозавры все издохли, а крокодилы остались и в своей нише неплохо себя чувствуют

На MSM было сделано управление производством на "Парнасе-М" до того момента, как он попал в руки кузьмоловским ребятам. На рисках и старых пнях всё отлично вертелось. Те решили переделать всё на SQLный 1С. В результате -- 9 месяцев невообразимого траха, смена 6 версий, замена абсолютно всего железа и штата ИТшников, наконец всё со скрежетом зашевелилось. Сейчас всё как-то скрипит, качество продукции недурное, но ценники, увы, не радуют. Каталог продукции выдаёт информацию в объёме меньшем, чем напечатано на этикетке(!!!), за время порядка 20 секунд. Афигенная CRM/ERP. Я так и не знаю, поняли они или нет, что откатились с системы послезавтрашнего дня на систему дня позавчерашнего...

Немцы "забыли" про иерархические системы сбора данных, где информация обрабатывается на каждом генерирующем ее узле и считывается узлом уровня +1 в обработанном виде. Для чего, например, считывать с каждого ветряка 500 показаний в секунду? Достаточно раз в минуту считать среднюю мощность. Экономия - 29999 записей. В эпоху копеечных микроконтроллеров с вычислительными возможностями БЭСМ-6 глупо гонять по сетям терабайты данных в "сыром" виде.

Не соврёшь - истории не раскажешь. (с)

В НИИЭФА АСУ ТПП ТЕКРАМ (на DSM-11/VAX) крутилась сама и одна (бэз сопровождающих погромил) лет 10 ... не вру. :-) И то местный перец чё-та хотел с ней сделать.

Немцы "забыли" про иерархические системы сбора данных, где информация обрабатывается на каждом генерирующем ее узле и считывается узлом уровня +1 в обработанном виде. Для чего, например, считывать с каждого ветряка 500 показаний в секунду? Достаточно раз в минуту считать среднюю мощность. Экономия - 29999 записей. В эпоху копеечных микроконтроллеров с вычислительными возможностями БЭСМ-6 глупо гонять по сетям терабайты данных в "сыром" виде.

Не все так просто. Сама начинка распределенных узлов обработки действительно стоит копейки. Но вот обслуживание распределенной системы стоит намного дороже. Алгоритмы управления еще не отработаны, постоянно меняются. Намного проще в таких условиях все обрабатывать в центре, в т.ч. разными алгоритмами одновременно. Представьте насколько будет трудоемко непрерывно обновлять алгоритмы обработки на сотнях не обслуживаемых распределенных узлах. Любой софт на этапе отладки будет глючить, соответственно нужно будет иногда выезжать на место. Да и сам процесс отладки алгоритмов распределенном на сотнях независимо работающих узлах - это серьезная проблема.

Поэтому как я понял, немцы немного вложились в дата-центр, и все сложности исчезли сами по себе. Раз технология есть, то в чем проблемы.

Согласен в пред-пред-предыдущим оратором - централизация в целом хорошо, но без явного идиотизьма как в рассматриваемом случае. Строить догорой дата-центр не иначе как ещё на видавс или линьюксе - это первый идиотизьм. Второй - нагружать комплекс таким кол-вом транзакций, третий - стихийность жизни сети приводит к пикообразным флудам, штормам ... Воощем, они конечно "обогнали другие хорошие СУБД" - но по-моему явно через зад. :-) Да и через зад сбор показаний счётчиков воды вгонять в иерархию ...

А MUMPS - дело хорошее ... :-)

Согласен в пред-пред-предыдущим оратором - централизация в целом хорошо, но без явного идиотизьма как в рассматриваемом случае. Строить догорой дата-центр не иначе как ещё на видавс или линьюксе - это первый идиотизьм. Второй - нагружать комплекс таким кол-вом транзакций, третий - стихийность жизни сети приводит к пикообразным флудам, штормам ... Воощем, они конечно "обогнали другие хорошие СУБД" - но по-моему явно через зад. :-) Да и через зад сбор показаний счётчиков воды вгонять в иерархию ...

А MUMPS - дело хорошее ... :-)

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

Как собрать данные в одном месте - это было решено довольно давно. Сейчас выросли скорости каналов, и повысился интеллект оконечных устройств. Появилась возможность собирать больше данных.

Зачем нужны эти данные - это как раз еще не решено. Теоретических изысканий много, а практических реализаций мало. Есть еще политические спекуляции типа запрета ядерной энергетики, когда немцы, начинают пилить бюджет оправдываясь якобы ядерной безопасностью. Бюджеты там умеют осваивать получше наших.

Исходя из всего сказанного нужно уметь сохранять в БД кучу данных, чтобы кто-нибудь потом с этими данными экспериментировал, и может быть изобрел какой-нибудь дельный алгоритм имеющий практическую ценность. Нереально распределено решать задачу не имеющей четкой технической постановки, а имеющей только более-менее ясную политическую цель. Централизованно хотя бы что-то можно сделать. Представьте массу немецких аспирантов и инженеров хаотично через интернет подключающихся к вашему счетчику электроэнергии, к контроллеру ветряка расположенного рядом и т.п. Централизованный доступ к информации со стороны этой массы людей - единственная возможность как-то обеспечить технологическую безопасность.

Разработчики СУБД возможность предоставили. Политика, рынок, конкуренция и прочее - это уже не их забота. Решение есть - это хорошо.

Сообщение отредактировал alexey38 - 29.8.2011, 15:03

Прежде чем чирикать за сети, стоит самому узнать о сетях чуть более чем хом лан и перестать верить что "структурой сети" решаются все проблемы транспортной среды. Ужо сказано задача решена идиотским способом. Ну и надо понимать что на М делать сбор CDR-ок - глупость. Есть способы на порядок дешевле и производительней.

Молодцы, больше бы средок разработок.
____________
http://market-fmcg.ru/