IB и скорость

← →
Ura (2002-02-01 15:55) [0]

Сколько запросов может обрабатывать IB6. Где посмотреть или кто-то сам тестил? У меня будет 20 машин * по 10 запросов - на чтение + 1 запрос на запись = MAX . База ~ 1 - 20 МГб.

← →
drpass (2002-02-01 16:45) [1]

Справится с не одним десятком таких баз одновременно, поверь

← →
Romkin (2002-02-01 16:49) [2]

На какоую аппаратную часть поставишь - так и будет, а твое по-моему потянет и P100
см http://www.cvalde.com/WhoUsesIB.htm

← →
Johnmen (2002-02-01 17:14) [3]

В любой книге по IB в преамбуле пишутся тех.характеристики сервака...
Я помню примерно (в одной из старых книжек) : ...поддерживается одновременное обслуживание порядка 100 клиентов без заметной перегрузки [сервер на 486DX-66]...

← →
Fareader (2002-02-01 17:26) [4]

Смотря как спроектировать базу и запросы ;). При "правильном" подходе можно и одним пользователемсервер завалить.

← →
Johnmen (2002-02-01 17:36) [5]

>>>Fareader © : очень справедливо подмечено !

← →
Ura (2002-02-01 18:14) [6]

База нормальная 120 таблиц. Но большие только таблица людей мах 10 млн людей (в Беларусии больше не живет ;-)) и адресов ~ 5 млн адресов + 1 Таблица для записи на 300 тыс. Запросы все маленькие. Ну на людей и адреса пока думаем как разбить чтобы не лопатить все сразу. (Может по алфавиту)
// Это самы МАХ случай базы реально 100 тыс людей и 25 тыс адресов. + 1 Таблица для записи на 300 тыс

← →
Desdechado (2002-02-01 20:18) [7]

все зависит от железа (если БД и запросы правильно спроектированы)

← →
evgeg (2002-02-01 21:59) [8]

> 1 - 20 МГб
микробаза какая-то, ты в оценках размера не ошибся?

← →
Фэ (2002-02-01 23:44) [9]

Думаю, что он сильно ошибся.
При 10 лимонах людей и 5 л. адресов база за 1G вылетит.

← →
Фэ (2002-02-01 23:47) [10]

Хотя при 100 тыс людей и 25 тыс адресов. + 1 Таблица для записи на 300 тыс
около 30M будет

← →
Ura (2002-02-04 11:36) [11]

Просто объем будет расти постепенно, я думаю на одной точке (уровень района (~100 тыс чел)) не превысит этого предела, а вышестоящий уровень - пока не мы разрабатываем ;-)). Я думаю IB выше не потянет. Но жизнь покажет.

← →
Fareader (2002-02-04 11:51) [12]

У меня база за 6 месяцев с 2 метров выросла до 200 и ничего, нормально работает

← →
Ura (2002-02-04 12:20) [13]

Все ответы вселяют надежду. ;-)).

← →
Besa (2002-02-04 14:02) [14]

2 Ura
База нормальная 120 таблиц. Но большие только таблица людей мах 10 млн людей (в Беларусии больше не живет ;-)) и адресов ~ 5 млн адресов + 1 Таблица для записи на 300 тыс. Запросы все маленькие.

по своему опыту могу сказать, что IB может не потянуть такую БД
даже на уровне района...
у нас все крутится на Informix Dynamic Server v7.30
при 110 таблицах и в среднем 120 тыс населения в год по району
собирается инфа по каждому году(зрпл, кл-во мес. и дней и др в месяц на каждого зарегистрированого)
и то многие запросы выполняются примерно 15-20 минут(select по 9-ти таблицам)
загрузка всей БД из резервной копии по времени примерно час и больше. правда одна таблица на 8 млн записей. :)
имхо, если только создаете то ориентируйтесь на что-то серьезное типа Informix or Oracle

2 Ura (04.02.02 12:20)
Все ответы вселяют надежду. ;-)).

не сильно я внушил отчаенье? :)

← →
Ray (2002-02-04 14:34) [15]

Ну не обязательно сразу на Oracle.
При пмравильном проектировании потянет и IB, хотя я все же советую посерьезнее. Можно MS SQL 7.0 отлично справиться, унас на заводе стоит 6.5 и 7.0, на первом все базы уже достигли 15 гиг 8-), правда сервачек тормозно P2 333, поэтому и запросы иногда медленно идут. Но вот второй сервак более крутой там 7.0 стоит и запросыс просто летают, там обьем тож не хилый около 7 гиг.

← →
drpass (2002-02-04 14:48) [16]

У меня в основной таблице около 150 тыс записей, сервер - Celeron 633. Запросами, правда, не перегружен, все делает мгновенно. Я пробовал MS SQL 2000, он мне жутко не понравился, потому что сразу сожрал всю память, которую нашел :) IB (во всяком случае, на таком количестве записей)работает намного быстрее, причем практически не чувствуется загрузка процессора и памяти.

← →
Ura (2002-02-04 15:53) [17]

> Besa ©
Система похожая, но все данные только за 1 год...
но твое
> 15-20 минут(select по 9-ти таблицам)
меня расстроило.... :-(
Сомнение по поводу IB у меня есть. Я писал и тестил базу на 40МГб но там было всего 11 таблиц. 10 маленькие и одна НУ очень большая. По моему в IB проблема с кешем т.е. если бы его настроить. Пока будем бороться. Индексы там всякие и т.д.

Для остальных...
Я не пробовал остальные БД сильно. Мелкие проекты. Не нужно было и очень ругался, когда просили сильнее СУБД ставить. Теперь жалею... Было бы не плохо определить ниши под СУБД. ХОТЯ БЫ по разговором с разработчиками. Нигде не могу найти нормального сравнения СУБД. Одна реклама без КОНКРЕТНОГО приложения проекта. А человек который работал бы с 3-5 различными СУБД найти ОЧЕНЬ сложно. Специализация елки-палки...

← →
Praco (2002-02-04 16:15) [18]

Сравнение
Borland InterBase 4.x, Sybase SQL Server и Microsoft SQL Server

http://delphiplus.narod.ru/articles/Comparer.htm#1.%20INTRODUCTION

← →
Johnny Smith (2002-02-04 16:35) [19]

Мой тебе добрый совет - если база а) актуальна (то есть не для игрушек) и б) разрастется до больших размеров, то бросай этот IB. Говорю как человек, который с ним поработал изрядно. Да, 150 тыс. записей для него не страшно, но когда перевалит за 1-2 миллиона, вот тогда...
Пример (не называю организацию). Сервак - двухпроцессорный. IB 5.6 (купленный!!!). База - 8 ГБ. Так вот, некоторые отчеты строятся в течение ночи (какие там 15-20 минут). Причем резкий спад производительности произошел, когда база перевалила за 2 ГБ

← →
Besa (2002-02-04 16:57) [20]

2 Ura (04.02.02 15:53)
Так по 9 таблицам среди которых одна на 3 млн. записей и в основном поиск идет по ней по 4-м полям :)

← →
BlankAlex (2002-02-04 17:53) [21]

На сервере www.ibexpert.com есть шикарная прога IB Expert. Для советских она халявная. SQL Explorer отдыхает. Так там после выполнения запроса можно посмотреть не только время Prepare, Exec и т.д. , но и планы, количество индексированных чтений, записей и ... Короче супер, а не программа. У нас вся контора ей пользуется с моей подачи

← →
Фэ (2002-02-04 21:15) [22]

Как всегда все определяется разумным компромисом "железо-софт" и искусством программиста "выжать" из возможностей все возможное и умением обходить сложности и избегать тупиков, т.е. классом - в конце концов.
Об это уже здесь сказано.
Нет, ну что-такое СЕРВЕР- Celeron-633 - о чем это Вы ?
О локальной или на 5 шт юзеров базе размером 10М ?
Пойдет, однако.
А лучше..
База на 1-3G, 100-200 таблиц: локалка на 100М со swith-ами 3Com,Lantech, сервер 900-1100М P-III EB, а лучше Tualatin 1,2G, диски: два системных 20G 7200 и два 20G на базы под RAID 0, а лучше аппаратный RAID 0, OS Win2000/Linux, RAM 256+64*Users,
материнка ASUS и иже, а лучше готовый сервак IBM, еще вариант
Win 2000 Advanced Server(Terminal) на одном серваке c App, на втором связанном Гигабитом с первым IB и базы, а клиентские места - почти терминалы, опять же даже по модему работа возможна.
Словом, проектировать надо, а не исходить из наличия завалявшегося 368DX и желания обслужить всю Белоруссию.

← →
kaif (2002-02-05 01:29) [23]

Я как-то сгенерировал 1 млн. записей в 1 таблице на IB5.0.
Генерация заняла 40 мин на Pentium MMX 166. Запросы типа простых SELECT * WHERE UPPER(NAME) LIKE "%ВАСЯ%" потом занимали не более 1 сек. Конечно, если не делать FETCH из 1 млн. записей.
IMHO:
Легко рекомендовать ORACLE тому, кому деньги некуда девать.
:)
Рекомендую не спрашивать по форумам, а просто сгенерировать (можно для этого хранимую процедуру написать) свой миллион и посмотреть, что получится. Я всегда заполняю базу сгенерированными значениями, а иначе, как узнать, где у тебя кривизна в запросах? Например, я замечал, что индексы по DATE в IB5 крайне медленно работали (в 100 раз медленнее, чем по INTEGER). И мне приходилось иногда PLAN вручную вписывать. Рекомендую еще опираться на реальные перспективы. Если планируется иметь 100тыс. в таблице 1 и 1,5тыс в таблице 2, то и генерить нужно именно столько. А о будущем лучше не думать. "Заботьтесь о дне сегодняшнем. Завтрашний сам позаботится о себе."И.Х. Евангелие от Иоанна, стих не помню :))

← →
Леша (2002-02-05 04:54) [24]

Полемика развернулась, и не малая. Добавлю некоторык интересные факты из своего опыта. Изначально базу проектировал на IB 6.0, вообщем то неплохая вещь, хотя и синтаксис бедноват. Но вот когда пришло время собирать отчеты, весьма объемные и сложные то выборки шли минут по 15-20. Причем поскольку это отчет, данные не урежешь, но и сократить время выборок иным способом не как не получалось. Да еще когда надо получить подобных отчетов штук 100, времени уходило много. На таких же выборках SQL 2000 сразу давал преимущество по скорости выборки раз 8-10, да плюс еще синтаксические конструкции побогаче. В результате переписал базу на SQL 2000 и пока не жалею, хотя работа триггеров реализована не лучшем образом.

← →
Фэ (2002-02-05 09:50) [25]

Есть два основных способа организации базы - ориентрованный на ввод и ориентированный на отчеты. Можно комбинировать.
Есть два основных способа исполнения бизнес-логики: серверный, через ХП триггеры и клиентский и их комбинация.
Никто и не говорит, что все просто.
А совет - генерить тестовые данные - дельный.
Для нормальных проектов такой документ как ПМ (программа и методика испытаний никто не отменял.)

← →
Ura (2002-02-05 11:29) [26]

Спасибо всем кто откликнулся :-)
Мои причины использовать IB 6.0
1. Простота в обслуживании - поставил и забыл
- не НУЖНО ДЕРЖАТЬ АДМИНА это условие заказчика
2. ОПЕН РЕСУРС - БЕЛАРУСЬ не очень богатая страна, но когда нибудь и здесь примут закон о ПИРАТСТВЕ.(А это тема отдельной дискусии). И мне не хотелось бы что бы меня вспоминали плохими словоми. Хотя, по моему, начальство организации этого не оценит.
3. Машина заявленная на сервер CELERON 300 + 128 МГб

Из всего вышесказанного сделал два вывода
1. Сгенерировать тестовую базу и оттестить, но это будет только к лету. Раскажу в форуме после тестов.
2. Попробую разгрузить сервак, часть основную справочных данных закачивать на клиента, и через механизм сообщений IB -> слиетн обновлять эту часть по сообщению об изменении (должно случаться редко)
3. Попробовать паралельно и сделать базу на ???

← →
Sergey13 (2002-02-05 11:31) [27]

2Ura
>по 10 запросов - на чтение + 1 запрос на запись
А за какое время? 1 секунда, 1 минута, 1 час, 1 день? Если 1 минута а
>База нормальная 120 таблиц
то как ты уложишься в 11 запросов (12-ый отсекать будешь? 8-)? Там же одних справочников несколько десятков будет. А их тоже надо на клиента подтаскивать периодически. А индексы перестраивать для 10млн-ой таблицы(а индексов по людям я думаю будет не мало)? А связь между 20 машинами какая? Не, ты как хочешь, но я бы посоветовал что нибудь покруче чем IB. Он хорош для склада, чтоб на админа не тратиться. Хотя ТЕОРЕТИЧЕСКИ потянет и это. Только шею потом будут мылить ПРАКТИЧЕСКИ. Я бы хранение и обработку 10 млн записей по ЛЮДЯМ (они такие вредные 8-) IB не доверил.

>Просто объем будет расти постепенно

И вот на 3 миллионе ты решишь, что пора менять все 8-(.
А ты пробовал перевести данные с одной СУБД на другую? А работу с данными прерывать нельзя. Это такой геморой!!! С одними особенностями SQL заморишся. Поэтому лучше сразу заложиться на серьезную СУБД. Кстати на новый проект денег выбить НАМНОГО проще чем на изменение старого.

← →
Ura (2002-02-05 12:23) [28]

Sergey13 ©
> по 10 запросов - на чтение + 1 запрос на запись
Это в минуту, но только * 20 машин, это максимальная нагрузка, это просто подсчитано...
По людям реально 100 тыс+ где-то до 300 тыс, И КАДЖЫЙ год собираються базу заменять на новую. Сказали срок хранения базы 5 лет.

← →
Sergey13 (2002-02-08 11:42) [29]

>Это в минуту, но только * 20 машин, это максимальная нагрузка, это просто подсчитано...
Кем, как, по какой методике? Если, как я понял, пока нет ни базы ни приложения. А если ничего нет то такой подсчет - филькина грамота. У меня тоже "нормальная база" примерно с твоими параметрами. Так вот при ~30-40 открытых сессиях(значит реально долбят по клавам человек 10-15) у меня иногда бывает больше 50 запросов в СЕКУНДУ. И это не предел. Просто я не постоянно наблюдаю за базой в он-лайне.
> И КАДЖЫЙ год собираються базу заменять на новую. Сказали срок хранения базы 5 лет.
Ни понял. Это тебе наверное на ОВОЩНОЙ базе сказали. Зачем менять, если можно хранить в холодильнике :-)

← →
Ura (2002-02-08 12:06) [30]

> Sergey13 ©
Хранение базы 5лет - это требование налоговой. ФАКТ. А менять каждый год базы это по СУЩЕСТВУЮЩЕЙ технологии. ФАКТ. Но с ним боремься... ;-)
А нагрузка ;-), это уже проверено. Есть часть базы, есть уже прога работающая с этой частью. Сейчас пробиваем бумагу на использования... И проверено это на 5 раб местах... Каждая чать базы независимая. Я бы их вообще разделил на отдельный базы, но справочники общие и общий сбор инфомации + log +... Просто пока справочники ненаросли, а некоторые (самые больши - не подключены) а данные там болжны быть реальные...

← →
kaif (2002-02-08 14:26) [31]

Средний поток 10 запросов в минут - среднее значение. Если запросы друг от друга, как события, не зависят, то реально это будет вплоть до 10 плюс минус 3*корень квадратный из 10. То есть где-то 10 +- 10 = 0..20 запросов в минуту. Как правило, события будут пачковаться. То есть пару минут вообще ничего не происходит, а затем... вдруг навалило сразу 20 запросов. Это Пуассон...

← →
Ura (2002-02-08 15:36) [32]

> kaif ©
А ВОТ про математику Я и забыл. Заработался. Пересчитаю. Спасибо. А то как темный человек... ;-)
Осталось только вывести зависимости: Объем БД - Кол запросов (Или закон)- Объем ср.одработ данных в 1 запросе() - СУБД = Индекс скорости. Осталось построить графики ;-))

IB и скорость Найти похожие ветки