powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Можно ли вообще в базах данных добиться хорошой скорости
22 сообщений из 22, страница 1 из 1
Можно ли вообще в базах данных добиться хорошой скорости
    #32902024
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
можно ли вообще в базах данных добиться хорошой скорости.

есть простая таблица два поля.
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 получать.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902042
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А что за СУБД?

Для длинных строк можно вычислять хэш-код и уже его индексировать.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902050
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вариант 1:
Хранить строки в компрессионном виде, 10кб текста будут неплохо жаться.

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

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

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

ну и возможно еще множество вариантов в зависимости от возможностей той или иной СУБД.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902074
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А еще в SQL Server есть Full Text Search, в других серверах - другие названия, но смысл тот же.

PS. Правда в SQL Server нельзя задать varchar(10000), это только text.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902080
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>А что за СУБД?
или самописная или что то типа 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:
>Сделать хэш на строку и индексировать его.
Вариант.

Спасибо.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902089
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PS. Правда в SQL Server нельзя задать varchar(10000), это только text.

Varchar это довольно условный выбор. просто размер от 100 до 2000-10000 символов в строке
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902096
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ynike
или самописная или что то типа firebird бесплатное.

Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще? Чтобы те у кого не самописные, могли бы знать что не зря платят деньги?
Иначе бы все были с самописными, если бы они ни чем не хуже остальных были.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902100
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo
Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще?

B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в самописной базе. Такова уж природа B-Tree индекса...
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902111
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же >еще? Чтобы те у кого не самописные, могли бы знать что не зря платят >деньги?
>Иначе бы все были с самописными, если бы они ни чем не хуже остальных >были.

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

>B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в >самописной базе. Такова уж природа B-Tree индекса...
хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird?
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902134
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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. Однако в документации написано, что такой способ доступа к данным не гарантирует уникальности при хранении строк и СУБД при поиске по такому индексу будет вынуждена после нахождения в индексе строки по хэш-коду физически прочитать все найденные записи из таблицы и провести полное сравнение с искомой строкой.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902150
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ynikeНо это же не база данных а творчество как быть?
С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) этот сервер также является самопальным. Вас это не отпугивает?
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902161
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ynike
хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird?

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

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

Понятно, что существующие СУБД имеют некоторые ограничения, которые в Вашем случае придётся обойти. Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902174
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) >этот сервер также является самопальным. Вас это не отпугивает?
еще больше пугает цена mssql oracle, sybase
задача имеет самые простые запросы нет никаких транзакций бекапов многопользовательской работы в основном select но быстрый надо :(

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

Спасибо всем за help.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902323
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ru
Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой.

Про задачу из этого топика сказать ничего не могу, поскольку думаю, что нужно проводить исследования для долгих запросов. Но в общем случае самого факта B-tree индекс везде B-tree индекс не достаточно, чтобы все было одинаковымпо производительности. Например, Оракл 9.2.0.1.0 (винды) и 9.2.0.4.0 (линукс) уже отличаются, например, при сканировании индекса по диапазону, т.е для не равенств. Точнее по первому полю равенство, а второе из диапазона (композитный индекс). У первого я смог добиться сканирования только поставив поле для диапозона первым, а у второго вторым и чуть ли не на 1.3 быстрее выполнялся запрос, когда по диапазону вторым стоит. Так что быстерее даже внутри одного продукта с разными версиями. Я уже не говорю про сжатия индексов, упаравлени заполнением блоков, что влияет на кол-во чтений, фрагментацию таблиц, мат представления и др разные средства, которые есть в продвинутых СУБД для того, чтобы пытаться получить максимальную скорость на данном железе.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902335
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;

end;

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


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

Вообщем обида на базы данных для этой задачи :(
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902338
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
база была


id -integer;
hash-integer; hash-index.
text-longtext, (varchar(100)) text, даже если индекс по полю этому делать все равно. (хотя индекс не выходит)
тоесть решение с разбивкой на hash или на первые 200 символов делать индект тоже плохо.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902368
Alexey Sh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Самописный код для решения узких задач может быть гораздо эффективней по времени работы( не написания кода!) чем стандартная СУБД.Ничего удивительного
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902402
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если других (более сложных )запросов не предвидится, посмотрите berkeley db к примеру.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902415
ynike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
berkeley db к примеру.

А под windows у них верисии вроде то нет ....
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902423
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 www.fun4me.narod.ru

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

Это если он есть, а вообще-то его может и не быть. Мало ли бывает чудес в самописных базах.
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902437
fynda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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) Выполнение на клиенте кода
Код: plaintext
count:=ZQuery1.RecordCount;
в большинстве случаев приведет к fetch на клиента всех записей, удовлетворяющих запросу. Если, конечно, ZQuery - это не какой-то суперинтеллектуальный объект, умеющих самостоятельно исправлять SQL-запросы по необходимости.
2) Насколько я понимаю, то, что hash1 == hash2, еще не гарантирует, что text1 == text2, а всего лишь указывает на возможность этого (то есть одинаковые хэши могут быть и у разных текстов). Соответственно и проверка на count==0 не имеет смысла - нужно проверять все записи, у которых хэш совпадает. Соответственно на клиента уйдут и все поля text с соответствующими хэшами.

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

PS Кстати, а "очень тормозно" - это сколько по времени в данном случае? Секунды? Минуты? Часы? ;)
...
Рейтинг: 0 / 0
Можно ли вообще в базах данных добиться хорошой скорости
    #32902474
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ynikeberkeley 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.
...
Рейтинг: 0 / 0
22 сообщений из 22, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Можно ли вообще в базах данных добиться хорошой скорости
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]