Самый шустрый сервер

← →
REA (2004-11-16 12:32) [0]

Есть необходимость работать с данными большого объема. Таблица (допустим) одна, 100 полей FLOAT, первичного ключа (допустим) нет.
Требуется запись в таблицу со скоростью 1 запись/сек. и как можно более быстрое чтение. Объем может достигать 2Гб, но проверить не могу т.к. вставка медленная - придется долго генерировать.
Какой сервер из семейства IB (Firebird, Yaffi...) можете посоветовать для такой задачи?

← →
Reindeer Moss Eater © (2004-11-16 12:38) [1]

Любой из перечисленных.

← →
Danilka © (2004-11-16 12:42) [2]

> первичного ключа (допустим) нет

Однако, такого, думаю, лучше не допускать никогда :))

← →
REA (2004-11-16 12:43) [3]

А все-таки. Есть ли у кого данные по быстродействию серверов (и их версий)?

← →
Reindeer Moss Eater © (2004-11-16 12:45) [4]

Первичный ключ иногда не нужен.

А все-таки. Есть ли у кого данные по быстродействию серверов (и их версий)?

Большее значение будут иметь характеристики тома где лежит бд, чем конкретная модель.

← →
REA (2004-11-16 12:46) [5]

>Однако, такого, думаю, лучше не допускать никогда :))

Если его сделать, то полагаю скорость записи может замедлиться на больших объемах. Учитывая, что при [Forced write = on] скорость и так оставляет желать лучшего (порядка 30 записей в секунду), то ИМХО отсутствие первичного ключа может как то улучшить ситуацию с вставкой.

← →
REA (2004-11-16 12:50) [6]

>Большее значение будут иметь характеристики тома где лежит бд, чем конкретная модель.

БД лежит локально, быстродействие компьютера и дисковой подсистемы среднее (Хотя диск похоже мало влияет - он его и не дергает при записи почти). Чтение впрочем возможно и по сети, но мне кажется, что быстродействие сервера будет ниже, чем пропускная способность сети 100Мбит (пока не пробовал).

Т.е. от типа сервера для данной задачи быстродействие не зависит?

← →
Fay © (2004-11-16 15:14) [7]

2 REA (16.11.04 12:50) [6]
А нафиг тебе чтение таблицы без первичного ключа?

← →
Fay © (2004-11-16 15:15) [8]

А ваще имеет смысл взять FB 1.51

← →
Reindeer Moss Eater © (2004-11-16 15:20) [9]

PK - не самоцель, а средство.
Если нет цели, которую надо достичь с помощью PK, то он не нужен.

← →
Соловьев © (2004-11-16 15:27) [10]

ПК - может состоять из всех полей

← →
Соловьев © (2004-11-16 15:29) [11]

В смысле его создавать не надо, а думать что уникальность определяется всем кортежем

← →
Fay © (2004-11-16 15:31) [12]

Чтобы так думать, надо иметь уверенность

← →
Соловьев © (2004-11-16 15:32) [13]

> Требуется запись в таблицу со скоростью 1 запись/сек

Ну так пишеим дату + время - вот тебе и уникальность.

← →
Sergey13 © (2004-11-16 15:38) [14]

2 Соловьев © & Fay ©
Зачем бороться за уникальность, если она не нужна? см [9] Reindeer Moss Eater © (16.11.04 15:20)

← →
Danilka © (2004-11-16 15:52) [15]

[14] Sergey13 © (16.11.04 15:38)
А нафига в БД неуникальные записи? :))

Есть какой-нибудь пример, когда ПК ненужен или (о-боже) вредит? Что-то я не могу предстравить..

← →
Danilka © (2004-11-16 15:54) [16]

Или просто пример случая, когда бывает необходима таблица, содержащая полностью одинаковые записи. И как в таком случае обратиться к какой-нибудь конкретной из них?

← →
Reindeer Moss Eater © (2004-11-16 15:59) [17]

Конечно есть.
Например простейшая таблица привилегий, которыми наделены пользователи:
create table user_rights(
user_id ...,
privilege_id ...
);

Систему интересует набор привилегий, которыми обладает юзер.
Системе не надо знать в какой конкретной записи содержится привилегия.

← →
Соловьев © (2004-11-16 16:04) [18]

> Системе не надо знать в какой конкретной записи содержится
> привилегия.

Но админу то надо! Чтобы забрать привелегию.

← →
Reindeer Moss Eater © (2004-11-16 16:07) [19]

Что бы забрать привилегию, админ напишет запрос
delete from user_rights wherer user_id = :uid and privilege_id = :pid

← →
Danilka © (2004-11-16 16:08) [20]

[17] Reindeer Moss Eater © (16.11.04 15:59)
Дык, здесь в качестве ПК будет две записи: "юзер" и "привелегия", кроме всего прочего, на уровне сервера будет обеспечен контроль - не будет записей с одинаковым набором юзер и привелегия

← →
Danilka © (2004-11-16 16:08) [21]

брр, не две записи, а составной ПК по двум полям

← →
Соловьев © (2004-11-16 16:09) [22]

> wherer user_id = :uid and privilege_id = :pid

Ну так вот и есть ПК - виртуальный правда :)

← →
Johnmen © (2004-11-16 16:12) [23]

>Reindeer Moss Eater © (16.11.04 15:59) [17]

Здесь нет одинаковых записей (по смыслу).
И ПК есть (опять же по смыслу).

← →
Reindeer Moss Eater © (2004-11-16 16:13) [24]

По смыслу может быть это и PK.
Но объект БД "primary key" в этом случае не нужен.
Он ничего нам не дает и ничего не решает.

← →
Johnmen © (2004-11-16 16:16) [25]

А что дает/решает ПК, напр., в таблице-справочнике ?

← →
Danilka © (2004-11-16 16:16) [26]

[24] Reindeer Moss Eater © (16.11.04 16:13)
решает. во-первых скорость доступа в запросе: wherer user_id = :uid and privilege_id = :pid
во-вторых, обеспечивает уникальность. :))

← →
Reindeer Moss Eater © (2004-11-16 16:25) [27]

1. Уникальность не нужна (будет сто одинаковых записей, но стократного увеличения привилегий не будет )

2. Скорость обеспечивается и обычным индексом.

PK здесь нафик не нужен.

← →
Соловьев © (2004-11-16 16:26) [28]

> 2. Скорость обеспечивается и обычным индексом.

Что влечет за собой замедление при вставке...

← →
Reindeer Moss Eater © (2004-11-16 16:27) [29]

А PK это "волшебство", работающее без индекса, и вставку не замедляет.
Так что ли?

← →
Соловьев © (2004-11-16 16:31) [30]

> А PK это "волшебство", работающее без индекса, и вставку
> не замедляет.
> Так что ли?

Замедляет конечно. Просто я так понял спор разгорелся из-за того, что ПК может и не существовать(я так понимал, что имелось ввиду - не существовать вообще). Как оказалось такого быть не могет. ПК всегда есть :)

← →
Reindeer Moss Eater © (2004-11-16 16:34) [31]

Не надо путать логические сущности и физические объекты.
PK есть не всегда.

← →
Соловьев © (2004-11-16 16:40) [32]

> Не надо путать логические сущности

Логически ПК должен быть. Потому как смысла в данных не будет
Физически да, может и не быть.

← →
Reindeer Moss Eater © (2004-11-16 16:42) [33]

В моей таблице нет физического PK.
И логического PK то же нет.
Потому что мне не надо уникально идентифицировать запись.

Тем не менее в таблице смысла - хоть отбавляй.

← →
Соловьев © (2004-11-16 16:47) [34]

> create table user_rights(
> user_id ...,
> privilege_id ...
> );

Эта таблица? ПК Вы сами привели в запросе

> delete from user_rights wherer user_id = :uid and privilege_id
> = :pid

← →
Reindeer Moss Eater © (2004-11-16 16:54) [35]

Это не ПК, это перечень полей.

← →
Sergey13 © (2004-11-16 17:59) [36]

2[15] Danilka © (16.11.04 15:52)
>А нафига в БД неуникальные записи? :))
Есть какой-нибудь пример, когда ПК ненужен или (о-боже) вредит? Что-то я не могу предстравить..

Ну например лог какого то устройства за сутки. Могут отслеживаться только крайние значения например. В сутках может быть сколько угодно одинаковых значений (прибор тупо отдает - база тупо пишет). Удаляется сразу посуточно т.е. where day=:day. Не редактируется. И что? Зачем ПК? Достаточно (но и необязательно 8-) индекса по суткам, ну и по искомой величине.

← →
vuk © (2004-11-16 18:04) [37]

to Reindeer Moss Eater © (16.11.04 16:25) [27]:
>1. Уникальность не нужна (будет сто одинаковых записей, но
>стократного увеличения привилегий не будет )
При выборках всегда select distinct писать будете? Сервер железный - ему по барабану? :o)

← →
Reindeer Moss Eater © (2004-11-16 21:41) [38]

Для того, чтобы узнать, есть ли у юзера привилегия Х я не буду писать distinct. Зачем он?
Exists после первого же найденного вхождения мне вернет true, либо не вернет false если привилегии нет вовсе.

exists - да. А если для отображения в клиенте?

Если будет требование отображать в клиенте список привилегий, я добавление привилегии реализую с предварительной проверкой на её существование.

Угу, PK в стиле "сделай сам". :o)
А отображать в конечном итоге все равно придется. Плавали, знаем.

Еще раз: PK мне здесь не нужен.
Что бы решить задачу разграничения прав пользователей первичный ключ мне не нужен.
Не нужен и все тут.

Отображение всех прав имеющихся у юзера - задача совсем иная.
И она вовсе не требует грида и тупого select * from ... where user_id = ...

Кроме того.
При открытии самого справочника привилегий при добавлении никто не запрещает открывать его с условием not exists
И те привилегии, что уже есть у юзера просто не попадут в выборку.

Все-таки пример случая, когда можно обойтись без ПК, от [36] Sergey13 © (16.11.04 17:59) более нагляден, чем пример с правами.
Эт понятно, что именно для этой задачи: "Что бы решить задачу разграничения прав пользователей первичный ключ мне не нужен"
Но я-бы делал такую таблицу с ПК.

В любом случае, имеет смысл индекс по полям user_id, privilege_id так в чем проблема сделать этот индекс первичным ключем?

по сабжу
у меня дейсвтия юзерей вынесены в спец. лог базу
размер 2.4 Gb
число записей в таблицах порядка 4.5 млн
никаких индексов разумеется
время добавления не измерял, но на 1-2 порядка меньше секунды
сервер MS SQL 2000

я не работал с IB , что, там все запущено ?

Довольно сильно. Но многие интербэёсники этого "не замечают" 8)

:-)

Речь, насколько я понял, идет о реляционной базе данных? Тогда откуда ростут ноги фразы "первичный индекс не нужен"? Даже если Вам лень создавать первичный индекс, СУБД все равно его создаст неявно. По той просто причине, что все записи в БД должны быть уникальными. Это аксиома реляционной модели баз данных.

>>сервер MS SQL 2000
Я понимаю стремление MS облегчить труд разработчиков (в виде автоматического создания первичных индексов), но это облегчение порой выходит боком в виде утверждения, что первичный индекс в реляционных базах данных необязателен.

2 Danilka © (17.11.04 13:20) [50]

> А что конкретно там сильно запущено? Просто интересно.

На мой взгляд, он дюже тормозной. То, что со мной многие не согласны, мне уже известно.

2 Rem © (17.11.04 13:39) [51]

> Я понимаю стремление MS облегчить труд разработчиков (в
> виде автоматического создания первичных индексов),

Вас ввели в заблуждение.

Rem © (17.11.04 13:39) [51]

> Даже если Вам лень создавать первичный индекс, СУБД все
> равно его создаст неявно.

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

← →
REA (2004-11-18 17:22) [54]

>А нафиг тебе чтение таблицы без первичного ключа?

Можно сделать первичный, но мне и просто индекса будет достаточно. Это просто набор данных. И изменять их потом с высокой долей вероятности не будут.

По сабжу:
Выборка на FB-1 и 1.5 = 22.5сек и 9.5 сек соответственно.
Тест проводился с одинаковыми параметрами на небольшой базе (200Мб).
Продолжим сравнивать...

Самый шустрый сервер Найти похожие ветки