Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
можно ли вообще в базах данных добиться хорошой скорости. есть простая таблица два поля. 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 получать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:25 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
А что за СУБД? Для длинных строк можно вычислять хэш-код и уже его индексировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:35 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
Вариант 1: Хранить строки в компрессионном виде, 10кб текста будут неплохо жаться. Вариант 2: Сделать вычисляемое поле c_Text как LEFT(Text, 10) и нацепить на него индекс. Искать как: SELECT id FROM Table WHERE c_Text = Left(SearchValue, 10) AND Text = SearchValue Вариант 3: Если записей не сильно много, просто сделать компресионный индекс на поле Text. Вариант 4: Сделать хэш на строку и индексировать его. ну и возможно еще множество вариантов в зависимости от возможностей той или иной СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:38 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
А еще в SQL Server есть Full Text Search, в других серверах - другие названия, но смысл тот же. PS. Правда в SQL Server нельзя задать varchar(10000), это только text. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:47 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
>А что за СУБД? или самописная или что то типа 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: >Сделать хэш на строку и индексировать его. Вариант. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:48 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
PS. Правда в SQL Server нельзя задать varchar(10000), это только text. Varchar это довольно условный выбор. просто размер от 100 до 2000-10000 символов в строке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:52 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
ynike или самописная или что то типа firebird бесплатное. Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще? Чтобы те у кого не самописные, могли бы знать что не зря платят деньги? Иначе бы все были с самописными, если бы они ни чем не хуже остальных были. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:56 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
vadiminfo Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же еще? B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в самописной базе. Такова уж природа B-Tree индекса... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 17:59 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
>Самописные СУБД для того и изобретены, чтобы медлено работать. Зачем же >еще? Чтобы те у кого не самописные, могли бы знать что не зря платят >деньги? >Иначе бы все были с самописными, если бы они ни чем не хуже остальных >были. нет спору нет что самописные это плохо. просто задача такая что все наворты которые есть в базах попросту не нужны и самописная база данных очень хорошо работало до тех пор пок ане было необходимости проводить анализа данных которые не умещаються в памяти. даже c hash и b-tree >B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в >самописной базе. Такова уж природа B-Tree индекса... хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:07 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
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. Однако в документации написано, что такой способ доступа к данным не гарантирует уникальности при хранении строк и СУБД при поиске по такому индексу будет вынуждена после нахождения в индексе строки по хэш-коду физически прочитать все найденные записи из таблицы и провести полное сравнение с искомой строкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:20 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
ynikeНо это же не база данных а творчество как быть? С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) этот сервер также является самопальным. Вас это не отпугивает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:27 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
ynike хорошо как прикрутить его в данные ситуации в бузе в моем случаии и тогда бызы зе бест :) например в firebird? В вашем случае лучше использовать hash. Можно ещё разбить строку на две части: varchar(200) и varchar(8800). И сделать индекс по первой части строки, а на вторую сделать hash-code. В 99% случаев это будет работать очень быстро. Понятно, что существующие СУБД имеют некоторые ограничения, которые в Вашем случае придётся обойти. Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:33 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
>С точки зрения программистов-разработчиков mssql (oracle, sybase и т.д.) >этот сервер также является самопальным. Вас это не отпугивает? еще больше пугает цена mssql oracle, sybase задача имеет самые простые запросы нет никаких транзакций бекапов многопользовательской работы в основном select но быстрый надо :( >Можно ещё разбить строку на две части: varchar(200) и varchar(8800). И >сделать индекс по первой части строки, а на вторую сделать hash-code. В >99% случаев это будет работать очень быстро. можно поробывать хотя выглядит это пролематично. Спасибо всем за help. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:41 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ru Когда я писал про B-tree индекс, я хотел сказать, что самописная субд не обязательно должна работать медленнее готовой. Про задачу из этого топика сказать ничего не могу, поскольку думаю, что нужно проводить исследования для долгих запросов. Но в общем случае самого факта B-tree индекс везде B-tree индекс не достаточно, чтобы все было одинаковымпо производительности. Например, Оракл 9.2.0.1.0 (винды) и 9.2.0.4.0 (линукс) уже отличаются, например, при сканировании индекса по диапазону, т.е для не равенств. Точнее по первому полю равенство, а второе из диапазона (композитный индекс). У первого я смог добиться сканирования только поставив поле для диапозона первым, а у второго вторым и чуть ли не на 1.3 быстрее выполнялся запрос, когда по диапазону вторым стоит. Так что быстерее даже внутри одного продукта с разными версиями. Я уже не говорю про сжатия индексов, упаравлени заполнением блоков, что влияет на кол-во чтений, фрагментацию таблиц, мат представления и др разные средства, которые есть в продвинутых СУБД для того, чтобы пытаться получить максимальную скорость на данном железе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 21:22 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
Минимальные иследования показали что прим код. таблица. 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мег всего на диске) Вообще завис пошел под удаление и долгие маты........ Вообщем обида на базы данных для этой задачи :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 21:56 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
база была id -integer; hash-integer; hash-index. text-longtext, (varchar(100)) text, даже если индекс по полю этому делать все равно. (хотя индекс не выходит) тоесть решение с разбивкой на hash или на первые 200 символов делать индект тоже плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 22:01 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
Самописный код для решения узких задач может быть гораздо эффективней по времени работы( не написания кода!) чем стандартная СУБД.Ничего удивительного ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 22:56 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
если других (более сложных )запросов не предвидится, посмотрите berkeley db к примеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 00:14 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
berkeley db к примеру. А под windows у них верисии вроде то нет .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 01:13 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
2 www.fun4me.narod.ru >B-Tree индекс - он, кстати, один и тот же будет, что в коммерческой, что в самописной базе. Такова уж природа B-Tree индекса... Это если он есть, а вообще-то его может и не быть. Мало ли бывает чудес в самописных базах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 02:00 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
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 2) Насколько я понимаю, то, что hash1 == hash2, еще не гарантирует, что text1 == text2, а всего лишь указывает на возможность этого (то есть одинаковые хэши могут быть и у разных текстов). Соответственно и проверка на count==0 не имеет смысла - нужно проверять все записи, у которых хэш совпадает. Соответственно на клиента уйдут и все поля text с соответствующими хэшами. Вывод (ИМХО): правильнее это все было бы сделать на сервере, через хранимую процедуру. Тогда и SQL не надо будет переписывать на каждый чих (BTW RTFM на тему Query.Prepare), да и, возможно, до кучи можно будет несколько соптимизировать алгоритм и сделать его более понятным для сервера. А то получается его бедного пинают, а логика работы-то вся на клиенте, он про нее ни сном, ни духом... :) PS Кстати, а "очень тормозно" - это сколько по времени в данном случае? Секунды? Минуты? Часы? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 03:20 |
|
||
|
Можно ли вообще в базах данных добиться хорошой скорости
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 09:38 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32902402&tid=1553951]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
12ms |
get forum data: |
4ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 435ms |

| 0 / 0 |
