Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Какую СУБД выбрать?

Страницы: < 1 2 3 4 5 >
WondeRu © (2004-03-18 09:53:00)
Есть следующие задачи, которая должна обслуживать БД:
1. Клиентские рабочие места - 20-30
2. До 400 транзакций в сек.
3. Отказоустойчивось
4. Триггеры, библиотеки расширения и т.п.
5. Недорогая
6. Windows/Linux

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

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

WondeRu (2004-03-23 11:15:00) [22]
2Sergey13 © (23.03.04 10:56) [65]
Точно сказать не могу, не я этим занимаюсь)

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

WondeRu (2004-03-23 10:54:00) [24]
>Sergey13 © (23.03.04 10:48) [63]
Могу написать 0.5099% ;-) Сам не считал, но вероятность какая-то все же присутствует! Аудитом такой хр.. (вероятностей) я еще не занимался!

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

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

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

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

roottim (2004-03-23 10:39:00) [27]
еще разз...
>уже радость
вероятно
>А 40 событий в секунду - вероятность такого исхода порядка 0.5%

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

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

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

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

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

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

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

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

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

WondeRu (2004-03-23 10:04:00) [33]
машины хоть пеньки 3ГГц, ет не проблема! Но FB устарел как класс СУБД! Поэтому и есть нужда перейти к чему-нибудь более совершенному! А 40 событий в секунду - вероятность такого исхода порядка 0.5%! События записываются простыми инсертами, но при этом параллельно действует логика, которая реагирует на событие и также обращается к базе для анализа предыдущих событий!

Sergey13 (2004-03-23 09:39:00) [34]
30*16*300=144000 событий в час=40событий в секунду
тоже не слабо, если я ничего не напутал.
Что за событие, скока чего пишется? Зачем нужны результаты? Как часто и по каким критериям инфа читается из базы? Написал бы нормально про задачу. А то гадание на кофейной гуще какое то.

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

WondeRu (2004-03-23 09:03:00) [35]
Люди, железяки же не осциллографы, это был самый худший вариант 30х16! А так в час тройку сотен событий от устройства придет уже радость))) Но пиковая нагрузка должна присутствовать на крайний случай, все-таки же почти технологический процесс, т.е. самый край задержки 5 сек.!

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

roottim (2004-03-22 13:57:00) [37]
2Petr V. Abramov © (22.03.04 13:36) [50]
да я думаю что не так все грустно...
он привел пиковую нагрузку.. 16 устроиств на клиента
а реально-то думаю меньше... и данные "думаю" снимаются не милисекундами...
- хотя ситуация когда все устр-ва одновременно будут писать в базу возможна... только все зависит от минимального времени транзакции... Оракле сдесь имеет плюс в том что одновременная вставка в таблицу не вызовет колизий... наверно и все...

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

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

roottim (2004-03-22 13:28:00) [39]
2Petr V. Abramov © (22.03.04 12:57) [47]
это тоже вариант... формировать файлы с опр. структурой и писать значения напрямую туда... а затем переносить (если конечно есть перерыв во времени снятий данных..
в этом случае любая удобная для обработки результатов база подойдет.. ну а если напрямую туда... то наверно всеже оракул

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

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »