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

← →
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. Скорость обеспечивается и обычным индексом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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