घर
Top.Mail.Ru Yandeks.Metrika
फोरम: "मामले";
वर्तमान संग्रह: 2004.04.18;
डाउनलोड करें: [xml.tar.bz2];

नीचे

कौन सा DBMS चुनना है? इसी तरह की शाखाएँ खोजें


WondeRu ©   (2004-03-18 09:53) [0]

Есть следующие задачи, которая должна обслуживать БД:
1. Клиентские рабочие места - 20-30
2. До 400 транзакций в сек.
3. Отказоустойчивось
4. Триггеры, библиотеки расширения и т.п.
5. Недорогая
6. Windows/Linux

Что подскажите? Какую СУБД выбрать?



Vlad ©   (2004-03-18 09:55) [1]

Оракл, если денег не жалко :-)



WondeRu ©   (2004-03-18 10:05) [2]

ओरेकल - गायब हो जाता है। यह बहुत महंगा है, और 30 ग्राहकों के लिए इसकी क्षमता बहुत अधिक है। पैसे की बर्बादी।



Vlad ©   (2004-03-18 10:09) [3]

संस्करण 6 या फायरबर्ड के बाद इंटरबेस



Zacho ©   (2004-03-18 10:16) [4]


> व्लाड © (18.03.04 10: 09) [3]

Присоеденяюсь. Только насчет 400 тр./сек не уверен, в моей практике было поменьше. Но кто мешает автору топика поставить FB 1.5 и проверить ? По остальным требованиям подходит, особенно по цене :)



WondeRu ©   (2004-03-18 10:24) [5]

अब Fb इसके लायक है, लेकिन दूसरों के साथ जांच करने के लिए और आपातकालीन शटडाउन (और कभी-कभी सिर्फ) के दौरान बेहतर प्रदर्शन प्राप्त करने के लिए शिकार करते हैं कभी-कभी डेटाबेस खराब हो जाता है।



Vlad ©   (2004-03-18 10:29) [6]


> वोंद्रु © (18.03.04 10: 24) [5]

Выбирай на любой вкус :-)
http://www.dbforums.com/
Там же можно и консультацию получить по интересующим вопросам.



Romkin ©   (2004-03-18 10:31) [7]

[5] फोर्स्ड राइट्स चालू करें, डेटाबेस सिर्फ खराब नहीं होना चाहिए



Zacho ©   (2004-03-18 10:35) [8]


> при аварийном выключении (а иногда просто) сервака порой
> база портится.

Поставь UPS на сервер. Или см. http://www.ibase.ru/v6/ib6faq.htm#fwoff



WondeRu ©   (2004-03-18 10:52) [9]

Если я не ошибаюсь, то Forced Write = ON уменьшит скорость работы. Или я не прав?



Romkin ©   (2004-03-18 10:57) [10]

А ты проверь :)) Сейчас практически разницы быть не должно, особенно на Linux
В любом случае, это лучше, чем крах БД



WondeRu ©   (2004-03-18 11:03) [11]

А у нас оказывается включен FW! А все равно бывает слетает база



serge35   (2004-03-18 11:08) [12]

Проверь, может еще что лишнее включено?

А недорогая - это в пределах какой суммы?
На рынке за 80 р можно любую купить.
Правда Oracle 9 по-моему на двух дисках,
поэтому он и дороже в 2 раза.



WondeRu ©   (2004-03-18 11:12) [13]

> सर्ज 35 (18.03.04/11/08 12:XNUMX) [XNUMX]

Если бы система не ставилась на гос и т.п. объекты, то я бы этот вопрос не задавал!)))

>На рынке за 80 р можно любую купить.
Знаю где по 35р. в Самаре ;-)



Romkin ©   (2004-03-18 11:16) [14]

[11] Странно, причем весьма. Мне так и не удалось обрушить БД при FW. Модет быть, что-то с аппаратной частью?



Vlad ©   (2004-03-18 11:19) [15]


> रोमकिन © (18.03.04 11: 16) [14]


> Мне так и не удалось обрушить БД при FW

Как рушил ? :-)



WondeRu ©   (2004-03-18 11:21) [16]

>Как рушил ? :-)

Заполняешь базу всякой фигней, и выдераешь вилку компа из розетки)



Vlad ©   (2004-03-18 11:24) [17]


> वोंद्रु © (18.03.04 11: 21) [16]

Странно, так просто рушиться не должна...



Romkin ©   (2004-03-18 11:24) [18]

Vlad ©  (18.03.04 11:19) [15] НУ как? ЗАпускаются 10-15 потоков, в каждом - цикл работы с БД. На автозагрузке...
НУ и reset стоишь, жмешь периодически. Как еще?



Vlad ©   (2004-03-18 11:28) [19]


> रोमकिन © (18.03.04 11: 24) [18]

Мне удавалось обрушить в момент Restore - вырубаешь комп, потом включаешь и файл бэкапа и самой БД порушен :-)



Zacho ©   (2004-03-18 11:30) [20]

Я тоже примерно так эксперементировал лет 5 назад. Базу порушить не удалось. Так что похоже у WondeRu © проблемы с железом. Но в таком случае никакой другой SQL-сервер не поможет.



WondeRu ©   (2004-03-19 08:26) [21]

> जैचो © (18.03.04/11/30 20:XNUMX बजे) [XNUMX]
Это-то проблемы с железом на фирменных IBM, HP  и др.?)))

УПС предположим стоит, но давайте на вопрос попробуем ответить: какую СУБД выбрать для увеличения скорости по сравнению с FB? Работат 30 компов, на каждом запущено до 16 потоков работы с БД (16*30=480 потоков), и все это добро должно иметь как можно меньшее время отклика!



bushmen ©   (2004-03-19 10:27) [22]

>какую СУБД выбрать для увеличения скорости по сравнению с FB?
Попробуй Cache



Romkin ©   (2004-03-19 10:28) [23]

Yaffil, NSSQL, Oracle
Меньшее время? Более мощный сервер, и оптимизировать запросы



Romkin ©   (2004-03-19 10:29) [24]

А операционка какая? На Linux FB заметно быстрее работает, чем на NT
Zacho ©  (18.03.04 11:30) [20] Скорее, кстати, похоже на проблемы с ОС :))



Romkin ©   (2004-03-19 10:29) [25]

А операционка какая? На Linux FB заметно быстрее работает, чем на NT
Zacho ©  (18.03.04 11:30) [20] Скорее, кстати, похоже на проблемы с ОС :))



Delirium ©   (2004-03-19 10:33) [26]

विंडोज के लिए, यह स्पष्ट रूप से MSSQL है, अगर आधार <2Gb है, तो यह मुफ़्त है (DeskTop संस्करण)।



bushmen ©   (2004-03-19 10:43) [27]

>6. Windows/Linux

MSSQL отпадает по условию задачи



Delirium ©   (2004-03-19 10:45) [28]

Тогда, без сомнения - InterBase, как уже предлагалось, лучше ничего не придумаешь.



serge35   (2004-03-19 10:56) [29]

Сервер надо купить в 10 раз мощнее.
И не надо экономить деньги организации, на которую
ты работаешь. Если они хотят 400 транзакций в сек.
то пусть раскошеливаются на сервак за 20-40 тыс $.
И сетевое оборудование.
А если для организации УПС купить проблема,
то пусть берут счеты и на них работают.



WondeRu ©   (2004-03-22 08:54) [30]

>то пусть раскошеливаются на сервак за 20-40 тыс $.

Если ПО стоит $3000-4000, то вообще нереально отдельный сервак выделять!



roottim   (2004-03-22 09:29) [31]

>Oracle - отпадает. Больно уж дорог, да и его мощности многовато на 30 клиентов. Бессмысленная трата денег

интересно где-же он будет дорог... 300 баков за намед юзера..
у тебя их всего 30-40..  то биш около 10 кусков он тебе обойдется

40000$ на анлимиед - это может и дороговато... но если у тебя будет более 1000 юзеров.. лучше сервера  сейчас думаю не найти...

во вторых при твоем требовании на 400 тразакций в сек... это тоже оптимальный вариант..
в отличие о других субд работа блокировок и транзакций в оракле сделаны оптимально (быстро, удобно, без потерь)

в третьих.. не такой оракул и прожорливый... еже-ли правильно настроить (у нас тестовый инстанс на персоналке XP п3 с 256м озу и то работает кул), ну конечно по занимаемым ресурса с FB не сравнить... но нужно понимать что назначение их разное.. и гарантии и возможности тоже...



Sergey13 ©   (2004-03-22 09:49) [32]

2roottim   (22.03.04 09:29) [31]
40000$ - это на процессор в энтерпрайс эдишн. Стандарт - 15000$, Стандарт Он - 5995$. Я читал где то, что Ораклы собираются снизить цену на стандарт он до 4000 и разрешить там работать на 2 процах+урезаная репликация.
Так что дороговизна Оракл - это не совсем так.



roottim   (2004-03-22 10:10) [33]

2Sergey13 © (22.03.04 09: 49) [32]

про все цены я в курсе...

> Так что дороговизна Оракл - это не совсем так

и полность с тобой согласен...

если взять к примеру комерческую лицензию мускула ~ 500$ за намед узера,  то незнаю что и выбрать... я бы не сомневался в пользу оракула...

про Cache не могу ничего сказать... сам потихоньку его осваиваю.. но уж очень все у меня медленно... слишком "большой" опыт в РЕЛЯЦИОННЫХ СУБД... трудно мозги перестраивать.
но когда я делал запрос к ним.. як бы купить...
то ценник был 300 с соплями на юзера... то биш по цене сопоставим с оракулом.. а вот в во всем остальном трудно сказать..  хоть они и заявляют о своей "быстр, умен, не требует сильного админа"... но реальных сравнений (не те хвалы что на их сайте) я не видел...



snake1977   (2004-03-22 10:12) [34]

а Oracle 7 можно бесплатно юзать :)
потому как ен снят с производства



Sergey13 ©   (2004-03-22 10:17) [35]

2snake1977   (22.03.04 10:12) [34]
Можно даже 10Г. Но не в промышленной эксплуатации. 8-)

2roottim   (22.03.04 10:10) [33]
Да я собственно не для тебя и писал. Просто цифру ты назвал, на тебя и сослался. Сори. Я догадываюсь что ты знаешь. 8-)



WondeRu ©   (2004-03-22 10:23) [36]

А где можно накопать сводный прайс всех распространенных в России СУБД?



Sergey13 ©   (2004-03-22 10:24) [37]

2WondeRu © (19.03.04 08: 26) [21]
>Работат 30 компов, на каждом запущено до 16 потоков работы с БД (16*30=480 потоков)
А что за работа такая, что именно 16 потоков? Что вообще 400 транзакций делают? Они ведь есть разные, эти транзакции. Если даже Оракла поставить и им никак не заниматься, то ИМХО и ему тяжеловато будет. Загубить можно все что угодно.



WondeRu ©   (2004-03-22 10:29) [38]

> सर्गेइएक्सन्यूम्एक्स © (13 22.03.04: 10) [24]
на каждом компе может висеть до 16 железяк на портах, которые должны управляться и мониториться в реальном времени и записывать свои события в एक БД!



roottim   (2004-03-22 10:37) [39]

2Sergey13 © (22.03.04 10: 17) [35]
 да я разве обиделся ?... просто ежели пишеш 2roottim то все что ниже предназначеается мне.. .. а я тебе и сказал что что "знаю про них"

2WondeRu © (22.03.04 10: 29) [38]
речь идет о постоении (точнее наверно имитации, так-ка тут и операционка и СУБД все должно быть завязано.. и вребя обработок критично) систем реального времени, то оракул 100% тебе в помощь...



WondeRu ©   (2004-03-22 10:43) [40]

Насчет Оракла ВЫ меня почти убедили, а насчет сводного прайса не подскажите? Где накопать? Плюс, виды лицензий на каждую СУБД! Ищу, не могу найти ничего подходящего((



Sergey13 ©   (2004-03-22 10:44) [41]

2WondeRu © (22.03.04 10: 29) [38]
А что они делают, железяки эти? Инсертят или апдейтят? Если индексов много - могут тормозить. В общем фиг его знает. Если основная работа только на вставку, то Оракл может и не ускорит. Пробовать надо, однако. Аппарат однозначно ускорит, особенно дисковая подсистема. ИМХО.



roottim   (2004-03-22 10:45) [42]

и не найдешш.. на некоторые субд.. я вообще письмом кидал в их сторону.. только после мне прайсы высылали...
незнаю почему некоторые субьекты не хотят выставлять ценники в инет (к примеру в ордерах)



WondeRu ©   (2004-03-22 10:52) [43]

Лана, я буду толкать Оракл! Всем, принявшим участие, огромное спасибо!



Sergey13 ©   (2004-03-22 11:01) [44]

2WondeRu © (22.03.04 10: 52) [43]
Толкать можно. Но хочу тебя предупредить, что это несколько отличается от ИБ и с ходу после инсталяции, без опыта и обучения, тебе будет ох как не просто.



roottim   (2004-03-22 11:40) [45]

рекомендация... Благо наконец вышла в свет книга Тома Кайта "ORACLE для крутых перцев" ( шутка.. но смысл в том же :)) ) точнее уже 2-х томник.. для понимания этой СУБД она будет тебе очень и ОЧЕНЬ полезна...
धमकी
у меня есть все книги издательства ЛОРИ по 8и -ке..
но по опыто все вопросы (и ответы) я всегда черпал именно от Кайта (ну кроме маналов) на его сайте asktom.oracle.com или его книг



Deniz ©   (2004-03-22 12:12) [46]

बंद
> roottim   (22.03.04 10:10) [33]
> про Cache не могу ничего сказать... сам потихоньку его осваиваю.. но уж очень все у меня медленно... слишком "большой" опыт в РЕЛЯЦИОННЫХ СУБД... трудно мозги перестраивать.

А как, пардон, Вы с этим чудом работаете? Т.е. среда(Delphi/C++ и т.д.), способ доступа?



Petr V. Abramov ©   (2004-03-22 12:57) [47]

> 1. Клиентские рабочие места - 20-30
> 2. До 400 транзакций в сек.
 Это по 20 тр/сек с рабочего места. Если 1 тр = 50 байт, то это ~70М/час, при работе даже по 8 час/день 80 Гиг винта хватит на 15 дней максимум. По сами, понимаете, ну чересчур оптимистичной методике подсчета. Может, это все же какие-нить данные с датчиков, и СУБД тут не надо использовать (по крайней мере, сразу сырые данные в нее гнать)?



roottim   (2004-03-22 13:25) [48]

2Deniz ©   (22.03.04 12:12) [46]
 изучаю как и все прочее... в делфи я сораклом работаю..
а Caсhe пока на стадии их подручных средств CSP, Studio, Тирминалка, и скл менеджер..
- под делфи можно использовать одбс или com объекты
 но все-же их основной упор на CSP .. т.к веб-сервис интегрирован всместе с их ядром.. и думаю интерфейсы делфи здесь необходимы постольку поскольку... например отчетик в фаст-репортере забабахать.. ну или малоли что бывает. так что в этом контексте и работаю.. :)) надеюсь удовлетворено любопытство !



roottim   (2004-03-22 13:28) [49]

2Petr वी। अब्रामोव © (22.03.04 12: 57) [47]
это тоже вариант... формировать файлы с опр. структурой и писать значения напрямую туда... а затем переносить (если конечно есть перерыв во времени снятий данных..
в этом случае любая удобная для обработки результатов база подойдет.. ну а если напрямую туда... то наверно всеже оракул



Petr V. Abramov ©   (2004-03-22 13:36) [50]

> roottim   (22.03.04 13:28) [49]
> .. ну а если напрямую туда... то наверно всеже оракул
 Угу. И писатели биллинговых систем тут же не выдержат конкуренции и разорятся :) Да такие системы (400 транзакций в секунду), наверное, по пальцам пересчитать можно. Или автор не ведает, что творит, или не ведает, за что взялся, или это не транзакции :)



roottim   (2004-03-22 13:57) [51]

2Petr वी। अब्रामोव © (22.03.04 13: 36) [50]
да я думаю что не так все грустно...
 он привел пиковую нагрузку.. 16 устроиств на клиента
 а реально-то думаю меньше... и данные "думаю" снимаются не милисекундами...
- хотя ситуация когда все устр-ва одновременно будут писать в базу возможна... только все зависит от минимального времени транзакции... Оракле сдесь имеет плюс в том что одновременная вставка в таблицу не вызовет колизий... наверно и все...

- ну а если и правда с такой мощностью идет наполнение... то всетаки необходимо испытать и то и то... и сравнить результаты..
т.е при записи в файл и работа напрямую с субд.



Petr V. Abramov ©   (2004-03-22 17:20) [52]

> roottim   (22.03.04 13:57) [51]
 Спор на пиво, что в файл быстрее? :)
 Если, конечно, не совсем кривыми руками :)
> он привел пиковую нагрузку..
 Да если даже на 10 поделить, все равно не кисло.
Но соглашусь, что если уж так решит человек писать сразу  в базу,то лучше в Oracle :)



WondeRu ©   (2004-03-23 09:03) [53]

लोग, हार्डवेयर ऑसिलोस्कोप नहीं हैं, यह 30x16 का सबसे खराब संस्करण था! और इसलिए एक बजे (डिवाइस से तीन सौ घटनाओं में खुशी आएगी))) लेकिन चरम भार चरम मामलों में मौजूद होना चाहिए, आखिरकार, यह लगभग एक तकनीकी प्रक्रिया है, अर्थात्। देरी 5 सेकंड के बहुत किनारे!



Sergey13 ©   (2004-03-23 09:39) [54]

30*16*300=144000 событий в час=40событий в секунду
тоже не слабо, если я ничего не напутал.
Что за событие, скока чего пишется? Зачем нужны результаты? Как часто и по каким критериям инфа читается из базы? Написал бы нормально про задачу. А то гадание на кофейной гуще какое то.

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



roottim   (2004-03-23 10:04) [55]

2Sergey13 © (23.03.04 09: 39) [54]
> В Оракле можно много чего подкручивать, но не скорость записи на диск
собственно причем тут запись на диск... это бд а не операционка..
для чего буферный кэш тогда существует..
а насчет того что настроить можно так что время записи будет много более времени поступления - это можно... но это уже не только оракле относится а ко всему семейству БД.
> Что за событие, скока чего пишется
это да.. хотелось бы услышать оценочные параметры..
2 WondeRu © (23.03.04 09: 03) [53]
>т.е. самый край задержки 5 сек
это означает что задержка в записи=5сек - максимальный предел?
если так... то запись напрямую подходит для этого случая точно



WondeRu ©   (2004-03-23 10:04) [56]

3GHz भांग मशीनों, कोई समस्या नहीं है! लेकिन एफबी को डीबीएमएस वर्ग के रूप में चित्रित किया गया है! इसलिए, कुछ अधिक सही करने के लिए आगे बढ़ने की जरूरत है! और प्रति सेकंड 40 घटनाओं - इस तरह के परिणाम की संभावना 0.5% के बारे में है! घटनाओं को सरल आवेषण द्वारा दर्ज किया जाता है, लेकिन साथ ही, तर्क संचालित होता है जो घटना के प्रति प्रतिक्रिया करता है और पिछली घटनाओं के विश्लेषण के लिए डेटाबेस को भी संदर्भित करता है!



roottim   (2004-03-23 10:16) [57]

2WondeRu © (23.03.04 10: 04) [56]
тогда флаг в руки...  даже 40 соб в секунду - это нормально при правильной всавке (подготовить план запроса.. свзываемые переменные и в путь...) если при вставке логика проверок минимальна - то средствами пл/скл пишем процедурку вставки и оставляем ее в разделяемом пуле (keep), для скорости. если логика проверки данных более "мощная" - то вставке данных ничего не должно мешать.. а выявление ошибок в данных производить в фоновым процессом или мулькой...



Sergey13 ©   (2004-03-23 10:19) [58]

2roottim   (23.03.04 10:04) [55]
Если в БД идет постоянная запись, то при чем тут буферный кеш? Про чтение из БД автор упорно ничего не сообщает. Наверное это тайна покрытая мраком. 8-)

2WondeRu © (23.03.04 10: 04) [56]
А по конкретнее можно? Ты все про секунды да про события. А что за события, что за объемы - ни слова. Например - что есть "анализ предыдущих событий"? Агрегатные значения за месяц? Да при таких объемах что угодно в ступор встанет.

पुनश्च:
И не надо про устаревшее как класс СУБД!
Разруха она в головах. (с) пр.Преображенский.



roottim   (2004-03-23 10:28) [59]

2Sergey13 © (23.03.04 10: 19) [58]
> Если в БД идет постоянная запись
перенаправляю..
> А так в час тройку сотен событий от устройства придет уже радость

такчто думаю скорость записи на диск будет не критична при достаточном размере буф.кэша (на пиковую нагрузку)



Sergey13 ©   (2004-03-23 10:36) [60]

2roottim   (23.03.04 10:28) [59]
Так три сотни в час от одного устройства. От 30*16 устройств это 40 в секунду. А это немало. Так это еще без "анализа предыдущих событий"!
Или я запутался в цифирях?



roottim   (2004-03-23 10:39) [61]

еще разз...
>уже радость
शायद
>А 40 событий в секунду - вероятность такого исхода порядка 0.5%

>От 30*16 устройств это 40 в секунду. А это немало
у меня по 100 в секунду бывает(редко.. но проверял) вставок в базу... все ничего...



WondeRu ©   (2004-03-23 10:46) [62]

>Sergey13 c   (23.03.04 10:19) [58]
Про разруху в головах, а в частности всяких там Швондеров и Шариковых (а возможно и у меня) мне известно!

Короче анализировать нужно (уже делается) последние 5-10 событий всех устройств!
События: срабатывание контактного датчика, обрыв провода  и т.п.



Sergey13 ©   (2004-03-23 10:48) [63]

2roottim   (23.03.04 10:39) [61]
Ну у автора все очень противоречиво. Вначале было 400 транзакций в секунду, потом вероятность 40 в секунду стала 0.5%... Как он это все считает с точностью до полупроцента? 8-)

>у меня по 100 в секунду бывает
У меня и больше бывает, но кратковременно, слава богу. 8-)



WondeRu ©   (2004-03-23 10:54) [64]

> सर्गेइएक्सन्यूम्एक्स © (13 23.03.04: 10) [48]
Могу написать 0.5099% ;-) Сам не считал, но вероятность какая-то все же присутствует! Аудитом такой хр.. (вероятностей) я еще не занимался!



Sergey13 ©   (2004-03-23 10:56) [65]

2WondeRu © (23.03.04 10: 46) [62]
А по какому принципу ты отбираешь "5-10 последних по всем", если от устр №1 последнее было 3 дня назад, а от устр №444 полсекунды назад. И как записывается это событие? код.устр./дата.время/величина?



WondeRu ©   (2004-03-23 11:15) [66]

2Sergey13 © (23.03.04 10: 56) [65]
Точно сказать не могу, не я этим занимаюсь)



Sergey13 ©   (2004-03-23 11:25) [67]

2WondeRu © (23.03.04 11: 15) [66]
Интересная у тебя задача.
Кто то чего то делает с какой то вероятностью, но уверенности нет ни в чем. Хотя цифры приводишь на удивление конкретные, хотя и не нужные, в основном. После этого говоришь FB отстой, а Оракл (который в глаза не видел) рулез форэва. 8-) Даже не интересно продолжать.



Fay ©   (2004-03-23 11:27) [68]


> FB отстой, а Оракл (который в глаза не видел) рулез форэва.
>

तो यह है



Sergey13 ©   (2004-03-23 11:33) [69]

2Fay © (23.03.04 11: 27) [68]
Ну все - в треп надо переносить. 8-)



WondeRu ©   (2004-03-23 11:35) [70]

> सर्गेइएक्सन्यूम्एक्स © (13 23.03.04: 11) [25]
Oracle-то я ставил, но чисто в образовательных целях.

>Self "не я этим занимаюсь"
именно анализом не я, а представление обо всей системе вполне конкретное и ... кушать уже охота... )))



WondeRu ©   (2004-03-23 11:37) [71]

> सर्गेइएक्सन्यूम्एक्स © (13 23.03.04: 11) [33]

कॉमेंट से सहमत



Fay ©   (2004-03-23 11:43) [72]

Про "Трёп" согласен. FB нельзя сравнивать с Oracle. Хорошо ещё, что модераторы это терпят 8)



bushmen ©   (2004-03-23 11:49) [73]

Тут еще надо учитывать, что основная загрузка - это, как я понимаю, всавка данных в БД.



Sergey13 ©   (2004-03-23 11:50) [74]

2Fay © (23.03.04 11: 43) [72]
>FB нельзя сравнивать с Oracle
Религия такая?



Fay ©   (2004-03-23 11:54) [75]

MSSQL и Oracle. 8)



Sergey13 ©   (2004-03-23 11:56) [76]

Ну это точно в треп. 8-)



KSergey ©   (2004-03-23 14:22) [77]

Я бы начал от другого плясать: чем обернется то, что 40 событий в сек. не успеют отработаться вовремя? А 400? Если это крах всей системы с милионными убытками и гибелью сотен человек или это 5 минут вмешательства оператора?
Если первое - то на это и надо действительно закладываться, верноятно - винда тут не канает.
А если второе - то давайте все же говорить о реальной нагрузке с разумным запасом.
А то сейчас выяснится, что 97% нагрузка будет один инсерт в 5 сек и одна выборка 5 строк по ключу в 30 сек, а расет будет на жуткого монстра с жуткой ценой...



яч   (2004-03-23 16:19) [78]

> 1. Клиентские рабочие места - 20-30
> 2. До 400 транзакций в сек.
а не устанут 30 человек делать 400 транзакций в сек???



Zacho ©   (2004-03-23 16:24) [79]


> फे © (23.03.04 11: 43) [72]
> FB нельзя сравнивать с Oracle.

Можно. Ибо версионность в Оракле растет именно из IB. Но разговоры на эту тему уж точно надо в "Потрепаться" :)



Fay ©   (2004-03-23 16:48) [80]

Нет! "Ибо версионность в Оракле растет именно из IB" - жемчужина "Орешника".



Sergey13 ©   (2004-03-23 16:53) [81]

Еще не в трепе? Странно!!! 8-)



WondeRu ©   (2004-03-24 08:20) [82]

> KSergey © (23.03.04 14: 22) [77]
>Если это крах всей системы с милионными убытками и гибелью сотен человек или это 5 минут вмешательства оператора?

К первому ближе!



Sergey13 ©   (2004-03-24 08:54) [83]

2WondeRu © (24.03.04 08: 20) [82]
>К первому ближе!
Ну тогда давай трепаться. 8-)
(недавно помнится ядерные эксперименты на БД ставили, теперь опять люди в опасности 8-).

С какой частотой "центр" запрашивает статистику по всем приборам? Раз в секунду? минуту? 5 минут? час? Если ближе к последнему, то может стоит передавать туда инфу уже предварительно обработаную на клиенте с чуть меньшей периодичностью. Если исходить из того что прибор все таки должен работать нормально, зачем уведомлять об этом центр? Может достаточно послать отчетик типа период/среднее/макс.отклонение. А вот при возникновении "нештатной" ситуации слать сразу и подробно?
На клиентских машинах сидят операторы? Если да, то наверное и уведомлять в первую очередь надо их, а не "центр". Т.е. может над общей логикой работы подумать. (люблю я это дело 8-)



Anatoly Podgoretsky ©   (2004-03-24 09:02) [84]

WondeRu © (24.03.04 08: 20) [82]
Раз речь об миллионных убытках и гибели людей, то RS6000+AIX+Oracle



KSergey ©   (2004-03-24 09:28) [85]

> [82] WondeRu © (24.03.04 08: 20)
>> KSergey © (23.03.04 14: 22) [77]
> >Если это крах всей системы с милионными убытками и гибелью
> сотен человек или это 5 минут вмешательства оператора?
>
> К первому ближе!

निफ्गा खुद!
И в этом случае вы берете на себя смелость ее проектировать, получая ответы в публичных форумах?
Вы уж извините, но может не ваша это задача, а?



WondeRu ©   (2004-03-24 09:36) [86]

2KSergey (24.03.04/09/28 85:XNUMX) [XNUMX]
Думаю, все таки смысл есть, не указывается же сама система и ее прямое назначение. Щас схожу на лабы по "Системам дистанционного зондирования Земли" и приду продолжить диспут!



Anatoly Podgoretsky ©   (2004-03-24 09:39) [87]

KSergey © (24.03.04 09: 28) [85]
Может задача и его, но вот его рукодство уже сейчас можно сажать на большой срок, не дожидаясь последствий, а если это не сделать сейчас, то надо сажать руководство этого руководства.



पन्ने: 1 2 3 पूरी शाखा

फोरम: "मामले";
वर्तमान संग्रह: 2004.04.18;
डाउनलोड करें: [xml.tar.bz2];

ऊपर





मेमोरी: 0.91 एमबी
समय: 0.094 c
7-1076910434
अंधेरा आदमी
2004-02-16 08:47
2004.04.18
पीसी स्पीकर का गला कैसे काटें


3-1079967691
dimm22
2004-03-22 18:01
2004.04.18
इब्से में बड़ी संख्या में रिकॉर्ड स्थानांतरित करें। कमी की समस्या


8-1072441370
अर्ची गुदविन
2003-12-26 15:22
2004.04.18
घर का बना खिलाड़ी


1-1081069833
zif
2004-04-04 13:10
2004.04.18
किसी कारण से, फ़ाइल एक्सेस अस्वीकृत


3-1079610909
yura_2
2004-03-18 14:55
2004.04.18
किसी चर में अनुरोध में दिए गए मान को असाइन करें





अफ्रीकी अल्बानियन अरबी भाषा अर्मेनियाई आज़रबाइजानी बस्क बेलारूसी बल्गेरियाई कैटलन सरलीकृत चीनी) चीनी पारंपरिक) क्रोएशियाई चेक डेनिश डच अंग्रेज़ी एस्तोनियावासी फिलिपिनो फिनिश फ्रेंच
गैलिशियन् जॉर्जियाई जर्मन यूनानी हाईटियन यहूदी हिंदी हंगरी आइसलैंड का इन्डोनेशियाई आयरिश इतालवी जापानी कोरियाई लात्वीयावासी लिथुआनियाई मेसीडोनियन मलायी मोलतिज़ नार्वेजियन
फ़ारसी पोलिश पुर्तगाली रोमानियाई रूसी सर्बियाई स्लोवाक स्लोवेनियाई स्पेनिश स्वाहिली स्वीडिश थाई तुर्की यूक्रेनी उर्दू वियतनामी वेल्श यहूदी बंगाली बोस्नियाई
सिबुआनो एस्पेरांतो गुजराती हौसा हमोंग ईग्बो जावानीस कन्नड़ खमेर लाओ लैटिन माओरी मराठी मंगोलियन नेपाली पंजाबी सोमाली तामिल तेलुगु योरूबा
ज़ुलु
Английский Французский Немецкий Итальянский Португальский Русский Испанский