| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Размер mdb пугает [D7, ADO]
XMAN © (2006-04-27 12:06:00)Был файл с данными base.mdb в нем было около 40 000 записей в одной таблице...файл занимал около 130 мегабайт
я удалил все записи, а он так и остался с таким же размером...может немного уменьшился )...
в чем прикол?
я думал программка не все удалила...так при открытии *.mdb через Access я увидел что таблица пустая...
чего я не вижу...или что я должен знать? помогите....
sniknik (2006-04-30 14:47:00) [21]p.s. это, пост [49] шутка конечно, в сиысле я не расчитывал что прогу будут так использовать. когда писалось, тестировали ("стресс" тесты делали), и расчитывали mdb версию на максимум 3 кассы (потому как "стресс" на 5 начал глючить), если больше то должно быть mssql. кто знал, что менеджеры после ее на 20 "впарят" именно mdb версию... но тем не менее работает. правда я "открестился" от всех возможных глюков уже после случая такой продажи на 9 касс, в письменной форме. что радует. ;о))
sniknik (2006-04-30 14:38:00) [22]> И ее мне надо оптимизировать. ИМЕННО ЕЕ.
но спрашивал то ты НЕ ЭТО. откуда мне знать твои тайные мотивы, я говорил про то о чем спрошено.
> Гонять миллионы записей в Акцесс - это быть не в ладах с головой.
а период "гона" учитывается? ;о))
ну к примеру, есть прога (реально есть) используется для связки между бэк и фронт оффисами (касса и 1с), один из вариантов она работает с mdb базой...
справочник товаров полный в одном тоже реальном месте 100тыс записей, прогрузку полную они делают каждое утро... т.е. милион это 10 дней всегото. на самом деле даже меньше т.к. кроме товаров есть такойже, и даже больше справочник баркодов (некоторые товары представлены несколькими баркодами) т.е. уже 200тыс каждое утро. плюс дисконты, это таблица гдето 150-200тыс. и плюс в процессе работы, в течении дня, все что обновляется тут же передается на кассы. т.е. 1 милион это гдето 1 - 3 дня. прогоняется через mdb. (именно прогоняется, т.к. после передачи записи удаляются). и ничего работает. подумать сколько милионов было пергнано за 2 года (патриарх кому первому ставили уже 6 лет... правда там обьемы не те)... ужас просто. ;о))
могу я считать что у меня "не лады с головой" если программу писал я? ;)
VadimSpb (2006-04-30 14:16:00) [23]
> Гонять миллионы записей в Акцесс - это быть не в ладах с
> головой
Да.
Anatoly Podgoretsky (2006-04-30 14:14:00) [24]VadimSpb (30.04.06 11:42) [38]
Потому что есть понятия транзакции. Запись пишется в новое место, старая остается мусором до упаковки.
Гонять миллионы записей в Акцесс - это быть не в ладах с головой.
VadimSpb (2006-04-30 14:07:00) [25]
> ты выбрал то, где
Еще раз: я не выбирал ничего специально. ТИПОВАЯ ОПЕРАЦИЯ перекачки БД. И ее мне надо оптимизировать. ИМЕННО ЕЕ. У меня эта задача - реальность, а не в [37].
По Хонде. Ты сам подсознательно понимаешь меня. Если есть задача проехать мах быстро, то на масло и бензин внимания обращать не будем, как в Формуле 1 :-))). Если цель ставится о неких равных условиях - то на велосипеде быстрее. Так и у меня в примере - оптимизация программы по конкретному показателю - быстродействие, а не по сумме усредненных.
Природу не обманешь - где-то улучшил, в чем то проиграл.
Ладно, закончили. Футбол начался, пора смотреть :-))
sniknik (2006-04-30 13:55:00) [26]> В чем подтасовка?
ты выбрал то, где перераспределения сведены к минимуму (ну может один два раз за сеанс и будет), по всем остальным показателям запись по использованому полю в проигрыше перед записью по чистому, но меряеш ты почемуто именно перерасрпеделение. (о нем говорим)
вот поэтому и подтасовка.
аналог, как это мне представляется. говорим значит что скорость хонды(машины) быстрее чем у велосипеда... потом делаем "тест", берем хонду без масла, бензина, и т.д. типа поставили в одинаковые условия... хонду приходится толкать а на весипеде как ехали так и едут. потом говорим "ну естественно, мы же меряем растояние за определенное время, без дополнительных факторов"...
а то приближение к реальности ([37]), что я предложил, ты попросту игнорировал.
> Ладно, дальше нет смысла обсуждать.
согласен
VadimSpb (2006-04-30 13:43:00) [27]
> по моему ты не читаеш того чего тебе пишут. в mssql структура
> сложнее, там еще файл логов транзакций добавлен, который
> только увеличивается (зависит от модели)... + автоматические
> очистки, если настроены... там твой "тест" еще более нелеп.
>
Если разработчики автомобильного двигателя оптимизируют его на скорость 300 км/ч с расходом 1 л., а для скорости 60 км/ч - расход 100л., ты купишь такую машину за те же деньги, где расход на 60 км будет 5 л.?
Не купишь, потому что в городе ездишь.
Так и в софте - ищешь оптимальные алгоритмы. Графикой никогда не занимался? Уверяю - еще тем станешь оптимизатором!
В базах я смотрю то же. Как запрос составишь - так он и отработает. Можно конечно, клиента запарить большой теорией, что все круто, но как- то неприлично это ...
VadimSpb (2006-04-30 13:35:00) [28]sniknik © (30.04.06 12:57) [40]
> в том то и дело, это не практика это подтасовка, выбран
> процес который только боком этого касается и где выделение
> минимизировано разработчиками движка
В чем подтасовка? Я честно записываю 100000 фамилий абонентов 'ХХХХХХХХХХ'. Очень даже часто встречающаяся у меня задача. Если разработчики движка оптимизировали его для каких-то определенных целей, то неплохо бы знать для каких. Если моя задача выполняется неоптимально, то надо принимать какие-то меры. Берешь секундомер и считаешь как быстрее работает. Иногода сомневать оказывается очень даже полезно, результаты улучшаются!
> я тебя посылал? или всетаки пытался обьяснить?
Спасибо. Я не часто сюда захожу, когда совсем припрет - нет информации, а не понимаешь что-либо. Однажды мне даже предложили сжечь Архангельского, в смысле его книги :-)))
> тем более доказательством ты почемуто считаеш размер
РАЗУМЕЕТСЯ. Размер/время - это количественные показатели, которые характеризуют быстродействие программы. Нормальный программист ищет не типовые решения, а ОПТИМАЛЬНЫЕ для конкретной задачи.
Ладно, дальше нет смысла обсуждать.
sniknik (2006-04-30 13:16:00) [29]в Accesse теория таже, только для милионов записей место ограничено, чтобы их туда "гонять".
> Нет проблем, сейчас в MS SQL проверю ...
по моему ты не читаеш того чего тебе пишут. в mssql структура сложнее, там еще файл логов транзакций добавлен, который только увеличивается (зависит от модели)... + автоматические очистки, если настроены... там твой "тест" еще более нелеп.
VadimSpb (2006-04-30 12:59:00) [30]В Accesse теория другая??? Что-то это мне напоминает ... :-)))
Хотя [1] все начиналось именно с Access-а.
Нет проблем, сейчас в MS SQL проверю ...
sniknik (2006-04-30 12:57:00) [31]> Конечно, если практика опровергает теорию [20] ;-))
в том то и дело, это не практика это подтасовка, выбран процес который только боком этого касается и где выделение минимизировано разработчиками движка.
и на этом делаются выводы... поэтому и дурацкий. а вовсе не потому что чтото опровергает.
говорил же, извратиш.
> Ввели еще раз 100 000 записей - файл стал 143 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
да потому, что не все так просто как в примере, чтобы обьяснить упрощают... фактически, то что я привел, это будет верно только для одной страници, ссылки эти. но есть же еще область где описаны сами страници (для дисков аналогия область FAT), есть рабочие области (упакуй базу и после простой запрос на чтение, лучше с обьеденением(join) делаеш и... чудо, база увеличилась а ты туда даже ничего в нее не писал...), есть типы полей которые имеют переменную длинну, а ты в "тесте" не привел даже структуру, хотя там единственная запись может быть размером от 4 байт до чуть меньше 2 гигабайт... тем не менее тоже делаеш "выводы".
хотя структура конечно тут не поможет, не только от нее размер зависит, и все факторы просчитать не удастся, это уже к разработчикам движка, хотя не думаю что и они это четко скажут.
> времени мало и послать всех в Библиотеку.
я тебя посылал? или всетаки пытался обьяснить?
> А можно не полениться, сваять простой пример и проверить свои утверждения на практике.
это не убеждения, это знание подчерпнутое из многих источников, доков, справок, и хелпов. притом что работаю я с разными базами (приходится по специфике работы), читаю разные описания баз, то могу сравнивать и вижу общее в построении этих самых баз.
а вот доказывать ничего не собираюсь, не хочеш не верь да и все. вопрос закрыт.
тем более доказательством ты почемуто считаеш размер, который как было не раз сказано неопределен, и отдан на усмотрение системы.
тебе оьяснили принцип всего одного процесса, а "принцип", тем более части, не равно "практика", тем более целого. доказывать безсмысленно. и лень тут не причем, хотя и лень тоже.
DrPass (2006-04-30 12:44:00) [32]
> VadimSpb (30.04.06 11:42) [38]
> Можно конечно сказать, что тест - дурацкий
Тест действительно дурацкий - потому что на сколько-нибудь серьезных СУБД (MS SQL, или тот же Firebird) все работает в соответствии с теорией. А Access... никому не придет в голову гонять миллионы записей в СУБД Access
VadimSpb (2006-04-30 11:42:00) [33]
> могу... но смысл? все одно извратиш...
> дурацкий тест, ничего он не проверяет.
Конечно, если практика опровергает теорию [20] ;-))
Речь идет о понимании того, что происходит в БД при операциях записи/удаления.
Еще раз поэкспериментировал уже с сотнями тысяч записей. Результат еще наглядней, только дольше проверять :-((
После того, как базу сжали/разжали - запись, напр. 100 000 строк, идет 86,05 - 88,02 с. Если перед этим этот объем несколько раз ввести, а потом удалить одним запросом - этот объем будет записываться уже 102,36 - 104,82 с. Разумеется, не следует после каждой записи БД сжимать/разжимать - это абсурд. Также ясно, что эти данные касаются моей машины и условиям примера. Главное - динамика.
Просто это противоречит твоим утверждениям в [20] о повышении скорости работы когда есть выделенная/размеченная (называй как угодно) область.
И далее. Файл 100 МБ. Ввели 100 000 записей - он стал 121 МБ.
Удалили - остался практически тем же.
Ввели еще раз 100 000 записей - файл стал 143 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
А если мне понадобиться постоянно гонять из БД в БД миллионы записей? Поэтому и есть желание понимать эти процессы.
Можно конечно сказать, что тест - дурацкий, юзер - начинающий извращенец, времени мало и послать всех в Библиотеку.
А можно не полениться, сваять простой пример и проверить свои утверждения на практике.
sniknik (2006-04-30 02:04:00) [34]> Можете прокомментировать?
могу... но смысл? все одно извратиш...
во первых кто говорил о какойто "разметке"? говорилось о выделении памяти/обьема файла, и перераспределении ее же при удалениях. и где перераспределение при твоем "тесте"? с чего ожидается "обратный результат"?
движок jet-а не дураки писали, для каждой записи выделения обьема не будет, т.е. когда пишеш в новый файл выделяется кусок (страница) памяти куда и идет запись, возможно все твои 5500 записей в одну страницу и поместились... выделение 1 раз, т.е. мизер по времени. а запись без проверок, никаких "указателей" (пусто/занято) проверять не надо вот и чуть быстрее.
дурацкий тест, ничего он не проверяет.
хочеш проверить действительно со временем на перераспределение сделай так, заносиш в таблицу твои записи, копируеш базу (дубль), и из одной делаеш удаление всего и упаковку, время засекаеш, из другой удаляеш по одной записи и после каждой упаковку... вот тут то и покажет сколько бы времени тратилось если бы было сделано как хочется автору, т.е. удалил и это тут же исчезло, база стала без удаленных записей.
потом придется прикинуть время каждого сжатия, и посчитать на сколько реально упадет скорость при нормальной работе (удаление построчно редкость при нормальной работе, бывает (у начинающих наоборот часто ;), но редкость, вот тут и надо будет прикинуть сколько операций производится при которых будет изменение размеров файла сколько времени это займет... и отнять ту разницу что получилась у тебя, время проверок, тоже с учетом что не все операции это делают)
DrPass (2006-04-29 23:52:00) [35]
> VadimSpb (29.04.06 21:44) [34]
Сейчас провел эксперимент - база с одной-единственной таблицей с 184 тыс. записей (тел. справочник Донецка за 2004 год, если интересно :-), весит 26 метров, Access 2003. Очистил таблицу полностью. Размер файла после удаления остался практически прежним - 26 метров. А вот при архивировании действительно уменьшился - с 5.5 до 4 метров.
Впрочем, этому есть объяснение - данные, естественно, Access не трогает. Зато индексы наверняка честно вычищает. А индексы к таблице порой занимают места намного больше самой таблицы...
VadimSpb (2006-04-29 23:29:00) [36]sniknik © (28.04.06 10:51) [20]
Основная мысль как я понял - более быстрый процесс записи если файл БД размечен. Пробуем проверить. База та же что и в [32].
Вводим запросом 5000 записей, файл "не размечен".
1. Время работы - 12,43 - 12,48 мкс. Пробовал 5 раз. Таймер высокоточный от LMD.
2. Удалил все новые записи, остались только 5500 старых. Т.е. файл теперь весит около 20 МБ и типа "размечен".
Вводим запрос. Время работы 12,71 - 12,91. Явное увеличение времени работы, хотя ожидается обратный результат. ПРИЧЕМ ПОСЛЕ нескольких запросов, когда БД стала "неразмеченой", время работы сразу уменьшилось до п.1. Предвижу результат на базе 1-2 ГБ ;-)))
Можете прокомментировать?
VadimSpb (2006-04-29 21:44:00) [37]
> А ты проведи этот эксперимент много раз с разными данными
> и базами.
И причем здесь количество раз??? Может к шаманам обратиться?
Сколько угодно экспериментируй и с разными базами, результат будет как в [32]. Просто замечено длительной практикой.
> Как на самом деле внутренние структуры mdb-файла изменяются
> при удалении, ведает только сама Access.
В этом собака и зарыта. Пока не известно достоверно, что Access там делает реально, все рассуждения сводятся к гаданию на кофейной гуще в стиле одна бабушка сказала. Результат работы архиватора просто реально сигнализирует о том, что не только затираются некие заголовки.
DrPass (2006-04-29 20:25:00) [38]
> VadimSpb (29.04.06 10:43) [32]
А ты проведи этот эксперимент много раз с разными данными и базами. Увидишь, что никакой зависимости между объемом заархивированной базы и количеством удаленных записей вообще нет :-) Как на самом деле внутренние структуры mdb-файла изменяются при удалении, ведает только сама Access. Но то, что при удалении записей не удаляются никакие данные - это факт.
VadimSpb (2006-04-29 10:43:00) [39]
> ... аналогия не уместна
Очень даже уместна, хоть я и занимался сжатием изображения, а не баз.
Архиватор конечно тупой (зип, рар), сжимает без потери данных и внутр. структуру не понимает. Моя мысь была основана на практике.
Прожу эксперимент:
База mdb объемом 12 255 232. Сжал - 1 062 877. Это исходные параметры.
Удалил записи из одной таблицы в количестве 5500. Всего таблиц около 15 и они менее объемны. Сохранил файл, получил - 12 267 520, т.е. увеличился. Забавно.
Сжал - 738 038.
Вывод: После удаления записей процесс сжатия становится более эффективным, хотя объем файла немного увеличился. Наверное не только заголовки (адреса и т.д.) удаляются, но и какие-то данные.
sniknik (2006-04-29 01:06:00) [40]> Если большой файл, например БД, реально внутри полупустой, то процесс сжатия становиться весьма эффективным.
с точки зрения архиватора "например БД" не будет полупустой, даже если внутри все до последней таблици удалено... т.к. удаление логическое, т.е. просто указателю присвоено "вот туда можно писать", физически по вышеприведенным причинам там никто нулями пространство не трет, остаются старые данные. просто адреса где что лежит потерялись. но архиватор то про внутреннюю логику размещения данных не в курсе... аналогия не уместна.
| |
Страницы: 