Размер mdb пугает

← →
sniknik © (2006-04-30 12:57) [40]

> Конечно, если практика опровергает теорию [20] ;-))
в том то и дело, это не практика это подтасовка, выбран процес который только боком этого касается и где выделение минимизировано разработчиками движка.
и на этом делаются выводы... поэтому и дурацкий. а вовсе не потому что чтото опровергает.
говорил же, извратиш.

> Ввели еще раз 100 000 записей - файл стал 143 МБ! Т.е. не хочет он писать в ту область, о которой ты говоришь. Почему?
да потому, что не все так просто как в примере, чтобы обьяснить упрощают... фактически, то что я привел, это будет верно только для одной страници, ссылки эти. но есть же еще область где описаны сами страници (для дисков аналогия область FAT), есть рабочие области (упакуй базу и после простой запрос на чтение, лучше с обьеденением(join) делаеш и... чудо, база увеличилась а ты туда даже ничего в нее не писал...), есть типы полей которые имеют переменную длинну, а ты в "тесте" не привел даже структуру, хотя там единственная запись может быть размером от 4 байт до чуть меньше 2 гигабайт... тем не менее тоже делаеш "выводы".
хотя структура конечно тут не поможет, не только от нее размер зависит, и все факторы просчитать не удастся, это уже к разработчикам движка, хотя не думаю что и они это четко скажут.

> времени мало и послать всех в Библиотеку.
я тебя посылал? или всетаки пытался обьяснить?

> А можно не полениться, сваять простой пример и проверить свои утверждения на практике.
это не убеждения, это знание подчерпнутое из многих источников, доков, справок, и хелпов. притом что работаю я с разными базами (приходится по специфике работы), читаю разные описания баз, то могу сравнивать и вижу общее в построении этих самых баз.
а вот доказывать ничего не собираюсь, не хочеш не верь да и все. вопрос закрыт.
тем более доказательством ты почемуто считаеш размер, который как было не раз сказано неопределен, и отдан на усмотрение системы.
тебе оьяснили принцип всего одного процесса, а "принцип", тем более части, не равно "практика", тем более целого. доказывать безсмысленно. и лень тут не причем, хотя и лень тоже.

← →
VadimSpb (2006-04-30 12:59) [41]

В Accesse теория другая??? Что-то это мне напоминает ... :-)))
Хотя [1] все начиналось именно с Access-а.
Нет проблем, сейчас в MS SQL проверю ...

← →
sniknik © (2006-04-30 13:16) [42]

в Accesse теория таже, только для милионов записей место ограничено, чтобы их туда "гонять".

> Нет проблем, сейчас в MS SQL проверю ...
по моему ты не читаеш того чего тебе пишут. в mssql структура сложнее, там еще файл логов транзакций добавлен, который только увеличивается (зависит от модели)... + автоматические очистки, если настроены... там твой "тест" еще более нелеп.

← →
VadimSpb (2006-04-30 13:35) [43]

sniknik © (30.04.06 12:57) [40]

> в том то и дело, это не практика это подтасовка, выбран
> процес который только боком этого касается и где выделение
> минимизировано разработчиками движка

В чем подтасовка? Я честно записываю 100000 фамилий абонентов "ХХХХХХХХХХ". Очень даже часто встречающаяся у меня задача. Если разработчики движка оптимизировали его для каких-то определенных целей, то неплохо бы знать для каких. Если моя задача выполняется неоптимально, то надо принимать какие-то меры. Берешь секундомер и считаешь как быстрее работает. Иногода сомневать оказывается очень даже полезно, результаты улучшаются!

> я тебя посылал? или всетаки пытался обьяснить?

Спасибо. Я не часто сюда захожу, когда совсем припрет - нет информации, а не понимаешь что-либо. Однажды мне даже предложили сжечь Архангельского, в смысле его книги :-)))

> тем более доказательством ты почемуто считаеш размер

РАЗУМЕЕТСЯ. Размер/время - это количественные показатели, которые характеризуют быстродействие программы. Нормальный программист ищет не типовые решения, а ОПТИМАЛЬНЫЕ для конкретной задачи.

Ладно, дальше нет смысла обсуждать.

← →
VadimSpb (2006-04-30 13:43) [44]

> по моему ты не читаеш того чего тебе пишут. в mssql структура
> сложнее, там еще файл логов транзакций добавлен, который
> только увеличивается (зависит от модели)... + автоматические
> очистки, если настроены... там твой "тест" еще более нелеп.
>

Если разработчики автомобильного двигателя оптимизируют его на скорость 300 км/ч с расходом 1 л., а для скорости 60 км/ч - расход 100л., ты купишь такую машину за те же деньги, где расход на 60 км будет 5 л.?
Не купишь, потому что в городе ездишь.
Так и в софте - ищешь оптимальные алгоритмы. Графикой никогда не занимался? Уверяю - еще тем станешь оптимизатором!
В базах я смотрю то же. Как запрос составишь - так он и отработает. Можно конечно, клиента запарить большой теорией, что все круто, но как- то неприлично это ...

← →
sniknik © (2006-04-30 13:55) [45]

> В чем подтасовка?
ты выбрал то, где перераспределения сведены к минимуму (ну может один два раз за сеанс и будет), по всем остальным показателям запись по использованому полю в проигрыше перед записью по чистому, но меряеш ты почемуто именно перерасрпеделение. (о нем говорим)
вот поэтому и подтасовка.

аналог, как это мне представляется. говорим значит что скорость хонды(машины) быстрее чем у велосипеда... потом делаем "тест", берем хонду без масла, бензина, и т.д. типа поставили в одинаковые условия... хонду приходится толкать а на весипеде как ехали так и едут. потом говорим "ну естественно, мы же меряем растояние за определенное время, без дополнительных факторов"...

а то приближение к реальности ([37]), что я предложил, ты попросту игнорировал.

> Ладно, дальше нет смысла обсуждать.
согласен

← →
VadimSpb (2006-04-30 14:07) [46]

> ты выбрал то, где

Еще раз: я не выбирал ничего специально. ТИПОВАЯ ОПЕРАЦИЯ перекачки БД. И ее мне надо оптимизировать. ИМЕННО ЕЕ. У меня эта задача - реальность, а не в [37].
По Хонде. Ты сам подсознательно понимаешь меня. Если есть задача проехать мах быстро, то на масло и бензин внимания обращать не будем, как в Формуле 1 :-))). Если цель ставится о неких равных условиях - то на велосипеде быстрее. Так и у меня в примере - оптимизация программы по конкретному показателю - быстродействие, а не по сумме усредненных.
Природу не обманешь - где-то улучшил, в чем то проиграл.

Ладно, закончили. Футбол начался, пора смотреть :-))

← →
Anatoly Podgoretsky © (2006-04-30 14:14) [47]

VadimSpb (30.04.06 11:42) [38]
Потому что есть понятия транзакции. Запись пишется в новое место, старая остается мусором до упаковки.
Гонять миллионы записей в Акцесс - это быть не в ладах с головой.

← →
VadimSpb (2006-04-30 14:16) [48]

> Гонять миллионы записей в Акцесс - это быть не в ладах с
> головой

Да.

← →
sniknik © (2006-04-30 14:38) [49]

> И ее мне надо оптимизировать. ИМЕННО ЕЕ.
но спрашивал то ты НЕ ЭТО. откуда мне знать твои тайные мотивы, я говорил про то о чем спрошено.

> Гонять миллионы записей в Акцесс - это быть не в ладах с головой.
а период "гона" учитывается? ;о))

ну к примеру, есть прога (реально есть) используется для связки между бэк и фронт оффисами (касса и 1с), один из вариантов она работает с mdb базой...
справочник товаров полный в одном тоже реальном месте 100тыс записей, прогрузку полную они делают каждое утро... т.е. милион это 10 дней всегото. на самом деле даже меньше т.к. кроме товаров есть такойже, и даже больше справочник баркодов (некоторые товары представлены несколькими баркодами) т.е. уже 200тыс каждое утро. плюс дисконты, это таблица гдето 150-200тыс. и плюс в процессе работы, в течении дня, все что обновляется тут же передается на кассы. т.е. 1 милион это гдето 1 - 3 дня. прогоняется через mdb. (именно прогоняется, т.к. после передачи записи удаляются). и ничего работает. подумать сколько милионов было пергнано за 2 года (патриарх кому первому ставили уже 6 лет... правда там обьемы не те)... ужас просто. ;о))

могу я считать что у меня "не лады с головой" если программу писал я? ;)

← →
sniknik © (2006-04-30 14:47) [50]

p.s. это, пост [49] шутка конечно, в сиысле я не расчитывал что прогу будут так использовать. когда писалось, тестировали ("стресс" тесты делали), и расчитывали mdb версию на максимум 3 кассы (потому как "стресс" на 5 начал глючить), если больше то должно быть mssql. кто знал, что менеджеры после ее на 20 "впарят" именно mdb версию... но тем не менее работает. правда я "открестился" от всех возможных глюков уже после случая такой продажи на 9 касс, в письменной форме. что радует. ;о))

← →
Anatoly Podgoretsky © (2006-04-30 15:31) [51]

Делать периодический Compact если кого то это беспокоить.
Новые записи не оказывают пагубного воздействия. Пагубно удаление и возможно изменение. Размер тогда растет катастрофически. Но беспокоиться до примерно 2 гб не о чем.

← →
sniknik © (2006-04-30 16:05) [52]

> Но беспокоиться до примерно 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 гиг часть данных требуется скидывать в архив (механизм есть, деление по годам/кварталам/месяцам). архив ничем не отличается от рабочей базы, отчеты получить из него можно, исправить в нем ничего нельзя (в программе, если аксессом открыть то конечно... но тут сами виноваты ;о)).

← →
VadimSpb (2006-04-30 18:50) [53]

> Anatoly Podgoretsky © (30.04.06 14:14) [47]
> VadimSpb (30.04.06 11:42) [38]
> Потому что есть понятия транзакции. Запись пишется в новое
> место, старая остается мусором до упаковки.

Почему?
В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ... Мои примеры показывают что если это и так - то не всегда. Теперь оказывается, что это мусор.
Зачем? И где тогда логика опять из [20]?
Не думайте, что я цепляюсь, просто Ваши ответы противоречивы и вызывают еще больше вопросов. Действительно охота разобраться. Придется видно поискать соотв. литературу.

← →
sniknik © (2006-04-30 19:15) [54]

> В [20] утверждается что все размечено (типа в шоколаде) и теперь работать будет быстрее ...
в [20] нет ни слова о какойто разметке... выдумываеш.

← →
VadimSpb (2006-04-30 19:20) [55]

> операции перераспределения памяти/дискового пространства/файла
> длительны и ресурсоемки, а вот перезапись внутри уже выделенного
> пространства нет, значит логично минимизировать эти операции,
> считать что память/обьем файла один раз выделенная будет
> принадлежать программе/файлу до явного указания освободить
> ее. программе же явно, каждый раз указывать незачем, после
> удаления может сразу пойти запись (в базах сплош и рядом)
> и в случае уже имеющегося(выделенного) пространства она
> пойдет с минимальными задержками.

Разве речь не об этом?

← →
sniknik © (2006-04-30 20:28) [56]

разметка, это это не выделение памяти, это "нанесение меток внутри этой памяти" ну чтото типа этого. вот форматирование диска это разметка, а выделение, это создание раздела по аналогии. абсолютно разные понятия.

и потом тебе же сказали, что при только добавлении записей (твой "тест") выделение будет не под каждую запись, а под страницы, на твоем обьеме может пару раз, притом добавление это не перераспределение, т.е. сначала отдача а после опять выделение. сказали как можно получить более реальные результаты. что было проигнорировано. обьяснено тем что по задаче тебе этого не надо.
т.е. ты игнорируеш то, что реально, и акцентируеш внимание на том в чем операций перераспределения практически нет, даже добавлений нет (одно/два на 5000 операций можно игнорировать), но зато куча других факторов.
а после заявляеш, что не цепляешся, а хочеш разобраться... чтото верится с трудом... да не верится в общемто практически...

← →
VadimSpb (2006-04-30 20:48) [57]

sniknik ©, Уважаемый верить или не верить дело личное.
Я предпочитаю проверять с калькулятром/секундомером ...
Просто твои объяснения весьма расплывчаты и меня не удовлетворили.
Из твоего поста [20] следует что увеличение объема БД это хорошее решение разработчиков движка. Я же показал что не всегда это так. ВОТ И ВСЕ!
Когда ты учился в институте тебе читали лекции, где говорилось что хорошо/быстро, а что плохо/медленно. После 2-4 лекций была лабораторная, где индикаторы со стрелочками подтверждали слова преподавателя. Если бы в том же [20] была оговорка, что такое выделение памяти не всегда является благом, то и постов бы столько небыло. В моей задаче это даже вредно, т.к. просто чаще придется сжимать/разжимать БД. Тут уж ... задача такая :-)))) Объем ограничен 4 ГБ Express-ом 2005.
Спасибо.

← →
EvS © (2006-04-30 20:51) [58]

" В системах управления транзакциями почти всех баз данных промежуточные изменения хранятся в некотором временном файле журнала, вместо немедленной их записи в БД. Аналогично, MS Jet буферизует все результаты работы транзакции во временной базе данных.Когда транзакция фиксируется, содержимое временной базы данных переносится в реальную БД.
MS Jet не создает временную базу данных, пока это не потребуется. В начале для хранения изменений к данным он использует любую доступную кэш-память. После того, как кэш исчерпан, процессор создает временную базу данных и начинает записывать изменения туда.
...
Хотя временная база данных- база данных MS Jеt, она внутренне используется только процессором.Ее нельзя открыть из другого приложения.После завершения транзакции процессор освобождает пространство временной базы данных.
...
MS Jet автоматически инициирует внутренние транзакции для всех операций по добавлению, модификации и удалению данных."
Цитата из бумажной книги, поэтому ссылку не привожу.
Относится к MS Jet 3.5

← →
VadimSpb (2006-04-30 20:53) [59]

EvS © (30.04.06 20:51) [58]
Можно ссылку на весь документ или скинуть его по почте?

← →
VadimSpb (2006-04-30 21:05) [60]

> MS Jet автоматически инициирует внутренние транзакции для
> всех операций по добавлению, модификации и удалению данных

Вот что, когда и как при этом происходит интересует прежде всего. В этом бумажном варианте ничего про это не сказано?
В т.ч. для MS SQL.

← →
EvS © (2006-04-30 21:06) [61]

Посылку оплатишь? Тебе же сказали из бумажной книги.

← →
VadimSpb (2006-04-30 21:08) [62]

Я уже понял. Сообщи реквизиты. Возможно, будет от чего отталкиваться при поиске литературы.

> Я же показал что не всегда это так. ВОТ И ВСЕ!
ты этого НЕ ПОКАЗАЛ! ты взял вариант где обсуждаемые операции НЕ УЧАСТВУЮТ, вернее их так мало что ими можно пренебреч. и из 2-х вариантов операций, даже которыми пренебрегаем участвует 1-н наименее ресурсоемкий.

это и называется подтасовкой.

> Если бы в том же [20] была оговорка, что такое выделение памяти не всегда является благом...
оно всегда является благом, если расматривать сумму факторов, процес в обшем. даже в твоем "тесте", для того чтобы получить чистые страници (выделились их после удалений) придется прежде базу упаковать, добавь время упавки к своим результатам и смотри что выгоднее в сумме. (даже одной упаковки! а если бы это делалось после каждого удаления, что было бы если бы всегда работало на поддержание минимального обьема базы т.е. хранило только "чистые данные".)

О каком Express-е пошла речь

← →
VadimSpb (2006-04-30 21:21) [65]

:-)))))
Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.

> оно всегда является благом, если расматривать сумму факторов,
> процес в обшем.

Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ. Такие рассуждения напоминают впаривание чего-либо клиенту. ЭТО ОТЛИЧНЫЙ ДВИЖОК. Можно и не упоминать, что для конкретной задачи есть более оптимальные решения. Работал у меня один студент. У него все клиенты были тупыми и ничего не понимали в том, что хотят. Перевоспитанию не поддавался, поэтому был уволен.

> Я взял вариант который нужен МНЕ не имея никакого понятия об операциях.
там тоже самое, движок аналогичен MSSQL 2005. продукт того же мелкософта. (т.е. тут даже не принципы, тут детали реализации могут быть подобные)

> Это - средняя температура в больнице. И это является ПОДТАСОВКОЙ.
допустим, тогда скажи, как ты собираешся обеспечивать постоянную запись в чистые, только выделенные страници базы, если не будет упаковок? ... т.е. у тебя не будет удалений? а чего тогда в "тесте" оно присутствует? зачем меряеш температуру не больного, а прохожего рядом с больницей? он то тут при чем?

кстати какое впаривание? говорили вроде о процессе безотносительно движка, аксесс как пример потому как тема с него начиналась.

← →
VadimSpb (2006-04-30 22:31) [67]

Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express. Все значительно дольше и места больше ест :-(((.
Просто задача состоит в периодических записях части клиентской базы 300-400тыс. строк. В идеале мне и затирать данные специально не надо. Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых. Просто и со вкусом, одним словом - оптимально. В Accesse так не пройдет, файл быстро будет максимальным. Или надо сжать/разжать. 2005 я смотрю очень долго все делает.
Проще будет просто удалять файл базы и создавать новый. Access, кстати значительно пошустрее.

> кстати какое впаривание? говорили вроде о процессе безотносительно
> движка, аксесс как пример потому как тема с него начиналась.
>

Я не хотел тебя задеть. Просто я давно уже объясняю, что мой тест выбран только исходя из моих задач, а ты как будто этого не слышишь. Просто убеждаешь, что идейная реализация в движках отличная. Очень похоже на убеждение клиента в чем либо :-0)))
Я и не сомневаюсь что движки пишут грамотные люди. Просто есть золотое правило - если тебе говорят, что то, то и то круто, сразу поинтересуйся за счет чего это достигнуто и где оказалось хуже. Природу не обманешь. Может тот худший параметр и будет для тебя наиболее важным.

VadimSpb (30.04.06 22:31) [67]
Сейчас гоняю тот же тест как [38] но в MS SQL 2005 Express.
...
Было бы прекрасно: стерлись заголовки и пишем новые данные поверх старых.

MS SQL не пишет новых данных поверх старых.

Access, кстати значительно пошустрее.

Зависит от методики измерения, если Акцесс локальный, то может быть быстрее, а может и нет. В сетевом варианти почти всегда проиграет.

По возможности он вообще не пишет данные в базу. Пишется лог

> Access, кстати значительно пошустрее.
в локальном варианте (и аксесс и mssql на одной машине, где и клиент) да шустрее, но не значительно (в разы разници нет). в нормальном варианте (сервер на одной машине клиенты на других) mssql быстрее.

> Просто я давно уже объясняю, что мой тест выбран только исходя из моих задач, а ты как будто этого не слышишь.
и не услышу, т.к. начинали с одного, обсуждали его, после вдруг оказывается что имеется ввиду другое. задай этот вопрос в другой ветке, изначально так как подразумевается, здесь это оффтопик.

кстати гораздо больше скорости теряется вовсе не на особенностях движка, а на неумелой реализации задачи. (на порядки разница! не имхо, а длительное наблюдение за форумом)

Размер mdb пугает Найти похожие ветки