Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
change transaction Isolation Level? 16.05.08 21:36 Число просмотров: 5223
Автор: void <Grebnev Valery> Статус: Elderman
|
|
|
|
<programming>
|
(sql CE) Индекс(-ы) 07.12.07 21:04
Автор: Garick <Yuriy> Статус: Elderman
|
Постановка задачи:
Дано:
- Справочник (~2500 записей) имущества. Меняется в справочнике только одно поле (битовое) -метка, что считано.
- Реинженеринг. Те софт не знает про "тонкости" структуры базы
- Сиквел для СЕ
- "Вход" select в базу данных - штрих-код.
- Индексов нет.
- Есть два поля из которых формируется штрих-код, которые присвоен (приклеен :)) к имуществу.
Требуется:
- Будет ли прирост, если создать индекс(ы)?
- Структура индекса.
- Оценка прироста?
Софт работает. Вопрос больше архитектурный :)
|
|
Индексы при 50к записей действительно помогают на select, а как ускорить update - меняется одно поле в одной строке тип bit? Секунд пять идет апдейт. 16.05.08 14:03
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| |
change transaction Isolation Level? 16.05.08 21:36
Автор: void <Grebnev Valery> Статус: Elderman
|
|
|
|
Однозначно будет! 09.12.07 15:50
Автор: Den <Денис Т.> Статус: The Elderman
|
> Постановка задачи:
> Требуется:
> - Будет ли прирост, если создать индекс(ы)?
Однозначно будет!
> - Структура индекса.
Кластерный индекс по полям, на основе которых строится штрих-код.
(+) - существенный прирост произв.поиска без увеличения размера БД
(-) - возможно некоторое падение производительности при добавлении записей (некритичный аспект в случае "справочника").
> - Оценка прироста?
>
> Софт работает. Вопрос больше архитектурный :)
З.Ы. Не совсем понятно, зачем использовать SQL CE. Вполне достаточно подобия DBF формата и кластерного индекса.
|
| |
"З.Ы. Не совсем понятно, зачем использовать SQL CE. Вполне достаточно подобия DBF формата и кластерного индекса." - приложение исполняется на мобильном устройстве со ШК сканером. 10.12.07 00:46
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 10.12.07 00:48 Количество правок: 1
|
а и сама реализация сиквел СЕ весьма проста. Установил библиотеку, положил файл в нужное место и работай. Нет необходимости сиквел сервер поднимать :)
Но нет, соотвественно, и многопользовательского режима. Да и зачем на мобильном терминале многопользовательский режим? :) Для этого есть експресс редакция (но для десктопов), также бесплатная.
С индексами попробую по возможности, сенкс.
Только не знаю как на мобильном устройстве бенчмаркинг с БД устроить, тут софт писать надо :)
|
|
на 2500 записей имхо индексы будут не заметны в простых... 08.12.07 05:45
Автор: i1 Статус: Незарегистрированный пользователь
|
> Постановка задачи:
> Дано:
> - Справочник (~2500 записей) имущества. Меняется в
> справочнике только одно поле (битовое) -метка, что считано.
> - Реинженеринг. Те софт не знает про "тонкости" структуры
> базы
> - Сиквел для СЕ
> - "Вход" select в базу данных - штрих-код.
> - Индексов нет.
> - Есть два поля из которых формируется штрих-код, которые
> присвоен (приклеен :)) к имуществу.
> Требуется:
> - Будет ли прирост, если создать индекс(ы)?
> - Структура индекса.
> - Оценка прироста?
>
> Софт работает. Вопрос больше архитектурный :)
на 2500 записей имхо индексы будут не заметны в простых запросах,
нужно знать запросы на которых хочется прироста производительности
и исходя их них строить индексы
и вообще проще посмотреть на скорость с индексами и без на нужных запросах :)
|
| |
имхо индексы будут заметны. Кстати SQL2005 вроде позволяет... 09.12.07 07:04
Автор: void <Grebnev Valery> Статус: Elderman
|
> на 2500 записей имхо индексы будут не заметны в простых
> запросах,
имхо индексы будут заметны. Кстати SQL2005 вроде позволяет агрегировать простой ключ непосредствено в индексе. Тогда ещё более заметно будет. Нет?
|
| | |
почитал про предмет разговора, понял что не учел объемы и... 10.12.07 04:30
Автор: i1 Статус: Незарегистрированный пользователь
|
> > на 2500 записей имхо индексы будут не заметны в
> простых
> > запросах,
> имхо индексы будут заметны. Кстати SQL2005 вроде позволяет
> агрегировать простой ключ непосредствено в индексе. Тогда
> ещё более заметно будет. Нет?
почитал про предмет разговора, понял что не учел объемы и скорости памяти :)
я так себе это представляю:
включаем терминал, запускаем приложение,
считываем первый штрих код, sql подгружает таблицу в RAM, ищет по полю,
выдает результат. На следующем считывании если таблица все еще в памяти надо
сделать в среднем 2500 сравнений без индекса, или 20 с индексом
(т.к. штрих код состоит из 2х полей). т.к. штрих код постоянной не очень большой длины
то операция сравнения займет не много времени на 300-400 мегагерцовом проце
и отличить на глаз 2500 и 20 сравнений не получится :) хотя конечно это надо смотреть
если же таблица в оперативке по каким то причинам не хранится то
при поиске в память загружается только индекс, который конечно меньше самой
таблицы, допустим индекс весит 100К (по 40 байт на штрих код) когда таблица
допустим 2.5 метра (по 1К на запись). Скорости чтения с флэш памяти: 2 - 133 Мб/с
то есть на этом этапе разница будет максимум в секунду минимум примерно 0.02 секунды
получается, что если для таблицы хватает памяти в RAM, или флеш-память в терминале быстрая, то разница будет особо не заметна.
если бы была сложная логика с запросами по этим полям используемыми в больших циклах, то
конечно индексы дали бы большой прирост скорости
если чего-то не учел поправьте.
ПС: индексы конечно это круто :)
|
| | | |
Кластерный индекс не является индексом в привычном понимании. 12.12.07 13:53
Автор: Den <Денис Т.> Статус: The Elderman
|
Это всего лишь упорядочивание записей в таблице по заданным полям.
Для таблицы с количеством записей ~2500 и "индексом", построенным по двум полям, максимальное количествово итераций поиска не привысит 12.
|
| | | | |
я имел ввиду операций сравнения, то есть 1 итерация поиска =... 13.12.07 03:00
Автор: i1 Статус: Незарегистрированный пользователь
Отредактировано 13.12.07 03:09 Количество правок: 1
|
> Это всего лишь упорядочивание записей в таблице по заданным
> полям.
> Для таблицы с количеством записей ~2500 и "индексом",
> построенным по двум полям, максимальное количествово
> итераций поиска не привысит 12.
я имел ввиду операций сравнения, то есть 1 итерация поиска = 2 операции сравнения
но понял что так считать нельзя :)
в индексах я так понимаю используются двоичные деревья, то есть количество итераций поиска
равно логарифму по основанию 2 от числа записей (забыл как считать логарифм по основанию при
помощи других логарифмов и поэтому посчитал от е, получилось 7 с чемто,
ну я и прикинул что от 2-х будет 10 :))
от 2-х оказалось 11.28.... операций сравнения в предыдущем посте тогда получилось бы 24
но так как в процессе поиска участвуют 2 поля то на начальном этапе поиска достаточно сравнивать
1-е поле и, если нет совпадения, то второе не сравнивать, то есть на вскидку 12 сравнений 1-го поля
и 2-3 сравнения второго и то это много, если 1-е поле в таблице имеет в основном разные значения.
то есть в итоге 15 операций сравнения
хм.. только что понял что при построении индекса из 2-х полей выгоднее пихать первым полем то,
в котором значения будут больше разниться :)
тогда и для простого перебора будет максимум не 2*2500 сравнений а 2500 + 100 (чтоб не жадничать :))
тогда в среднем получается 1300 сравнений
|
| | | | |
А если будет 35к записей? :) При тех же условиях. 12.12.07 17:02
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | |
16 итераций поиска :) 13.12.07 03:01
Автор: i1 Статус: Незарегистрированный пользователь
Отредактировано 13.12.07 03:01 Количество правок: 1
|
|
|
| | | | | | |
+1 не больше 16-ти 14.12.07 17:29
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
