Один из разработчиков GNOME опубликовал заметку (http://www.grillbar.org/wordpress/?p=426) с рассказом об организации функционирования фреймворка для работы с документами и пользовательской информацией Zeitgeist (http://live.gnome.org/GnomeZeitgeist). Zeitgeist представляет собой систему для организации доступа пользователя к документам, производящую отслеживание и журналирование пользовательской активности, направленное на то, чтобы позже забывчивый пользователь смог найти URL в истории браузера или отыскать ранее сохранённые файлы. Ключевым компонентом системы является демон регистратор событий, хранящий данные в SQLite и обеспечивающий доступ к накопленной информации через D-Bus.URL: http://www.grillbar.org/wordpress/?p=426
Новость: http://www.opennet.me/opennews/art.shtml?num=24290
SQLite - отлично
D-Bus - куда же без него.
Демон регистратор событий - если фенечка будет того стоить, почему бы и нет? Хотя я очень настороженно отношусь к фоновым индексаторам и т.п.
> SQLite - отличноПока с базой не захотят работать сразу два приложения - да.
>> ...демон регистратор событий, хранящий данные в SQLite и обеспечивающий доступ к накопленной информации через D-Bus...Зачем другому приложению мешать демону?
>>> ...демон регистратор событий, хранящий данные в SQLite и обеспечивающий доступ к накопленной информации через D-Bus...
>
>Зачем другому приложению мешать демону?Тоесть, искать документ сразу в двух приложениях вы считаете не надо? Или надо ждать? (хотя можт если чтение оно и дает одновременный доступ, но на практике все равно тормоз тот еще на серьезных базах, а бд моего жесткого диска - вполне себе серьезная штука).
С базой будет работать только одно приложение - сам демон. И запись (самое больное место SQLite) аккуратно скэшируется и будет происходить в одну транзакцию, и актуальные страницы базы будут висеть в памяти. И все будет довольно быстро.
Только вот остальным программам хорошо бы знать, что есть этот демон ;)
>С базой будет работать только одно приложение - сам демон. И запись
>(самое больное место SQLite) аккуратно скэшируется и будет происходить в одну
>транзакцию, и актуальные страницы базы будут висеть в памяти. И все
>будет довольно быстро.
>Только вот остальным программам хорошо бы знать, что есть этот демон ;)
>Ну да. Вот пошла запись на 5 минут в одну ненужную табличку и все остальные приложения шлют запрос в этот демон и висят)
Ой прид^ неуч :) За 5 мин SQLite засунет весь твой HDD в табличку.Да и потом ты и в правду считаешь что если два процесса полезут к одному файлу (ну да - *.DBF) - то будет быстрее? Ню-ню.
>Ой прид^ неуч :) За 5 мин SQLite засунет весь твой HDD
>в табличку.
>
>Да и потом ты и в правду считаешь что если два процесса
>полезут к одному файлу (ну да - *.DBF) - то будет
>быстрее? Ню-ню.Все 2 терабайта? Их скопировать не очень-то удастся, а тут их надо обработать каждый документик, засунуть его аккуратненько в базу, проиндексировать хорошенько, причесать.
При чем тут быстрее? Я говорю что в случае с скулайтом это будет иногда в разы медленнее, а иногда это вообще идиотский лок когда какой-то демон чего-то делает с этой базой, а я не могу банально документик найти. В общем, пусть пишут а там посмотрим.
p.s.: если даже коллекция амарока с скулайтом загибается, о каких "весь мой хдд в табличку" может идти речь)
>При чем тут быстрее? Я говорю что в случае с скулайтом это
>будет иногда в разы медленнее,В разы медленнее чем что? Чем СУБД которой дали зохавать все мои гигазы оперативы под ее невъ...й кеш? Так простите, мне на десктопе нужна оператива не для того чтобы все было зохавано СУБДом... :).И если кто думает что sqlite тормоз - очень напрасно.На большинстве задач он спокойно померяется пиписьками с постгром и мускулем например.Тут недавно пролетал забавный писькомер.Да и на sql.ru какой-то фрукт любящий sqlite достаточно немелкую базу бенчил, так оно мускуля в пару раз уделало на одних и тех же данных.
>а иногда это вообще идиотский лок
Вы там что, собираетесь на десктопе поставить сервер куда тыщи юзеров одновременно что-то пишут в БД, что вас локи колышут? Вы случайно крутой сервак с десктопом не попутали? oO
>когда какой-то демон чего-то делает с этой базой, а я не
>могу банально документик найти.Что за бред? Если я не тормоз, у sqlite-а как я помню вполне возможно множественное чтение из одной БД. А зачем при *чтении* локи?
>p.s.: если даже коллекция амарока с скулайтом загибается, о каких "весь мой
>хдд в табличку" может идти речь)Не знаю я что там загибалось, все там нормально работало, загонял до ~50 000 треков. А теперь зачем-то таскают огромный кус мускуля или типа того. Лично мне было хорошо и с sqlite, если честно и я как-то нововведение не оценил: говна добавилось, а результат на глаз ничем таким вроде не отличается.И что-то не думается мне что эти их куски мускуля занимают всего несколько сотен кило кода как sqlite.
Ага, бред ни о чём.
Кто-то передёргивает смысл, в этой БД не будет этих ваших террабайт
>Что за бред? Если я не тормоз, у sqlite-а как я помню
>вполне возможно множественное чтение из одной БД. А зачем при *чтении*
>локи?Скажите, у вас часто файлики на системе меняются/обновляются? У меня - да. Так вот эта программка тоже часто должна перепарсить каждый из них и сложить обновленное в базу. И каждый раз пока будет складывать чтение не будет возможным, хотя здесь я с вами согласен, надо уже в реальной жизни глядеть, может они тестировали и оказалось что нормально все.
А почему мускуль или постгрес оперативку будут жрать? Это уже задача планировщика оперативку распределять, и, если надо, даст меньше и без кэшей обойдется когда туго с оперативкой. Они жрут совсем немного.
> Скажите, у вас часто файлики на системе меняются/обновляются? У меня - да. Так вот эта
> программка тоже часто должна перепарсить каждый из них и сложить обновленное в базу.Если оно будет часто и много сканить файлы, пересканивая полдиска - оно висту по тормозам сделает, для начала. Будет так же клинить комп из-за постоянной занятости диска чтением-записью. А остальные при нужде что-то прочесть\записать встанут в позу рака, ожидая пока диск сможет осилить и их запросы. Как по мне - так я такие штуки на моем десктопе срубаю первым делом, если они есть. Я и так знаю что и где лежит а в крайнем случае - легко нахожу по имени файла (ed2k сетка научила меня полезному фокусу - забивать все потенциальные "теги" для "поиска" ... прямо в имя файла - тогда Kad может запубликовать "кейворды" в "распределенный индекс" и народ может найти файло "распределенным поиском" по кейвордам, до кучи оно помогает и поиску по локальной ФС, да и просто глядя на имя файла понимаешь о чем же оно - без его открытия и затрат на это времени).
> И каждый раз пока будет складывать чтение не будет возможным
1) Это в любом случае проблемы демона который будет индексированием заведовать.
2) В SQLite совершенно валидно если есть много reader-ов и не более 1 writer'а. Для десктопа - это трижды за глаза! Более того - такая конкуррентность канает даже для половины серверов (серверов с интенсивными записями в БД где реально нужна конкурентнаая запись нескольких writer-ов на этой планете не так уж и много).Цитирую понятно чей FAQ:
----------------
Can multiple applications or multiple instances of the same application access a single database file at the same time?Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
----------------Для десктопного индексатора - более чем за глаза... можно даже не паузить индексированеи пока демон вам что-то ищет как видите. А если у вас множественные одновременные записи - наверное это уже все-таки не десктопный индексатор а крЮтой сервак БД :)
> А почему мускуль или постгрес оперативку будут жрать?
Потому что для того чтобы они нормально работали - им надо кучу оперативы под кеши и прочая. И по дефолту они не очень скромничают с жрачем оперативы. Ну, сервер БД обычно ставится для того чтобы быть сервером БД, собссно. И там скромничать глупо - надо юзать ресурсы с пользой. Вот только десктоп - не сервер БД, он поставлен не для того чтобы отдать все свои ресурсы движку БД, так что на нем наглеть не полагается :P.
> Это уже задача планировщика оперативку распределять
Планировщика? Какого планировщика и где? Если что я про кеши самой СУБД говорил а не про дисковые кеши ОС. И зохаваную демоном сервера БД оперативу у него просто так не отберешь, пардон.
>я очень настороженно отношусь к фоновым индексаторам и т.п.Ну раз уж ты настороженно относишься, думаю стоит свернуть разработку.
>>отслеживание и журналирование пользовательской активностиBigBrother Has You.
Если это становится "ключевой" технологие в Gnome, явно стоит от него отказываться.
>Если это становится "ключевой" технологие в Gnome, явно стоит от него отказываться.
>Мегель хочет знать всё о вас
Главное, чтобы это можно было отключить.
хм, а кто нибудь из подписавшихся хоть раз такое юзал вообще?
>хм, а кто нибудь из подписавшихся хоть раз такое юзал вообще?Вряд ли ) Целевая аудитория тут похоже юзеры попроще, чем те, которые тут в основном сидят.