Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
можно ли вообще в базах данных добиться хорошой скорости.

есть простая таблица два поля.
id -автоинкримент
и varchar(10000)

нужно добавлять в таблицу строки при этом проверять если такая строка есть то ее не добавлять. а получать этот id

Индексы использовать нельзя так как данные могут быть 10000
Далек от тригеров хранимых процедур.
Делаю просто

select id from table where text='some text'
если ничего не найдено добавляю
insert into table (text) values ('some text');
если нет то беру найденный id

Скорость просто ужастная.

При использование алгоритма b-tree disk based дерева скорость практически моментальная. Но это же не база данных а творчество как быть?

Закинуть все данные а потом просто group и удалить повторения нельзя так как при каждом добавлении необходимо id получать.
4 фев 05, 17:25    [1301424]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
А что за СУБД?

Для длинных строк можно вычислять хэш-код и уже его индексировать.
4 фев 05, 17:35    [1301452]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вариант 1:
Хранить строки в компрессионном виде, 10кб текста будут неплохо жаться.

Вариант 2:
Сделать вычисляемое поле c_Text как LEFT(Text, 10) и нацепить на него индекс. Искать как:
SELECT id
FROM Table
WHERE c_Text = Left(SearchValue, 10) AND Text = SearchValue

Вариант 3:
Если записей не сильно много, просто сделать компресионный индекс на поле Text.

Вариант 4:
Сделать хэш на строку и индексировать его.

ну и возможно еще множество вариантов в зависимости от возможностей той или иной СУБД.
4 фев 05, 17:38    [1301464]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
А еще в SQL Server есть Full Text Search, в других серверах - другие названия, но смысл тот же.

PS. Правда в SQL Server нельзя задать varchar(10000), это только text.
4 фев 05, 17:47    [1301500]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
>А что за СУБД?
или самописная или что то типа firebird бесплатное.
Задача для анализа логов.

>Вариант 1:
>Хранить строки в компрессионном виде, 10кб текста будут неплохо жаться.
в 99% размер строки меньше 100 символов.

>Вариант 2:
>Сделать вычисляемое поле c_Text как LEFT(Text, 10) и нацепить на него >индекс. Искать как:
>SELECT id
>FROM Table
>WHERE c_Text = Left(SearchValue, 10) AND Text = SearchValue
В 99% начало строк идентично кончовка в основном разная.
логи. пример www.site.ru/1.html www.site.ru/2.html и.т.д.

>Вариант 3:
>Если записей не сильно много, просто сделать компресионный индекс на поле >Text.
Данных много но много повторений а вот что за хитрый индекс?

>Вариант 4:
>Сделать хэш на строку и индексировать его.
Вариант.

Спасибо.
4 фев 05, 17:48    [1301507]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
PS. Правда в SQL Server нельзя задать varchar(10000), это только text.

Varchar это довольно условный выбор. просто размер от 100 до 2000-10000 символов в строке
4 фев 05, 17:52    [1301522]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ynike

или самописная или что то типа firebird бесплатное.

Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще? Чтобы те у кого не самописные, могли бы знать что не зря платят деньги?
Иначе бы все были с самописными, если бы они ни чем не хуже остальных были.
4 фев 05, 17:56    [1301530]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
vadiminfo

Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще?


B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в самописной базе. Такова уж природа B-Tree индекса...
4 фев 05, 17:59    [1301534]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
>Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же >еще? Чтобы те у кого не самописные, могли бы знать что не зря платят >деньги?
>Иначе бы все были с самописными, если бы они ни чем не хуже остальных >были.

нет спору нет что самописные это плохо.
просто задача такая что все наворты которые есть в базах попросту не нужны и самописная база данных очень хорошо работало до тех пор пок ане было необходимости проводить анализа данных которые не умещаються в памяти.
даже c hash и b-tree

>B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в >самописной базе. Такова уж природа B-Tree индекса...
хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird?
4 фев 05, 18:07    [1301552]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ynike
>Вариант 1:
>Хранить строки в компрессионном виде, 10кб текста будут неплохо жаться.
в 99% размер строки меньше 100 символов.

Согласен, смысла нет.

ynike

>Вариант 2:
>Сделать вычисляемое поле c_Text как LEFT(Text, 10) и нацепить на него >индекс. Искать как:
>SELECT id
>FROM Table
>WHERE c_Text = Left(SearchValue, 10) AND Text = SearchValue
В 99% начало строк идентично кончовка в основном разная.
логи. пример www.site.ru/1.html www.site.ru/2.html и.т.д.

Никто не мешает сделать вычисляемое поле, как LEFT (SearchValue, 5) || RIGHT(SearchValue, 5)

ynike

>Вариант 3:
>Если записей не сильно много, просто сделать компресионный индекс на поле >Text.
Данных много но много повторений а вот что за хитрый индекс?

В каждой СУБД по разному. ASA например, автоматом организует B-Tree, comressed B-Tree или Hash B-Tree индекс, ориентируясь на размеры и типы полей индексов (плавающие, не плавающие), а так же размер страницы БД, т.е. определяя, какой из способов организации физического хранения индекса будет наиболее оптимальным для хранения и быстрого доступа по индексу.

ynike

>Вариант 4:
>Сделать хэш на строку и индексировать его.
Вариант.

То же самое, что и Hash B-Tree индексы в ASA. Однако в документации написано, что такой способ доступа к данным не гарантирует уникальности при хранении строк и СУБД при поиске по такому индексу будет вынуждена после нахождения в индексе строки по хэш-коду физически прочитать все найденные записи из таблицы и провести полное сравнение с искомой строкой.
4 фев 05, 18:20    [1301581]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ynike
Но это же не база данных а творчество как быть?

С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) этот сервер также является самопальным. Вас это не отпугивает?
4 фев 05, 18:27    [1301601]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
ynike

хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird?


В вашем случае лучше использовать hash.

Можно ещё разбить строку на две части: varchar(200) и varchar(8800). И сделать индекс по первой части строки, а на вторую сделать hash-code. В 99% случаев это будет работать очень быстро.

Понятно, что существующие СУБД имеют некоторые ограничения, которые в Вашем случае придётся обойти. Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой.
4 фев 05, 18:33    [1301617]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
>С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) >этот сервер также является самопальным. Вас это не отпугивает?
еще больше пугает цена mssql oracle, sybase
задача имеет самые простые запросы нет никаких транзакций бекапов многопользовательской работы в основном select но быстрый надо :(

>Можно ещё разбить строку на две части: varchar(200) и varchar(8800). И >сделать индекс по первой части строки, а на вторую сделать hash-code. В >99% случаев это будет работать очень быстро.
можно поробывать хотя выглядит это пролематично.

Спасибо всем за help.
4 фев 05, 18:41    [1301632]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
www.fun4me.narod.ru

Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой.

Про задачу из этого топика сказать ничего не могу, поскольку думаю, что нужно проводить исследования для долгих запросов. Но в общем случае самого факта B-tree индекс везде B-tree индекс не достаточно, чтобы все было одинаковымпо производительности. Например, Оракл 9.2.0.1.0 (винды) и 9.2.0.4.0 (линукс) уже отличаются, например, при сканировании индекса по диапазону, т.е для не равенств. Точнее по первому полю равенство, а второе из диапазона (композитный индекс). У первого я смог добиться сканирования только поставив поле для диапозона первым, а у второго вторым и чуть ли не на 1.3 быстрее выполнялся запрос, когда по диапазону вторым стоит. Так что быстерее даже внутри одного продукта с разными версиями. Я уже не говорю про сжатия индексов, упаравлени заполнением блоков, что влияет на кол-во чтений, фрагментацию таблиц, мат представления и др разные средства, которые есть в продвинутых СУБД для того, чтобы пытаться получить максимальную скорость на данном железе.
4 фев 05, 21:22    [1301871]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
Минимальные иследования показали что прим код.
таблица.



for i:=1 to 100000 do
begin
str:='123.234.'+IntToStr(i);
hash:=CalcHash(pointer(str),length(str));

ZQuery1.SQL.Clear;
ZQuery1.SQL.Add('select id from table1 where (hash=:hash)');
ZQuery1.Params.ParamByName('hash').Value:=hash;
ZQuery1.Open;
count:=ZQuery1.RecordCount;
ZQuery1.Close;

if (count=0) then
begin
ZQuery1.SQL.Clear;
ZQuery1.SQL.Add('insert into table1 (text,hash) values (:text,:hash);');
ZQuery1.Params.ParamByName('text').Value:=str;
ZQuery1.Params.ParamByName('hash').Value:=hash;
ZQuery1.ExecSQL;
end;

end;

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


В 20 раз медленне на mysql чем аналогичный но без баз :(
про firebird я уже молчу Жуткий тормоз....
при тестах 1 раз испортил таблицу
а после выполнения команды delete from table (в табличке 100,000 записей 8мег всего на диске)
Вообще завис пошел под удаление и долгие маты........

Вообщем обида на базы данных для этой задачи :(
4 фев 05, 21:56    [1301898]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
база была


id -integer;
hash-integer; hash-index.
text-longtext, (varchar(100)) text, даже если индекс по полю этому делать все равно. (хотя индекс не выходит)
тоесть решение с разбивкой на hash или на первые 200 символов делать индект тоже плохо.
4 фев 05, 22:01    [1301902]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Самописный код для решения узких задач может быть гораздо эффективней по времени работы( не написания кода!) чем стандартная СУБД.Ничего удивительного
4 фев 05, 22:56    [1301948]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
если других (более сложных )запросов не предвидится, посмотрите berkeley db к примеру.
5 фев 05, 00:14    [1302014]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
ynike
Member

Откуда:
Сообщений: 39
berkeley db к примеру.

А под windows у них верисии вроде то нет ....
5 фев 05, 01:13    [1302044]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
c127
Guest
2 www.fun4me.narod.ru

>B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в самописной базе. Такова уж природа B-Tree индекса...

Это если он есть, а вообще-то его может и не быть. Мало ли бывает чудес в самописных базах.
5 фев 05, 02:00    [1302057]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785
ynike

for i:=1 to 100000 do
begin
str:='123.234.'+IntToStr(i);
hash:=CalcHash(pointer(str),length(str));

ZQuery1.SQL.Clear;
ZQuery1.SQL.Add('select id from table1 where (hash=:hash)');
ZQuery1.Params.ParamByName('hash').Value:=hash;
ZQuery1.Open;
count:=ZQuery1.RecordCount;
ZQuery1.Close;

if (count=0) then
begin
ZQuery1.SQL.Clear;
ZQuery1.SQL.Add('insert into table1 (text,hash) values (:text,:hash);');
ZQuery1.Params.ParamByName('text').Value:=str;
ZQuery1.Params.ParamByName('hash').Value:=hash;
ZQuery1.ExecSQL;
end;


Пара ремарок буквально:
1) Выполнение на клиенте кода
count:=ZQuery1.RecordCount;
в большинстве случаев приведет к fetch на клиента всех записей, удовлетворяющих запросу. Если, конечно, ZQuery - это не какой-то суперинтеллектуальный объект, умеющих самостоятельно исправлять SQL-запросы по необходимости.
2) Насколько я понимаю, то, что hash1 == hash2, еще не гарантирует, что text1 == text2, а всего лишь указывает на возможность этого (то есть одинаковые хэши могут быть и у разных текстов). Соответственно и проверка на count==0 не имеет смысла - нужно проверять все записи, у которых хэш совпадает. Соответственно на клиента уйдут и все поля text с соответствующими хэшами.

Вывод (ИМХО): правильнее это все было бы сделать на сервере, через хранимую процедуру. Тогда и SQL не надо будет переписывать на каждый чих (BTW RTFM на тему Query.Prepare), да и, возможно, до кучи можно будет несколько соптимизировать алгоритм и сделать его более понятным для сервера. А то получается его бедного пинают, а логика работы-то вся на клиенте, он про нее ни сном, ни духом... :)

PS Кстати, а "очень тормозно" - это сколько по времени в данном случае? Секунды? Минуты? Часы? ;)
5 фев 05, 03:20    [1302084]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли вообще в базах данных добиться хорошой скорости  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ynike
berkeley db к примеру.

А под windows у них верисии вроде то нет ....


Berkeley DB, the most widely-used developer database in the world, is open source and runs on all major operating systems, including embedded Linux, Linux, MacOS X, QNX, UNIX, VxWorks and Windows.
5 фев 05, 09:38    [1302128]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить