| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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 23:20:00) [1]> Access, кстати значительно пошустрее.
в локальном варианте (и аксесс и mssql на одной машине, где и клиент) да шустрее, но не значительно (в разы разници нет). в нормальном варианте (сервер на одной машине клиенты на других) mssql быстрее.
> Просто я давно уже объясняю, что мой тест выбран только исходя из моих задач, а ты как будто этого не слышишь.
и не услышу, т.к. начинали с одного, обсуждали его, после вдруг оказывается что имеется ввиду другое. задай этот вопрос в другой ветке, изначально так как подразумевается, здесь это оффтопик.
кстати гораздо больше скорости теряется вовсе не на особенностях движка, а на неумелой реализации задачи. (на порядки разница! не имхо, а длительное наблюдение за форумом)
Anatoly Podgoretsky (2006-04-30 23:18:00) [2]По возможности он вообще не пишет данные в базу. Пишется лог
Anatoly Podgoretsky (2006-04-30 23:17:00) [3]VadimSpb (30.04.06 22:31) [67]
Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express.
...
Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых.
MS SQL не пишет новых данных поверх старых.
Access, кстати значительно пошустрее.
Зависит от методики измерения, если Акцесс локальный, то может быть быстрее, а может и нет. В сетевом варианти почти всегда проиграет.
VadimSpb (2006-04-30 22:31:00) [4]Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express. Все значительно дольше и места больше ест :-(((.
Просто задача состоит в периодических записях части клиентской базы 300-400тыс. строк. В идеале мне и затирать данные специально не надо. Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых. Просто и со вкусом, одним словом - оптимально. В Accesse так не пройдет, файл быстро будет максимальным. Или надо сжать/разжать. 2005 я смотрю очень долго все делает.
Проще будет просто удалять файл базы и создавать новый. Access, кстати значительно пошустрее.
> кстати какое впаривание? говорили вроде о процессе безотносительно
> движка, аксесс как пример потому как тема с него начиналась.
>
Я не хотел тебя задеть. Просто я давно уже объясняю, что мой тест выбран только исходя из моих задач, а ты как будто этого не слышишь. Просто убеждаешь, что идейная реализация в движках отличная. Очень похоже на убеждение клиента в чем либо :-0)))
Я и не сомневаюсь что движки пишут грамотные люди. Просто есть золотое правило - если тебе говорят, что то, то и то круто, сразу поинтересуйся за счет чего это достигнуто и где оказалось хуже. Природу не обманешь. Может тот худший параметр и будет для тебя наиболее важным.
sniknik (2006-04-30 21:49:00) [5]> Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.
там тоже самое, движок аналогичен MSSQL 2005. продукт того же мелкософта. (т.е. тут даже не принципы, тут детали реализации могут быть подобные)
> Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ.
допустим, тогда скажи, как ты собираешся обеспечивать постоянную запись в чистые, только выделенные страници базы, если не будет упаковок? ... т.е. у тебя не будет удалений? а чего тогда в "тесте" оно присутствует? зачем меряеш температуру не больного, а прохожего рядом с больницей? он то тут при чем?
кстати какое впаривание? говорили вроде о процессе безотносительно движка, аксесс как пример потому как тема с него начиналась.
VadimSpb (2006-04-30 21:21:00) [6]:-)))))
Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.
> оно всегда является благом, если расматривать сумму факторов,
> процес в обшем.
Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ. Такие рассуждения напоминают впаривание чего-либо клиенту. ЭТО ОТЛИЧНЫЙ ДВИЖОК. Можно и не упоминать, что для конкретной задачи есть более оптимальные решения. Работал у меня один студент. У него все клиенты были тупыми и ничего не понимали в том, что хотят. Перевоспитанию не поддавался, поэтому был уволен.
Anatoly Podgoretsky (2006-04-30 21:17:00) [7]О каком Express-е пошла речь
sniknik (2006-04-30 21:11:00) [8]> Я же показал что не всегда это так. ВОТ И ВСЕ!
ты этого НЕ ПОКАЗАЛ! ты взял вариант где обсуждаемые операции НЕ УЧАСТВУЮТ, вернее их так мало что ими можно пренебреч. и из 2-х вариантов операций, даже которыми пренебрегаем участвует 1-н наименее ресурсоемкий.
это и называется подтасовкой.
> Если бы в том же [20] была оговорка, что такое выделение памяти не всегда является благом...
оно всегда является благом, если расматривать сумму факторов, процес в обшем. даже в твоем "тесте", для того чтобы получить чистые страници (выделились их после удалений) придется прежде базу упаковать, добавь время упавки к своим результатам и смотри что выгоднее в сумме. (даже одной упаковки! а если бы это делалось после каждого удаления, что было бы если бы всегда работало на поддержание минимального обьема базы т.е. хранило только "чистые данные".)
VadimSpb (2006-04-30 21:08:00) [9]Я уже понял. Сообщи реквизиты. Возможно, будет от чего отталкиваться при поиске литературы.
EvS (2006-04-30 21:06:00) [10]Посылку оплатишь? Тебе же сказали из бумажной книги.
VadimSpb (2006-04-30 21:05:00) [11]
> MS Jet автоматически инициирует внутренние транзакции для
> всех операций по добавлению, модификации и удалению данных
Вот что, когда и как при этом происходит интересует прежде всего. В этом бумажном варианте ничего про это не сказано?
В т.ч. для MS SQL.
VadimSpb (2006-04-30 20:53:00) [12]EvS © (30.04.06 20:51) [58]
Можно ссылку на весь документ или скинуть его по почте?
EvS (2006-04-30 20:51:00) [13]" В системах управления транзакциями почти всех баз данных промежуточные изменения хранятся в некотором временном файле журнала, вместо немедленной их записи в БД. Аналогично, MS Jet буферизует все результаты работы транзакции во временной базе данных.Когда транзакция фиксируется, содержимое временной базы данных переносится в реальную БД.
MS Jet не создает временную базу данных, пока это не потребуется. В начале для хранения изменений к данным он использует любую доступную кэш-память. После того, как кэш исчерпан, процессор создает временную базу данных и начинает записывать изменения туда.
...
Хотя временная база данных- база данных MS Jеt, она внутренне используется только процессором.Ее нельзя открыть из другого приложения.После завершения транзакции процессор освобождает пространство временной базы данных.
...
MS Jet автоматически инициирует внутренние транзакции для всех операций по добавлению, модификации и удалению данных."
Цитата из бумажной книги, поэтому ссылку не привожу.
Относится к MS Jet 3.5
VadimSpb (2006-04-30 20:48:00) [14]sniknik ©, Уважаемый верить или не верить дело личное.
Я предпочитаю проверять с калькулятром/секундомером ...
Просто твои объяснения весьма расплывчаты и меня не удовлетворили.
Из твоего поста [20] следует что увеличение объема БД это хорошее решение разработчиков движка. Я же показал что не всегда это так. ВОТ И ВСЕ!
Когда ты учился в институте тебе читали лекции, где говорилось что хорошо/быстро, а что плохо/медленно. После 2-4 лекций была лабораторная, где индикаторы со стрелочками подтверждали слова преподавателя. Если бы в том же [20] была оговорка, что такое выделение памяти не всегда является благом, то и постов бы столько небыло. В моей задаче это даже вредно, т.к. просто чаще придется сжимать/разжимать БД. Тут уж ... задача такая :-)))) Объем ограничен 4 ГБ Express-ом 2005.
Спасибо.
sniknik (2006-04-30 20:28:00) [15]разметка, это это не выделение памяти, это "нанесение меток внутри этой памяти" ну чтото типа этого. вот форматирование диска это разметка, а выделение, это создание раздела по аналогии. абсолютно разные понятия.
и потом тебе же сказали, что при только добавлении записей (твой "тест") выделение будет не под каждую запись, а под страницы, на твоем обьеме может пару раз, притом добавление это не перераспределение, т.е. сначала отдача а после опять выделение. сказали как можно получить более реальные результаты. что было проигнорировано. обьяснено тем что по задаче тебе этого не надо.
т.е. ты игнорируеш то, что реально, и акцентируеш внимание на том в чем операций перераспределения практически нет, даже добавлений нет (одно/два на 5000 операций можно игнорировать), но зато куча других факторов.
а после заявляеш, что не цепляешся, а хочеш разобраться... чтото верится с трудом... да не верится в общемто практически...
VadimSpb (2006-04-30 19:20:00) [16]
> операции перераспределения памяти/дискового пространства/файла
> длительны и ресурсоемки, а вот перезапись внутри уже выделенного
> пространства нет, значит логично минимизировать эти операции,
> считать что память/обьем файла один раз выделенная будет
> принадлежать программе/файлу до явного указания освободить
> ее. программе же явно, каждый раз указывать незачем, после
> удаления может сразу пойти запись (в базах сплош и рядом)
> и в случае уже имеющегося(выделенного) пространства она
> пойдет с минимальными задержками.
Разве речь не об этом?
sniknik (2006-04-30 19:15:00) [17]> В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ...
в [20] нет ни слова о какойто разметке... выдумываеш.
VadimSpb (2006-04-30 18:50:00) [18]
> Anatoly Podgoretsky © (30.04.06 14:14) [47]
> VadimSpb (30.04.06 11:42) [38]
> Потому что есть понятия транзакции. Запись пишется в новое
> место, старая остается мусором до упаковки.
Почему?
В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ... Мои примеры показывают что если это и так - то не всегда. Теперь оказывается, что это мусор.
Зачем? И где тогда логика опять из [20]?
Не думайте, что я цепляюсь, просто Ваши ответы противоречивы и вызывают еще больше вопросов. Действительно охота разобраться. Придется видно поискать соотв. литературу.
sniknik (2006-04-30 16:05:00) [19]> Но беспокоиться до примерно 2 гб не о чем.
примерно... гдето на 1.8 гиг, у нас начинались глюки, ошибки разные выдавало. не часто и не всегда, зависело от запросов и интенсивности обращений, 1 раз мне удалось сложным запросом на таком размере практически "убить" базу (аксесовский компакт & репайр не справился), правда частично база работала, т.е. по одной двум записям можно было удалять/добавлять, все запросы после того висли, открывать таблицы получалость только в режиме серверного курсора. после удаления какогото количества записей (большого, не помню точно сколько) репайр сработал.
тот же запрос на меньшей й базе (1.5) отрабатывал множество раз без проблем (ни одного глюка получить не удалось)
размер мерялся после упаковки баз. т.е. "чисто" данные. после запросов, что база на 1.8, что на 1.5 гиг становилась размером 2 гига (т.е. запросы проверяли обьемные с джойнами, естественно логично предположить, что чем проще запросы с которыми работаеш, тем ближе граница "дедлайна" к 2м гигам).
"разрулить" это тогда не удалось (может и счас не удастся, но больше не пытаемся ;), а может наоборот не удастся воспроизвести... тогда это 2000-2001 год, база access-2000, MDAC-2.5/2.6 jet 3/4sp сейчас и не найти ;), просто написали в рекомендациях, что после 1.5 гиг часть данных требуется скидывать в архив (механизм есть, деление по годам/кварталам/месяцам). архив ничем не отличается от рабочей базы, отчеты получить из него можно, исправить в нем ничего нельзя (в программе, если аксессом открыть то конечно... но тут сами виноваты ;о)).
Anatoly Podgoretsky (2006-04-30 15:31:00) [20]Делать периодический Compact если кого то это беспокоить.
Новые записи не оказывают пагубного воздействия. Пагубно удаление и возможно изменение. Размер тогда растет катастрофически. Но беспокоиться до примерно 2 гб не о чем.
| |
Страницы: 