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

← →
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]

Off
> 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 V. Abramov © (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 V. Abramov © (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]

Люди, железяки же не осциллографы, это был самый худший вариант 30х16! А так в час тройку сотен событий от устройства придет уже радость))) Но пиковая нагрузка должна присутствовать на крайний случай, все-таки же почти технологический процесс, т.е. самый край задержки 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]

машины хоть пеньки 3ГГц, ет не проблема! Но FB устарел как класс СУБД! Поэтому и есть нужда перейти к чему-нибудь более совершенному! А 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]

>Sergey13 © (23.03.04 10:48) [63]
Могу написать 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 © (23.03.04 11:25) [67]
Oracle-то я ставил, но чисто в образовательных целях.

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

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

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

MSSQL и Oracle. 8)

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

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

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

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

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

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

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

Какую СУБД выбрать? Найти похожие ветки