>softwarer
> ... требует решения двух принципиальных задач: ...
Видимо да.
А если в алгоритм решения прибавить две FIFO структуры для данных временного хранения запросов - типа поместить данные и взять данные. Конечно, в структурах нельзя делать выборки, но они могут служить демпфером нагрузки.
Запросы из FIFO записи можно обрабатывать только одним потоком - не нужны (?) будут блокировки.
LittleCat
Ну насчет этого в Cache очень даже неплохо, у нас в реальном времени сетевой трафик с двух гигабитных интерфейсов разбирается и в базу пишется, каша вполне справляется, хоть и запущена на сервере начального уровня.
Чисто профессионально вопрос
Вы используете обьекты CACHE или все в м-коде ?
Как еще какими средствами форсировали скорость ?
Спасибо
Модератор: Извиняюсь, но у вас, кашистов, вроде же есть свой форум...
MX -- ALEX LittleCat
Ну насчет этого в Cache очень даже неплохо, у нас в реальном времени сетевой трафик с двух гигабитных интерфейсов разбирается и в базу пишется, каша вполне справляется, хоть и запущена на сервере начального уровня.
Чисто профессионально вопрос
Вы используете обьекты CACHE или все в м-коде ?
Как еще какими средствами форсировали скорость ?
Спасибо
Ну какие там объекты при таких скоростях :-) Запись в базу через CallIn, самый быстрый метод (ИМХО).
Для вашей АСКУЭ вполне подойдет ORACLE, потому как АСКУЭ система учета, а не управления, и потому некоторые задержки с помещением данных в базу вполне допустимы. Ведь там интервальный учет с датчиков (ну скажем 5 сек). Здесь уже вопросы не в СУБД, а в архитектуре системы.
Если очень упрощенно: надежность, масштабируемость и пропускная способность системы (и БД) решается путем кластеризации, каналов передачи данных, промежуточных коллекторов данных и конечных устройств. Ведь можно собирать на контроллере данные с нескольких датчиков и затем отправлять пакеты в базу. Чем шире совокупный канал, тем больше запросов достучится. И т.д.
LittleCatНу насчет этого в Cache очень даже неплохо, у нас в реальном времени сетевой трафик с двух гигабитных интерфейсов разбирается и в базу пишется, каша вполне справляется, хоть и запущена на сервере начального уровня.
Ну я так думаю, что речь НЕ идет о записи 2-х Гбит/с потока в реальном времени в БД. Ибо тогда или за день переполнятся все вменяемые хранилища данных, или - я не знаю таких хранилищ (винты), которые бы позволили лить на себя байты/биты с такой скоростью ;)
А так - у нас тоже на Оракле 2 сетевухи с гигабитным интерфейсом ;)
2manДля вашей АСКУЭ вполне подойдет ORACLE, потому как АСКУЭ система учета, а не управления, и потому некоторые задержки с помещением данных в базу вполне допустимы.
Для нашей АСКУЭ вот уже 10 лет как подходит Оракл ;) Просто не все понимают это. Людям в голову рекламы напхали, вот они и лезут со своими дурацкими пропозициями :(
А мы ищем аргументы ПРОТИВ рекламных трюков. Вот такие вот пироги
2man
Ведь там интервальный учет с датчиков (ну скажем 5 сек). Здесь уже вопросы не в СУБД, а в архитектуре системы.
ПС: коммерческий интервал - 30 минут. В интересах заказчика можно опрашивать скажем раз в 5 минут. Чаще - некоторые счетчики могут заглючить. Как было отмечено, они очень коммерческие :)
ППС: на АСКУЭ всякие разные любят наворачивать разные доп задачи - отседова и ноги растут :(
Vadim Romanenko LittleCatНу насчет этого в Cache очень даже неплохо, у нас в реальном времени сетевой трафик с двух гигабитных интерфейсов разбирается и в базу пишется, каша вполне справляется, хоть и запущена на сервере начального уровня.
Ну я так думаю, что речь НЕ идет о записи 2-х Гбит/с потока в реальном времени в БД. Ибо тогда или за день переполнятся все вменяемые хранилища данных, или - я не знаю таких хранилищ (винты), которые бы позволили лить на себя байты/биты с такой скоростью ;)
А так - у нас тоже на Оракле 2 сетевухи с гигабитным интерфейсом ;)
Ну конечно не в тупую. Если в двух словах, то слушаются интерфейсы сервера Oracle, на котором работает 800-1000 юзеров. Трафик расшифровывается и в базу пишется текст SQL-запросов и параметры. В день порядка 10-15-ти миллионов записей. Ну и изредка по накопленным данным СБ гоняет аналитику.
Vadim Romanenko
например :
QNX/RT11MJ + XML-типа база дaнных (или что-то подобное).
Стою на асфальте я в лыжи обутый... :-o XML БД - этта типа рилтайм в натуре? :-) :-) :-) Как же я отстал :-( /*здесь актер нюхает лук и типа плачет*/
2man Vadim Romanenko
например :
QNX/RT11MJ + XML-типа база дaнных (или что-то подобное).
Стою на асфальте я в лыжи обутый... :-o XML БД - этта типа рилтайм в натуре? :-) :-) :-) Как же я отстал :-( /*здесь актер нюхает лук и типа плачет*/
расскажи нам малчык что ты знаешь о IN-MEMORY DB ? или у тебя свопы на диск реалтаймовые ?
Lepsik 2man Vadim Romanenko
например :
QNX/RT11MJ + XML-типа база дaнных (или что-то подобное).
Стою на асфальте я в лыжи обутый... :-o XML БД - этта типа рилтайм в натуре? :-) :-) :-) Как же я отстал :-( /*здесь актер нюхает лук и типа плачет*/
расскажи нам малчык что ты знаешь о IN-MEMORY DB ? или у тебя свопы на диск реалтаймовые ?
Читай внимательно - об InMemoryDB ни слова - я по поводу XML как БД стебанулся.
А ты, дедуль, юзал хранилище на XML? Или только "типа" и "на тему" можешь вставить?
2manЧитай внимательно - об InMemoryDB ни слова - я по поводу XML как БД стебанулся.
А ты, дедуль, юзал хранилище на XML? Или только "типа" и "на тему" можешь вставить?
А что где-то было сказано про хранилища ? Может для начала научится читать вопросы. Хранилище и real-time концептуально противоположгые вещи. Болиды формулы1 тоже не пригодны для перевозки больших групп людей.
Lepsik 2manЧитай внимательно - об InMemoryDB ни слова - я по поводу XML как БД стебанулся.
А ты, дедуль, юзал хранилище на XML? Или только "типа" и "на тему" можешь вставить?
А что где-то было сказано про хранилища ? Может для начала научится читать вопросы. Хранилище и real-time концептуально противоположгые вещи. Болиды формулы1 тоже не пригодны для перевозки больших групп людей.
for Lepsik : Ok! - прекращаем ненужную пикировку.
IMHO по теме топика: может просто выполнять каждую задачу соответствующими средствами. Поясняю: обеспечение надежности и реалтайма возложить на средства промавтоматики, т.е. хранение RT-данных осуществлять в специально предназначенных контроллерах, а затем посредством соответствующих адаптеров считывать из контроллеров информацию и загонять ее в любую промышленную БД: Oracle, MS SQL, DB2 etc. В такой модели вопрос "реалтаймности" СУБД вообще не стоит, достаточно обычных требований к системе. Хотя есть такая фича как "MS SQL RealTime" или что-то в этом роде - не раз наталкивался на SCADA-вских сайтах :-) Может это оно? (поищите сами, т.к. мне это было неинтересно и потому сказать ничего не могу)
а вообще - для промышленных решений используются технологии OPC, а для связи с обычными системами (в т.ч. СУБД) специальные адаптеры (например, фирмы ICONICS и др.) - хоть в Access запихнут ваши данные :)
http://www.iconics.com
Так вот - в промышленных системах предусмотрены адаптеры для Oracle, MS SQL, DB2... Про Cach'e - ни слова :)
Так что пошлите этих оболтусов подальше - пускай предметную область изучат, а потом лапшу на уши вешают...
Резюме: реально лоббисты вводят в заблуждение Заказчика, чем нарушают права потребителя на достоверную информацию. А в результате родится неработоспособная кривая система (а задача АСКУЭ достаточно серьезная и эксперименты здесь недопустимы и экономически опасны). Обратитесь в вашу службу безопасности (или СБ Заказчика, если вы являетесь потенциальным Исполнителем) и объясните ситуацию - вас не слушают, может к ним прислушаются.
а вообще - для промышленных решений используются технологии OPC, а для связи с обычными системами (в т.ч. СУБД) специальные адаптеры (например, фирмы ICONICS и др.) - хоть в Access запихнут ваши данные :)
http://www.iconics.com
В связи с появлением третьей страницы все забыли об исходном вопросе :) Речь шла именнно о СУБД реального времени. Как требовании к системе в целом. Чтоб СУБД реального времени являлась ее частью.
По-этому в данном случае об использовании каких-то адаптеров по всей видимости речь не идет...
а вообще - для промышленных решений используются технологии OPC, а для связи с обычными системами (в т.ч. СУБД) специальные адаптеры (например, фирмы ICONICS и др.) - хоть в Access запихнут ваши данные :)
http://www.iconics.com
В связи с появлением третьей страницы все забыли об исходном вопросе :) Речь шла именнно о СУБД реального времени. Как требовании к системе в целом. Чтоб СУБД реального времени являлась ее частью.
По-этому в данном случае об использовании каких-то адаптеров по всей видимости речь не идет...
Тогда ни Oracle, ни Cach'e, ни какая другая подобная (назовем их узловно бизнес-СУБД) не подпадает под это определение :) Данные в системе реального времени хранятся в одном из ее компонентов (назовем условно РТ-БД), причем это чаще всего программно-аппаратное решение. Но выдергивать данные из РТ-БД и помещать в бизнес-СУБД вам придется однозначно, и это будет на 90% либо Оракл либо Мелкософт.
Да не ленитесь же, почитайте про OPC - там все понятно написано :) !!!
Vadim Romanenko
Для нашей АСКУЭ вот уже 10 лет как подходит Оракл ;) Просто не все понимают это. Людям в голову рекламы напхали, вот они и лезут со своими дурацкими пропозициями :(
А мы ищем аргументы ПРОТИВ рекламных трюков. Вот такие вот пироги
Вы хотитет сказать, что аргумент, что у вас уже есть работающая система на Oracle, разработка которой заняла 10 лет, не достаточен??? Кто в здравом уме будет переносить готовый проект на другую СУБД? Я еще не видел, чтобы при существовании готового работающего приложения кто-то стал переносить его на другую СУБД. Если за это кто-то готов платить деньги - тогда, конечно, вопросов нет - кто платит, тот и музыку заказывает.
Мимопроходящий
и я же ещё должен тебе о ней рассказывать...
если бы ты, в качестве примера задел, скажем RCVD из RSX-11M,
тогда можно было бы об чем-то потолковать.
а так, пустой трёп с дельфинистом...
Да, против дедушек не попрешь...
Давайте вспомним, когда лучше юзать RSX-11M, а когда RT-11, и что было вырезано в OC РВ-11, и с какими адаптерами работала DEC NET...
Не понял Кто в здравом уме будет переносить готовый проект на другую СУБД? Я еще не видел, чтобы при существовании готового работающего приложения кто-то стал переносить его на другую СУБД. Если за это кто-то готов платить деньги - тогда, конечно, вопросов нет - кто платит, тот и музыку заказывает.
Вот именно, что таких примеров достаточно. Система уже запущена, и даже сертифицирована, и тут кто-то наверху получает хороший откат, и летит приказ на места, все снести, ставить что приказывают... Видели.
LittleCat Не понял Кто в здравом уме будет переносить готовый проект на другую СУБД? Я еще не видел, чтобы при существовании готового работающего приложения кто-то стал переносить его на другую СУБД. Если за это кто-то готов платить деньги - тогда, конечно, вопросов нет - кто платит, тот и музыку заказывает.
Вот именно, что таких примеров достаточно. Система уже запущена, и даже сертифицирована, и тут кто-то наверху получает хороший откат, и летит приказ на места, все снести, ставить что приказывают... Видели.
Позвольте вклиниться в Вашу беседу, господа, со следующим вопросом. Сам уже давно отошел от сугубо технических вопросов, поэтому обращаюсь к специалистам!
В одной компании, зарубежной компании, в силу геополитической ситуации существует необходимость сделать базу данных реального времени с испольсованием только ПО, распространяющегося в открытых кодах.
Это изначально обречено на провал? Или же есть какая-то надежда на успех?
Лично моей заинтересованности в этом проекте нет никакой, однако просто стало интересно, это возможно или нет?
То есть найти систему в открытых кодах, которая будет обеспечивать соответсвующую производительность на уровне целого предприятия, обрабатывать и хранить огромные объемы информации, это такая простая задача, получается? И тот же MySQL с ней справится? Или PostgreSql?
foxovikА что, если код закрыть, то быстрее работать будет?
Впрочем, Вы уже отошли от дел...
Нет, здесь страхи совсем другого плана - в закрытых кодах могут присутствовать закладки, функции-шпионы, не документированные возможности, которые могут быть использованы для получения конфиденциальной информации.
Либо нет желания (возможности) платить большие деньги за лицензию
