 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : ЏгвЁ«Ё …ўЈҐЁ© ‚ «ҐвЁ®ўЁз 2:5020/400 03 Mar 2003 12:22:54 To : Dmitry Kuzmenko Subject : Re: постреляционные базы данных -------------------------------------------------------------------------------- Sat Mar 01 2003 14:58, Dmitry Kuzmenko wrote to Путилин Евгений Валентинович: DK> From: Dmitry Kuzmenko <kdv@ibase.ru> DK> Hello, Евгений! DK> Путилин Евгений Валентинович wrote: >> Hу есть стандартные тесты на проверку скорости БД. Мне про это >> расказывали в Relex. Они включают определенные задачи. Hо если у одной БД >> время выборки 1 DK> стандартные это TPC-C, который уже все забраковали, и TPC-R и TPC-H, DK> которые тоже не очень точно характеризуют быстродействие РСУБД. Hу я не знаком с этими тестами, ничего сказать не могу но думаю что их до сих пор используют для проверки . Иначе как можно писать про тесты скорости? >> записи в запросе быстрее, то при прочих равных условиях, она быдкт рабоыть >> быстрее. В качестве примера запрос достающий запись по PK. DK> О, только не это! :-) ЛЮБАЯ РСУБД достанет запись по уникальному ключу DK> за миллисекунды, в том числе и Cache. Если хочется более реального DK> примера, могу предложить поиск Hу уменя был такой прецендент. Есть списки типа create table (begn integer,endn integer,model char(4),...) begn и endn это 7 значные цифробуквенные обозначения. Они являються частью VIN автомобиля. Это БД была одной из немецкого концерна. Она содержали список ВСЕХ автомобилей выпищеным им. Т.е. если часть VIN поподала между begn и endn. ТО строка описывалал дату выпуска и комплектацию автомобиля. Таблица содержала больше полумилиона записей. Простой поиск с between выполнялся секунд 20, на Oracle 7.3 и ~4 секунд на IB 6.0. Это и говорит о производительности, чтения 1 записи :(. DK> select * from table where name like '%a%' DK> (только не для СУБД с полнотекстовым поиском). Тут будет однозначный DK> перебор всех записей в таблице, так что хоть как-то можно оценить DK> скорость. DK> Правда, нужно учитывать размер страницы и кол-во считываемых в процессе DK> страниц (т.к. СУБД может записи упаковывать или нет). В общем, голые DK> тесты DK> без знания подробностей архитектуры - ерунда, и могут только ввести в DK> заблуждение. Да но чтение из таблици при использовании индекса и без его это разные вещи, Простейщий пример делать запрос с прописанным FK, или без его создания.(Т.е. с индексом или без) С уважением Путилин Евгений Валентинович --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/166790318dd45.html, оценка из 5, голосов 10
|
|
|