The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обзор Zeitgeist, одной из ключевых технологий GNOME 3, opennews (??), 17-Ноя-09, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от kost BebiXemail (?), 17-Ноя-09, 11:25 
>  SQLite - отлично

Пока с базой не захотят работать сразу два приложения - да.

Ответить | Правка | Наверх | Cообщить модератору

4. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от Аноним (-), 17-Ноя-09, 11:49 
>> ...демон регистратор событий, хранящий данные в SQLite и обеспечивающий доступ к накопленной информации через D-Bus...

Зачем другому приложению мешать демону?

Ответить | Правка | Наверх | Cообщить модератору

7. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от kost BebiXemail (?), 17-Ноя-09, 13:11 
>>> ...демон регистратор событий, хранящий данные в SQLite и обеспечивающий доступ к накопленной информации через D-Bus...
>
>Зачем другому приложению мешать демону?

Тоесть, искать документ сразу в двух приложениях вы считаете не надо? Или надо ждать? (хотя можт если чтение оно и дает одновременный доступ, но на практике все равно тормоз тот еще на серьезных базах, а бд моего жесткого диска - вполне себе серьезная штука).

Ответить | Правка | Наверх | Cообщить модератору

9. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от тоже Аноним (?), 17-Ноя-09, 14:06 
С базой будет работать только одно приложение - сам демон. И запись (самое больное место SQLite) аккуратно скэшируется и будет происходить в одну транзакцию, и актуальные страницы базы будут висеть в памяти. И все будет довольно быстро.
Только вот остальным программам хорошо бы знать, что есть этот демон ;)
Ответить | Правка | Наверх | Cообщить модератору

11. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от kost BebiXemail (?), 17-Ноя-09, 14:29 
>С базой будет работать только одно приложение - сам демон. И запись
>(самое больное место SQLite) аккуратно скэшируется и будет происходить в одну
>транзакцию, и актуальные страницы базы будут висеть в памяти. И все
>будет довольно быстро.
>Только вот остальным программам хорошо бы знать, что есть этот демон ;)
>

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

Ответить | Правка | Наверх | Cообщить модератору

12. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от Warhead Wardick (?), 17-Ноя-09, 18:30 
Ой прид^ неуч :) За 5 мин SQLite засунет весь твой HDD в табличку.

Да и потом ты и в правду считаешь что если два процесса полезут к одному файлу (ну да - *.DBF) - то будет быстрее? Ню-ню.

Ответить | Правка | Наверх | Cообщить модератору

13. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  –1 +/
Сообщение от kost BebiXemail (?), 17-Ноя-09, 22:43 
>Ой прид^ неуч :) За 5 мин SQLite засунет весь твой HDD
>в табличку.
>
>Да и потом ты и в правду считаешь что если два процесса
>полезут к одному файлу (ну да - *.DBF) - то будет
>быстрее? Ню-ню.

Все 2 терабайта? Их скопировать не очень-то удастся, а тут их надо обработать каждый документик, засунуть его аккуратненько в базу, проиндексировать хорошенько, причесать.

При чем тут быстрее? Я говорю что в случае с скулайтом это будет иногда в разы медленнее, а иногда это вообще идиотский лок когда какой-то демон чего-то делает с этой базой, а я не могу банально документик найти. В общем, пусть пишут а там посмотрим.

p.s.: если даже коллекция амарока с скулайтом загибается, о каких "весь мой хдд в табличку" может идти речь)

Ответить | Правка | Наверх | Cообщить модератору

15. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от User294 (ok), 18-Ноя-09, 04:25 
>При чем тут быстрее? Я говорю что в случае с скулайтом это
>будет иногда в разы медленнее,

В разы медленнее чем что? Чем СУБД которой дали зохавать все мои гигазы оперативы под ее невъ...й кеш? Так простите, мне на десктопе нужна оператива не для того чтобы все было зохавано СУБДом... :).И если кто думает что sqlite тормоз - очень напрасно.На большинстве задач он спокойно померяется пиписьками с постгром и мускулем например.Тут недавно пролетал забавный писькомер.Да и на sql.ru какой-то фрукт любящий sqlite достаточно немелкую базу бенчил, так оно мускуля в пару раз уделало на одних и тех же данных.

>а иногда это вообще идиотский лок

Вы там что, собираетесь на десктопе поставить сервер куда тыщи юзеров одновременно что-то пишут в БД, что вас локи колышут? Вы случайно крутой сервак с десктопом не попутали? oO

>когда какой-то демон чего-то делает с этой базой, а я не
>могу банально документик найти.

Что за бред? Если я не тормоз, у sqlite-а как я помню вполне возможно множественное чтение из одной БД. А зачем при *чтении* локи?

>p.s.: если даже коллекция амарока с скулайтом загибается, о каких "весь мой
>хдд в табличку" может идти речь)

Не знаю я что там загибалось, все там нормально работало, загонял до ~50 000 треков. А теперь зачем-то таскают огромный кус мускуля или типа того. Лично мне было хорошо и с sqlite, если честно и я как-то нововведение не оценил: говна добавилось, а результат на глаз ничем таким вроде не отличается.И что-то не думается мне что эти их куски мускуля занимают всего несколько сотен кило кода как sqlite.

Ответить | Правка | Наверх | Cообщить модератору

16. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от Аноним (-), 18-Ноя-09, 09:17 
Ага, бред ни о чём.
Кто-то передёргивает смысл, в этой БД не будет этих ваших террабайт
Ответить | Правка | Наверх | Cообщить модератору

17. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от kost BebiXemail (?), 18-Ноя-09, 11:05 
>Что за бред? Если я не тормоз, у sqlite-а как я помню
>вполне возможно множественное чтение из одной БД. А зачем при *чтении*
>локи?

Скажите, у вас часто файлики на системе меняются/обновляются? У меня - да. Так вот эта программка тоже часто должна перепарсить каждый из них и сложить обновленное в базу. И каждый раз пока будет складывать чтение не будет возможным, хотя здесь я с вами согласен, надо уже в реальной жизни глядеть, может они тестировали и оказалось что нормально все.

А почему мускуль или постгрес оперативку будут жрать? Это уже задача планировщика оперативку распределять, и, если надо, даст меньше и без кэшей обойдется когда туго с оперативкой. Они жрут совсем немного.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

19. "Обзор Zeitgeist, одной из ключевых технологий GNOME 3"  +/
Сообщение от User294 (ok), 21-Ноя-09, 08:36 
> Скажите, у вас часто файлики на системе меняются/обновляются? У меня - да. Так вот эта
> программка тоже часто должна перепарсить каждый из них и сложить обновленное в базу.

Если оно будет часто и много сканить файлы, пересканивая полдиска - оно висту по тормозам сделает, для начала. Будет так же клинить комп из-за постоянной занятости диска чтением-записью. А остальные при нужде что-то прочесть\записать встанут в позу рака, ожидая пока диск сможет осилить и их запросы. Как по мне - так я такие штуки на моем десктопе срубаю первым делом, если они есть. Я и так знаю что и где лежит а в крайнем случае - легко нахожу по имени файла (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.

> Это уже задача планировщика оперативку распределять

Планировщика? Какого планировщика и где? Если что я про кеши самой СУБД говорил а не про дисковые кеши ОС. И зохаваную демоном сервера БД оперативу у него просто так не отберешь, пардон.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру