|
Недоступен liburl=http://free-books.dontexist.com/get?
| |
| Vadim_03 | Дата: Понедельник, 02.07.2012, 12:22 | Сообщение # 16 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
|
Error (509)
This account's public links are generating too much traffic and have been temporarily disabled!
Но, все равно, спасибо!
Quote Дело в том, что это не определено в идеологии самого либгена (в отличие от либруса). Согласись, ради одного человека не стоит усложнять алгоритм поиска (он и так, благодаря не совсем .... структуре базы, достаточно медленно пашет Я посмотрю, конечно, но вот обещать что это сделаю - не буду.
Это я не понял. Я всего навсего спросил, работает ли ваша программа с архивами, примерно так. как это делают ЛибРусЛиб и МайХоумЛиб, работающие с либрусеком. Причем тут мои пожелания?
Quote Это означает, что все поля приводятся к единой структуре Какого-то поля может и не быть, но 90% - будут. Автор, жанр, название и т д - без них никуда.
Не дошло. Что значит, к одной структуре? Кстати, полей в либгене хватает. Даже поле УДК есть, я его просто не заметил, оно там незаполннное, как правило. А вот дескрипторов нет.
Жанр, дескрипторы, УДК это хитрые поля их в одной книге может быть много. Например, Морс и Фишбах "Методы математической физики" - какой жанр?
УДК и жанр это одно и то же, просто удк это хорошо продуманное дерево, а жанр примитивный паллиатив.
Все это суета. Важна возможность добавлять поля. Допустим, у вас миллион книг. Вручную добавить и заполнить поле УДК нереально. Но, если есть ISBN, вы можете найти книгу в библиотеке конгресса и взять оттуда все описание со всеми полями. УДК там нет, но есть другие поля. А УДК точно так же можно вытянуть по ISBN из Лениники на весь миллион книг. Итог этой бурной деятельности рост числа полей, которые не предусмотрел автор, да и не нужно было их ему предусматривать. Он должен был предусмотреть добавление полей при эксплуатации базы. Многие pdf, djvu не имеют слоя текста. Но его ведь можно и добавить, причем программно, и сделать возможным полнотекстовый поиск гуглом. Это надо отобразить в базе - есть или нет текст? Куда его прилепить - к файлу или отдельно и завязать на файл через базу?
Quote Хорошо бы просто иметь возможность их добавлять. И, по примру IBM, дать эту возможность пользователю.
Ну, для этого есть поля для пользовательских ключевых слов и примечаний...
Насколько я понимаю, до всего этого очень трудно добраться программно. Вот, допустим, у меня миллион книг. Кроме чисто коллекционной радости это еще возможность найти то, что мне нужно в данный момент. Но ведь не буду же я, готовясь к этому будущему поиску, вручную заполнять поля у всего миллиона. Это нереально. Значит, вариантов несколько
1. Ждать, пока их заполнят другие любители.
2. Заполнить программно, скажем с помощью баз библиотеки Конгресса и Ленинки.
3. Просто использовать уже имеющиеся группировки, которые то ли сделал сам, то ли скачал в сгруппированном виде.
Но второй и третий вариант предполагают, что у меня должен быть доступ к заполнению этих полей программно. Или к добавлению полей. К примеру, ваш поиск средствами SQL вполне можно расширить и до модификаций базы, например, заполнению полей.Добавлено (02.07.2012, 10:34)
---------------------------------------------
Quote Quote (Vadim_03)
да еще и с именами файлов, которые даже компьютеру ничего не говорят, как это сделано в генезисе.
это очень даже правильно. При наличии поисково-информативной системы надобность в ручном поиске файлов напрочь отсутствует, а вот возможность не допустить дубляж - это хорошо.
Это не совсем так. Если у вас уже все ввиде свалки, поисковая система дает одни преимущества. А вот если есть некая структура – могут быть и недостатки. Структура уже может служить для поиска. Скачали пакет – это дерево жанров, иногда очень тонко настроенное на вас, и нужное. Дальше у вас две возможности.
1. Использовать структуру, как она есть. Это может быть очень быстро, если сравнить со временем, которое нужно для освоения SQL c нуля и написания на нем программ, а также вспомнить, как все реально работает. К примеру, я нашел книгу в генезисе вашей либгеной. Запустил «открыть». Пошел на пробежку. Вернулся. Еще не открыла. Принял душ, еще не открыла, выпил чай, глянул на экран. Там сообщение: книги нет, скачать? Это не ирония или преувеличение, это реальные события. Причем, его даже выключить нельзя, либген, пока он там что-то ищет. Только заткнуть силой с помощью Task manager. Компьютер – двухядерный 3.1 гигагерца с 4-8 гиг ОЗУ (зависит от того, какая ОС - 32 или 64) Причем базу для поиска я еще даже не начал заполнять, там только небольшая часть линков на книги.
2. Использовать структуру для автоматического заполнения полей базы. Ведь дерево директориев это дерево жанров.
Quote никто не заставляет переструктурировать сами книги... А вот базу - очень даже. На самом деле - ручной работы - не сильно много. Достаточно написать несколько скриптов (парсеров) для того что бы на 90% причесать базу. Авторов и темы...
Но, в переводе на простой русский язык, эти ваши слова и означают, что совместно с вашей либгеной надо использовать линки. Их то я могу обзывать, как либгене угодно, и структурировать, как она захочет. А слова про базу означают, что я должен иметь возможность добавлять и заполнять поля.
Quote угу... давай каждому в дом по кластеру в тысячу серверов
А так уже и случилось. На хабе висят мужики с 49 и более расшаренными терабайтами. Расшаренными! А сколько там у них стоит дома – это покрыто мраком. Если в норме надо иметь 3 дубля, то речь идет о, примерно, 150-200 терабайтах. Это, кстати говоря, не так уж и много денег – 10000 евро. Полмашины или одна пятая венецианской гондолы
Хотя гуглу десктопу плевать на ваши или мои терабайты – он и десятком гигабайта удовлетворится. Ему будет только лучше.Добавлено (02.07.2012, 10:35)
---------------------------------------------
Quote Понимаешь, есть понятие достаточности и избыточности. В данном случае, для 95% пользователей надо иметь поиск по теме и автору. Я смотрел на профессиональные библиотечные системы и понял - только профессионалам (и то сомнительно) это нужно. Мы же говорим о домашней системе... Тут надо компромис - простота и скорость.
А вот это вообще не понял. Искать по автору можно, только если его знаешь. Т.е вы уже знаете о книге почти все, и, всего навсего, хотите найти ее у себя в библиотеке. Это вообще понять не могу. Либо у вас файлы кучей, и их просто можно поискать тотальным коммандером, или иным менеджером, особенно, если есть индексация файлов. Или тем же гуглом десктопом. Он найдет вам за мгновение, просто пока набираете фамилию, уж точно во много раз быстрее, чем либген.
А поиск по теме вообще перевести на понятный мне язык не смог. Это что, поиск по жанру? Беру свой пример, вполне конкретный. Хочу найти книги по проектированию интегральных схем, желательно свежие. Ну и как мне их искать? Это какая тема то? Какой жанр? Электроника, что ли? А автора я заведомо не знаю, да их и тысячи. А по жанру «электроника» на меня вывалит столько книг, что просматривать их аннотации до конца жизни можно.
Запускаю поиск «microelectronic». Но это сработает только, если это слово попало в название книги. Если она у меня на дисках, обойдусь и без либгена – гугл десктоп ее найдет быстрее. Т.е либген нужен и сработает, только если у меня ее нет, но она есть в генезисе, в его базе, и если я удачно выбрал слово и оно есть в названии. А сколько книг остались за бортом такого идиотского поиска? Причем. вынуждено идиотского. А как искать то, в моих условиях?
Или еще иначе. Лезу в библиотеку конгресса, ищу там, нахожу подборку, и начинаю ее по одной проверять либгеном или гуглом десктопом. Т.е фактически поиск был на стороне, а тут я просто поискал, а нет ли ее уже у меня на диске? Кстати, в библиотеке конгресса особо не полазишь – там тоже не так много возможностей поиска.
В данном случае, в итоге книга нашлась в либгене, но вот скачать ее – облом. Она 500 мегабайт. И скачал я ее, родимую, уже торрентом. Но сколько книг я так не нашел. куда более мне полезных, – так и не узнаю. И, слава богу, меньше расстройства.Добавлено (02.07.2012, 11:07)
---------------------------------------------
Это все к чему? Если книги на диске просто коллекция из любви к искусству, зачем либген? Если этот миллион книг еще и база, в которой время от времени что то ищешь по новой для себя тематике, то нужна именно система поиска нужной, но неизвестной пока книги, а не просто возможность найти книгу по уже точно известным данным - автору, MD5, TTH, точному названию и т.п. Узкому профи книги по его узкой специальности вообще не нужны. Он сам их пишет. Ему нужны статьи в журналах или еще где. А в базе книг начинаешь рыться, когда нужно освоить что-то новое, т.е выступаешь в роли чайника. Вот тогда то либген и заранее припасенные книги сработают. Но только в том случае, если система поиска хороша. А иначе, зачем либген? Т.е. ваша концепция, изложенная в цитате, делает либген просто ненужным. Если автор и название известны- хватит файловго менеджера или гугла десктопа. Если либген искать не помогает, и все равно нужно искать на стороне, то нафига он тогда нужен? Добавлено (02.07.2012, 11:22)
---------------------------------------------
Quote Т.е не хочется вытягивать колхоз с его структурой каталогов в один слой
а кто сказал про один слой???? дерево - оно и в африке дерево...
Книги генезиса размещены в один слой. Разбиение их на тысячи или десятки тысяч это только формально - дерево. А вот колхоз вполне самодостаточная структура с возможностью поиска по тематике (жанрам). SL с ее 400 гигабайтами - это один слой, формально разбитый на DVD.
А вот какой нибудь пакет книг "Мой дом", с подразделами мебель, теплоизоляция и т.п. - вполне себе дерево.
|
| |
| |
| drserj | Дата: Понедельник, 02.07.2012, 13:17 | Сообщение # 17 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Это я не понял. Я всего навсего спросил, работает ли ваша программа с архивами, примерно так. как это делают ЛибРусЛиб и МайХоумЛиб, работающие с либрусеком. Причем тут мои пожелания?
Как это причем?  Если идея здравая - почему бы не реализовать, а если сомнительная - бум думать.
Quote (Vadim_03) Не дошло. Что значит, к одной структуре?
Это значит, что в мультилибе есть какая-то единая структура данных (поля), есть модули импорта, которые берут данные из произвольной библиотеки и загоняют ее в базу мультилиба в формате мультилиба. Ведь в разных библиотеках типы полей, названия, количество - отличаются. А для работы программы требуется однотипная структура.
Quote (Vadim_03) Важна возможность добавлять поля
А вот этого точно не будет. Как ты это себе представляешь? Ну, добавил ты поле (не вопрос), а запросы формировать как? А формы? А таблицы? Они же забиваются в программе железно... Я не спорю, теоретически можно создать подобную систему, но это уже будет не программа а СУБД, что для конечного юзверя смерти подобно
Quote (Vadim_03) Он должен был предусмотреть добавление полей при эксплуатации базы.
см. выше... Это малореально...
Quote (Vadim_03) Насколько я понимаю, до всего этого очень трудно добраться программно.
Да нет, поставить MySQL сервер и закинуть туда файлы таблиц
drSerj
|
| |
| |
| drserj | Дата: Понедельник, 02.07.2012, 13:23 | Сообщение # 18 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Это не совсем так. Если у вас уже все ввиде свалки, поисковая система дает одни преимущества. А вот если есть некая структура – могут быть и недостатки. Структура уже может служить для поиска. Скачали пакет – это дерево жанров, иногда очень тонко настроенное на вас, и нужное. Дальше у вас две возможности. 1. Использовать структуру, как она есть. Это может быть очень быстро, если сравнить со временем, которое нужно для освоения SQL c нуля и написания на нем программ, а также вспомнить, как все реально работает. К примеру, я нашел книгу в генезисе вашей либгеной. Запустил «открыть». Пошел на пробежку. Вернулся. Еще не открыла. Принял душ, еще не открыла, выпил чай, глянул на экран. Там сообщение: книги нет, скачать? Это не ирония или преувеличение, это реальные события. Причем, его даже выключить нельзя, либген, пока он там что-то ищет. Только заткнуть силой с помощью Task manager. Компьютер – двухядерный 3.1 гигагерца с 4-8 гиг ОЗУ (зависит от того, какая ОС - 32 или 64) Причем базу для поиска я еще даже не начал заполнять, там только небольшая часть линков на книги. 2. Использовать структуру для автоматического заполнения полей базы. Ведь дерево директориев это дерево жанров.
Дело в том, что обычно программа пишется под потребности большинства. Я согласен, универсальная программа может и круче, но... А сколько человек будут юзать те функции, которые ты описал? А теперь посмотрим, сколько времени и сил потребуется на их реализацию... А какой мощности понадобится комп, на котором будет работать подобный монстр??? В теории кажется, что это достаточно просто. На самом деле - добавление одного текстового поля (да еще и индексированного) приведет к заметным тормозам и дикому увеличению объема самой базы. "Искусственный Интеллект", который будет разруливать все структуры (а это формирование запросов к базе, создание динамических форм, и т д) усугубит эти тормоза на пару порядков... Стоит оно того? Скажут ли спасибо те 99%, кому оно и нафиг не надо?
drSerj
|
| |
| |
| drserj | Дата: Понедельник, 02.07.2012, 13:31 | Сообщение # 19 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) А вот это вообще не понял. Искать по автору можно, только если его знаешь. Т.е вы уже знаете о книге почти все, и, всего навсего, хотите найти ее у себя в библиотеке. Это вообще понять не могу. Либо у вас файлы кучей, и их просто можно поискать тотальным коммандером, или иным менеджером, особенно, если есть индексация файлов. Или тем же гуглом десктопом. Он найдет вам за мгновение, просто пока набираете фамилию, уж точно во много раз быстрее, чем либген. А поиск по теме вообще перевести на понятный мне язык не смог. Это что, поиск по жанру? Беру свой пример, вполне конкретный. Хочу найти книги по проектированию интегральных схем, желательно свежие. Ну и как мне их искать? Это какая тема то? Какой жанр? Электроника, что ли? А автора я заведомо не знаю, да их и тысячи. А по жанру «электроника» на меня вывалит столько книг, что просматривать их аннотации до конца жизни можно. Запускаю поиск «microelectronic». Но это сработает только, если это слово попало в название книги. Если она у меня на дисках, обойдусь и без либгена – гугл десктоп ее найдет быстрее. Т.е либген нужен и сработает, только если у меня ее нет, но она есть в генезисе, в его базе, и если я удачно выбрал слово и оно есть в названии. А сколько книг остались за бортом такого идиотского поиска? Причем. вынуждено идиотского. А как искать то, в моих условиях?
Критерии поиска - это проблема пользователя. Если пользователь создаст толковый запрос, получит толковую выборку. Я говорю о том, что в большинстве своем, люди ищут конкретные книги конкретных авторов, конкретные тематики (жанры). Если вбить в гугл десктоп "математика"- там тоже получатся миллионы ссылок. Задача Либгена - собрать как можно больше книг. Задача Либген-библиотекаря - дать возможность более комфортно, в офлайне получить информацию о том, есть ли такие книги в библиотеке и скачать их оптом или в розницу. Либген-библиотекарь не позиционируется как библиотечная программа. Это расширение поисковых функций самого либгена. Вся структура базы либгена загружается из сети. Если я внесу изменения в базу, при следующей загрузке они не сохранятся.
drSerj
|
| |
| |
| drserj | Дата: Понедельник, 02.07.2012, 13:36 | Сообщение # 20 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Если автор и название известны- хватит файловго менеджера или гугла десктопа. Если либген искать не помогает, и все равно нужно искать на стороне, то нафига он тогда нужен?
Вот и я думаю, нахрена этот либген? Может лучше вообще на него забить?.... Quote (Vadim_03) Книги генезиса размещены в один слой. Разбиение их на тысячи или десятки тысяч это только формально - дерево.
Именно !!!! Я об этом и говорю. Слили всё в одно поле... Надо парсить и строить дерево. И я бы построил, но... как уже писалось выше - следующий импорт всё это похерит. Делать это надо на исходной базе, на самом либгене... Но я к нему вообще отношения не имею...
drSerj
|
| |
| |
| 1_абрам | Дата: Понедельник, 02.07.2012, 16:18 | Сообщение # 21 |
|
Генералиссимус
Группа: Друзья
Сообщений: 1207
Статус: Offline
| Quote (drserj) Вот и я думаю, нахрена этот либген? Может лучше вообще на него забить?....
Полная чушь, либген очень нужная и удобная программа, прототип мультилиба.
|
| |
| |
| Vadim_03 | Дата: Вторник, 03.07.2012, 10:41 | Сообщение # 22 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
| Quote Как это причем? Если идея здравая - почему бы не реализовать, а если сомнительная - бум думать.
Все таки вы тратите на это сугубо личное время. Как то неудобно.
Quote Это значит, что в мультилибе есть какая-то единая структура данных (поля), есть модули импорта, которые берут данные из произвольной библиотеки и загоняют ее в базу мультилиба в формате мультилиба. Ведь в разных библиотеках типы полей, названия, количество - отличаются. А для работы программы требуется однотипная структура.
Просто пользователь должен иметь возможность составить таблицу соответствия полей. Если соответствия нет – добавить поле. При этом при merge (а как это сказать то по русски?) часть полей для части книг будет пустой, ну и что?
Quote А вот этого точно не будет. Как ты это себе представляешь? Ну, добавил ты поле (не вопрос), а запросы формировать как? А формы? А таблицы? Они же забиваются в программе железно... Я не спорю, теоретически можно создать подобную систему, но это уже будет не программа а СУБД, что для конечного юзверя смерти подобно
Но вы это уже сделали! Т.е «железно забитые» действия не будут учитывать новые поля. Однако, у вас есть возможность формировать запросы на SQL. Кто пожелает – там их может задействовать. Хочешь – учи, хочешь – не учи. Твои проблемы. Добавление поля, если я не ошибаюсь, и есть добавление таблицы, точнее, ее модификация. А запросы, если не ошибаюсь, это составление отчета и его форматирование – распихивание по полям формы. Если пользователю нужен нестандартный (для данной программы) отчет, обойдется без распихвания.
Quote Да нет, поставить MySQL сервер и закинуть туда файлы таблиц
У меня стоит и MySQL и SQL. Что, если я просто создам проект с таблицами из data, то смогу жить и без либгена? Это было бы хорошо. Либген мне нравится, но свобода нравится больше!
Quote Дело в том, что обычно программа пишется под потребности большинства. Я согласен, универсальная программа может и круче, но... А сколько человек будут юзать те функции, которые ты описал? А теперь посмотрим, сколько времени и сил потребуется на их реализацию... А какой мощности понадобится комп, на котором будет работать подобный монстр??? В теории кажется, что это достаточно просто. На самом деле - добавление одного текстового поля (да еще и индексированного) приведет к заметным тормозам и дикому увеличению объема самой базы. "Искусственный Интеллект", который будет разруливать все структуры (а это формирование запросов к базе, создание динамических форм, и т д) усугубит эти тормоза на пару порядков... Стоит оно того? Скажут ли спасибо те 99%, кому оно и нафиг не надо?
Я не владею статистикой того, кому что надо. Так что даже не пытался обсуждать это. Полагаю, вам виднее. Но, если вы считаете, что 99 процентов ищут только по автору, или по одному из немногих жанров, то либген им просто не нужен. Эти два вида поиска гораздо быстрее проводить, например, гуглом десктоп. А очень приятная функция – автоматический запрос пакетом того, что не нашел, к сожалению, по факту не работает.Добавлено (03.07.2012, 09:41)
---------------------------------------------
Quote Критерии поиска - это проблема пользователя. Если пользователь создаст толковый запрос, получит толковую выборку. Я говорю о том, что в большинстве своем, люди ищут конкретные книги конкретных авторов, конкретные тематики (жанры). Если вбить в гугл десктоп "математика"- там тоже получатся миллионы ссылок. Задача Либгена - собрать как можно больше книг. Задача Либген-библиотекаря - дать возможность более комфортно, в офлайне получить информацию о том, есть ли такие книги в библиотеке и скачать их оптом или в розницу. Либген-библиотекарь не позиционируется как библиотечная программа. Это расширение поисковых функций самого либгена. Вся структура базы либгена загружается из сети. Если я внесу изменения в базу, при следующей загрузке они не сохранятся.
Если сайт генезиса пашет, то искать там по автору, по одному слову из названия, по названию, по жанру и качать – одно удовольствие. Правда, до тех пор, пока не получишь сообщение о том, что книга слишком велика, или что сайт временно не доступен. Или не выяснится, что силы у добровольцев кончились и он умер навсегда. Т.е., либген по вашему замыслу это средство выжить, когда сайт упал, или средство для тех, кому интернет не всегда доступен, но никак не средство для упорядочивания своей коллекции или серьезного поиска. Я правильно вас понял?
Если это так, на всякий случай вопрос. Смогу ли я использовать его таблицы в SQL без серьезной переделки?
Quote Вот и я думаю, нахрена этот либген? Может лучше вообще на него забить?.
Мне нравится. И, так как он у меня уже есть, то, если вы забьете, я буду огорчен, но не пропаду. Другое дело, что все время пытаюсь найти в нем скрытые вами от широкой публики возможности. Или не скрытые, но малопонятные для чайников, вроде меня.
Quote (Vadim_03)
Quote Книги генезиса размещены в один слой. Разбиение их на тысячи или десятки тысяч это только формально - дерево.
Quote Именно !!!! Я об этом и говорю. Слили всё в одно поле... Надо парсить и строить дерево. И я бы построил, но... как уже писалось выше - следующий импорт всё это похерит. Делать это надо на исходной базе, на самом либгене... Но я к нему вообще отношения не имею...
А вот тут я с вами не согласен. База данных позволяет на размещенные в один слой файлы смотреть под самыми разными углами. Т.е создавать деревья динамически, в ходе запроса и составления отчета, а не забивать их в структуру на диске. Так что это очень правильный подход. Так и надо делать, просто надо еще учитывать возможности файловой системы по поиску файлов при очень их большом количестве в одном директории. И присвоение в качестве имени какой –либо контрольной суммы (хэша) тоже правильно. Хотя надо иметь еще и внутренние хэши, чтобы можно было искать «похожие» файлы, а не только в точности одинаковые. И поля в генезисе очень прилично выбраны. Один только ISBN огромная ценность.
Недостатки в другом. Все это, и в самом генезисе, и у вас, должно быть открыто и, по возможности, описано. Как это сделали в свое время разработчики IBM PC- чтобы можно было и самому что-то делать, не мороча голову добровольцам разработчикам. То, что для вас ясно и очевидно, я должен выяснять путем анализа, причем всегда есть опасность того, что выяснил неправильно.
Кроме того, есть недостатки связанные с масштабами задачи. Все очень медленно работает. Просто на то, чтобы выяснить, что книги в локальном собрании нет, могут уходить часы, а в дальнейшем и дни.
|
| |
| |
| drserj | Дата: Вторник, 03.07.2012, 12:23 | Сообщение # 23 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Кто пожелает – там их может задействовать.
угу.. вот только в таблице они не отобразятся.. ну нет в таблице таких столбцов...
Quote (Vadim_03) У меня стоит и MySQL и SQL. Что, если я просто создам проект с таблицами из data, то смогу жить и без либгена? Это было бы хорошо. Либген мне нравится, но свобода нравится больше!
естественно сможешь... возьми дамп либгена (он на mysql), импортируй в базу и делай любые выборки любым мускульным клиентом...
Quote (Vadim_03) Если сайт генезиса пашет, то искать там по автору, по одному слову из названия, по названию, по жанру и качать – одно удовольствие.
угу... пробовал, спасибо не надо группировки, сортировки где? Большая часть полей не отображается...
Quote (Vadim_03) То, что для вас ясно и очевидно, я должен выяснять путем анализа, причем всегда есть опасность того, что выяснил неправильно.
Дык я и выясняю путем анализа Мне никто ничего не давал и не рассказывал. Всё разгребал сам.
Quote (Vadim_03) Кроме того, есть недостатки связанные с масштабами задачи. Все очень медленно работает. Просто на то, чтобы выяснить, что книги в локальном собрании нет, могут уходить часы, а в дальнейшем и дни.
что есть - то есть... это как последствия изначально неправильно спроектированной базы, так и слабой мощности персоналок... А что делать? Хорошо хоть это есть...
drSerj
|
| |
| |
| Vadim_03 | Дата: Четверг, 05.07.2012, 11:16 | Сообщение # 24 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
| Quote угу.. вот только в таблице они не отобразятся.. ну нет в таблице таких столбцов
Таблицу всегда можно преобразовать, в том числе добавить столбцы.
Quote естественно сможешь... возьми дамп либгена (он на mysql), импортируй в базу и делай любые выборки любым мускульным клиентом.
Спасибо. Буду разбираться.
Quote угу... пробовал, спасибо не надо группировки, сортировки где? Большая часть полей не отображается...
Ну и где ваша логика и последовательность? Вы пишите, что 99 процентов пользователей нужно искать книгу по автору или названию. Не подборку делать, не поиск литературы по теме производить, а проверять, есть ли нужная ему и известная книга в данном собрании. Причем тут группировки, сортировки? Книга же одна. В крайнем случае, штук десять одного автора или штук 5 дублей, неизвестно чем отличающихся. Это мне, попадающему, по вашим словам, в 1-0 процентов пользователей нужно что-то искать, а значит группировать, сортировать и т.п.
Я уже не говорю о том, что моя реакция была именно на ваши слова про поиск по автору.
Quote Дык я и выясняю путем анализа Мне никто ничего не давал и не рассказывал. Всё разгребал сам.
Т.е вы не имели описания их базы? Все экспериментально? Сочувствую и преисполняюсь еще большего уважения.Добавлено (05.07.2012, 10:16)
---------------------------------------------
Quote что есть - то есть... это как последствия изначально неправильно спроектированной базы, так и слабой мощности персоналок... А что делать? Хорошо хоть это есть...
Это мои два процессора, 4 гигабайта ОЗУ (при 32 разрядной ОС) и 3.1 гигагерц слабая? А какая нужна? Т.е я жду, скажем, час или больше. Хочу ждать, скажем, не более 1-2 минуты. Значит мне надо добыть персоналку на 8 процессоров по 24 гигагерца, а лучше 128 процессоров и 128 гигагерц.
Я склонен думать, что есть и иные решения. Например, весь список книг, которые у меня есть, если его держать виде таблицы из хэшей по 32 байта на книгу, это порядка 32 мегабайт, т.е он без проблем помещается в одну сортированную переменную в ОЗУ. И запрос к этой переменной можно делать за миллисекунды. Причем у меня, просто в процессе создания линков, создается файл, их перечисляющий, в котором полный путь, и хэш. Так что и создавать ничего не надо – считай в процессе загрузки это файл и ву а ля. Ну, может быть, еще его отсортировать один раз после каждого дополнения. Поскольку каждый такой хэш это имя линка, то еще потребуется меньше секунды, чтобы, если он есть, его запустить и вытащить книгу. Когда я гляжу в task manager, то там что ни программа, то куда больше есть памяти, иногда и по гигабайту.
Кстати, наверное, так и сделаю. Поскольку, благодаря вам, я теперь умею запускать программу при попытке чтения книги, то мне, всего навсего, потребуется из моих сотен тысяч линков сделать один мультилинк в одном скромном файле на 250 мегабайт и как то отрубить попытки вашей программы самостоятельно искать есть файл или нет. Пусть всегда считает, что надо включать внешнюю программу для чтения.
Мне, правда, кажется, что вышеизложенное просто попытка изобрести велосипед. Нормальная база данных, тот же SQL, что то подобное должна уметь делать и без моих дилетантских идей. Просто я пока плохо ее знаю.
|
| |
| |
| drserj | Дата: Пятница, 06.07.2012, 09:55 | Сообщение # 25 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Ну и где ваша логика и последовательность? Вы пишите, что 99 процентов пользователей нужно искать книгу по автору или названию.
Совершенно верно. Но у автора, к примеру, может быть много книг... И каким боком группировка и сортировка нарушают мою логику?
Quote (Vadim_03) Это мои два процессора, 4 гигабайта ОЗУ (при 32 разрядной ОС) и 3.1 гигагерц слабая?
А ты смотрел сколько процессоров у тебя занимается этим процессом? Да и тормоза, как правило, из-за скорости винта и файловой системы... Поставь рейд - скорость повысится. Добавь памяти - тоже. Не на всех операциях ессесно, но на большей части. Чем больше файлов - тем ниже скорость поиска (вычитки каталога). Чем больше дефрагментация - тем ниже скорость на всех операциях (как чтения так и записи).
Quote (Vadim_03) весь список книг, которые у меня есть, если его держать виде таблицы из хэшей по 32 байта на книгу, это порядка 32 мегабайт, т.е он без проблем помещается в одну сортированную переменную в ОЗУ.
Угу.. а получить этот список? А это 95% времени... Сам поиск книги в списке - это от милисекунд до единиц секунд при сложной выборке. Все остальное время - дисковые операции...
Quote (Vadim_03) Мне, правда, кажется, что вышеизложенное просто попытка изобрести велосипед.
Знаешь, ведь сколько лет велосипед существует, а его всё изобретают и изобретают
Quote (Vadim_03) Нормальная база данных, тот же SQL, что то подобное должна уметь делать и без моих дилетантских идей. Просто я пока плохо ее знаю.
Немного не понял, какая связь между файлами и базой?
drSerj
|
| |
| |
| Vadim_03 | Дата: Суббота, 07.07.2012, 10:22 | Сообщение # 26 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
| Quote Совершенно верно. Но у автора, к примеру, может быть много книг... И каким боком группировка и сортировка нарушают мою логику?
Врядли больше 20. Да и таких не встречал. А ради 20 не стоит сортировать, проще просмотреть. К тому же, речь идет про технику. Автор пишет по одной тематике. Как сортировать то?
Quote А ты смотрел сколько процессоров у тебя занимается этим процессом?
Task Manadger обычно показывает два.
Quote Да и тормоза, как правило, из-за скорости винта и файловой системы... Поставь рейд - скорость повысится.
Чего ради? О каком именно рейде речь? Там или избыточность для надеги, или запись одного и того же сразу на два диска, для резерва, кажется, один из вариантов - читать два диска в параллель. Даст ли это прирост скорости? большой вопрос. Дело в том, что основной проигрыш на перемещении головки. Что тут дадут два диска? Потом, у меня диски, так сказать в теории, дают 100 мегабайт или больше, а на практике, при копировании, редко больше 20. Совершенно не ясно, где затык - в неумении процессора быстро работать с дисками, или в дисках.
Quote Добавь памяти - тоже. Не на всех операциях ессесно, но на большей части.
Но я вам несколько раз писал, что она предельная - 4 гига. Собственно, памяти в компьютере 8 гиг, просто 32 разрядная ОС их не может использовать. А 64 разрядная у меня неправильно вскрыта и через час вырубается. Впрочем, ваша программа берет не так уж и много, обычно, меньше гига.Добавлено (07.07.2012, 09:22)
---------------------------------------------
Quote
Чем больше файлов - тем ниже скорость поиска (вычитки каталога). Чем больше дефрагментация - тем ниже скорость на всех операциях (как чтения так и записи).
А вот это уже относится к тому, о чем я написал - к вызывающему у меня сомнения подходу к работе с базой. Поскольку я, кроме пары ваших полунамеков, ничего не знаю о том, как это сделано, то и критиковать не могу. Вполне может быть, что сделано идеально, и лучше просто не может быть. Так что, когда попробую сам один из вариантов, тогда и получу право что то сказать. Пока же могу просто почти молча страдать.
Quote Угу.. а получить этот список? А это 95% времени... Сам поиск книги в списке - это от милисекунд до единиц секунд при сложной выборке. Все остальное время - дисковые операции...
В моем случае - пара недель, максимум, хотя, скорее всего, пара суток. Мне, строго говоря, на это время плевать. Запустил процесс и единственная затрата - электроэнергия - 60 центов в сутки. Он почти разовый. Список надо обновлять только при добавлении пакета книг, но, думаю, это можно сделать без повторного чтения всех файлов на всех дисках, просто добавить новую информацию и отсортировать. Мне важно, чтобы я не ждал, когда ищу. Так что, единственная проблема - это перехват команд у вашей программы. К тому же, все равно надо получить список книг, которые есть. В общем, я не очень разобрался, что за таблицы вы используете. Но у меня есть сильное подозрение, что среди них нет перечня книг на локальном компьютере. Если бы он был, то отсортировав его по MD5, можно было бы очень быстро находить нужную строку таблице списка. А в данный момент программа ведет себя загадочно. Иногда выдает ответ – есть книга или нет, за пару минут, иногда за пару часов, иногда вообще не выдает, хотя в директориях, которые ей объявлены, всего 230000 файлов и 160 гиг (большая часть книг – линки). Между прочим, Тотал Коммандер тоже подсчитывал эту статистику минут 20 -30. Так что, такой метод работы явно порочен.
Quote Знаешь, ведь сколько лет велосипед существует, а его всё изобретают и изобретают
Это не повод самому этим заниматься. Хотя, часто просще его изобрести, чем найти подходящий.
Quote Немного не понял, какая связь между файлами и базой?
Я не силен в терминологии и называю словом база как сами таблицы в их совокупности, так и систему для работы с ними.
|
| |
| |
| drserj | Дата: Суббота, 07.07.2012, 12:14 | Сообщение # 27 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) Task Manadger обычно показывает два.
на моей программе? Не верю!
Quote (Vadim_03) один из вариантов - читать два диска в параллель. Даст ли это прирост скорости?
Ты не поверишь, именно на чтение даже всего 2 диска в рейде дадут прирост минимум на 50% Я когда на работе поставил - ощутил, а когда рейд разобрал - ощутил еще больше, без рейда - такие тормоза
Quote (Vadim_03) сделано идеально, и лучше просто не может быть.
да может, естественно...просто я отталкиваюсь только от идеологии либгена, если бы я планировал подобную систему, всё было бы несколько по-другому. Но что имеем - то имеем...
Quote (Vadim_03) В общем, я не очень разобрался, что за таблицы вы используете. Но у меня есть сильное подозрение, что среди них нет перечня книг на локальном компьютере.
Я использую тот дамп базы, который выкладывает либген. А в моих таблицах - только локальная информация о скачках, пользовательских группах и т д. Почему я и говорю - можно было бы всё значительно улучшить, но, поскольку я использую готовые дампы базы либгена - вмешаться в структуру не могу.
Quote (Vadim_03) Хотя, часто просще его изобрести, чем найти подходящий.
Именно!
drSerj
|
| |
| |
| Vadim_03 | Дата: Суббота, 07.07.2012, 17:53 | Сообщение # 28 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
| Quote на моей программе? Не верю!
Но я и не говорю, что именно процесс с вашей программой идет на 2 процессорах. В окошке видно, что трудятся оба, а чем заняты - ала верды, я точно не знаю. Однако, кроме вашей программы идет еще уйма процессов, которые могут (теоретически) идти не там. где ваша программа, т.е оставят ей больше рессурсов.
Quote Ты не поверишь, именно на чтение даже всего 2 диска в рейде дадут прирост минимум на 50% Я когда на работе поставил - ощутил, а когда рейд разобрал - ощутил еще больше, без рейда - такие тормоза
Я бы не поверил в 100 процентов. А в 50 верю без напряжения своей доверительной способности. Хотя, это наверняка зависит от задачи, т.е цифра малоинформативна. Однако, даже 100 процентов ( в два раза) мне бы ничего не дали. Ну не час надо ждать, или не два, а полчаса - час. Все равно надо в промежутке чай заваривать и пить. После каждой книжки, которую попросил открыть! Это ж сколько чаю надо выпить!
Quote Я использую тот дамп базы, который выкладывает либген. А в моих таблицах - только локальная информация о скачках, пользовательских группах и т д. Почему я и говорю - можно было бы всё значительно улучшить, но, поскольку я использую готовые дампы базы либгена - вмешаться в структуру не могу.
Вы это уже несколько раз написали, так что я это понял. Но это не мешает мне не понимать, как кокретно вы решаете задачу - проверить, есть ли книга на локальном компьютере. Вы же вполне можете завести себе некую таблицу - котрольная сумма - путь к файлу у пользователя. А можете не завести. Кто вас знает?. Вы, правда, написали, что просто шарите по указанным в настройках директориям, так что, скорее всего такой таблицы нет.
Я не очень понимаю это ваше заявление "поскольку я использую готовые дампы базы либгена - вмешаться в структуру не могу.". Никто вам не запрещает дополнять их базу любыми нужными вам таблицами. Насколько я понимаю, на SQL вполне можно написать программу для автоматического преобразования базы в несколько иной вид. Процесс. в общем, однократный, при инсталяции программы или обновлении базы. Учитывая, что реального обновления уже год нет, трагедии в том, чтобы час - два погонять такую SQL программу я не вижу.
В общем, попробую написать "велосипед", который будет делать следующее:
1. брать у пользователя MD5. Пока - руками, перехват данных из вашей программы еще надо научиться делать. Вот если бы заставить ее не проверять наличие файла, а сразу запускать предусмотренную настройками программу, было бы проще.
2. Искать в большой таблице, загруженной в ОЗУ, прредварительно отсортированной, этот MD5. Если не найдет - сообщать увы и ах, книжки нет Если найдет - дальше.
3. Номер строки, где он его найдет, рассматривать как номер записи в файле с путями.
4. Читать эту запись.
5 Искать данный файл и загружать его.
Вот интересно, сколько это будет занимать времени на моих дисках и с моим количеством файлов (250000).
|
| |
| |
| drserj | Дата: Воскресенье, 08.07.2012, 18:41 | Сообщение # 29 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Quote (Vadim_03) А в 50 верю без напряжения своей доверительной способности.
Ну, а если, скажем, рейд 5, да штук 5 дисков? Отож...
Quote (Vadim_03) После каждой книжки, которую попросил открыть! Это ж сколько чаю надо выпить!
Ну не верю я в такую скорость... Самый первый (и единственный раз) - да, долго, пока весь каталог считает, а потом - всё из кеша на уровне винды - достаточно быстро...
Quote (Vadim_03) Вы же вполне можете завести себе некую таблицу - котрольная сумма - путь к файлу
Дык дело в том, что считывать каталог всё равно прийдется!!! Путь и так указан в настройках...
Quote (Vadim_03) Никто вам не запрещает дополнять их базу любыми нужными вам таблицами. Насколько я понимаю, на SQL вполне можно написать программу для автоматического преобразования базы в несколько иной вид.
Да естественно, не мешает, и я это делаю, но.... На это уходит дико большое количество времени. Ведь этот дамп либгена надо всё-равно скачать, распаковать, преобразовать, загрузить в базу... А потом еще и преобразовывать в свой формат.... Пара часов - минимум... Если обновлять раз в месяц - ладно, а если ежедневно???
Quote (Vadim_03) Вот если бы заставить ее не проверять наличие файла, а сразу запускать предусмотренную настройками программу, было бы проще.
Я согласен с тем, что такая форма поиска имеет место быть, но... Одним из пунктов ТЗ была реализация поиска книги в разных каталогах (в том числе и на разных дисках), а такая постановка задачи с вышеуказанным вариантом жесткой привязки никак не совместимы 
Quote (Vadim_03) Вот интересно, сколько это будет занимать времени на моих дисках и с моим количеством файлов
ммм... я не уверен, конечно, но если при попытке обращения к книге не считывается весь каталог - практически мгновенно... Но при этом - малейшее изменение структуры хранения контента - и программа работать не будет. Ведь моя программа, в принципе, так и делает - лепит к файлу путь, но потом ищет файл, а не сразу его открывает (на что и идет 99% времени). Если-бы путь к хранилищу был один - твой вариант был бы оптимален, но, к сожалению, в общем случае он не катит
Хотя... Знаешь, я попробую открывать файл без поиска... В конце концов, можно это сунуть в try - except и отслеживать по наличию ошибки... Может и сработает... Тут только экспериментировать надо Может действительно ускорится...
drSerj
|
| |
| |
| Vadim_03 | Дата: Понедельник, 09.07.2012, 20:05 | Сообщение # 30 |
|
Сержант
Группа: Пользователи
Сообщений: 38
Статус: Offline
| Quote Ну, а если, скажем, рейд 5, да штук 5 дисков? Отож...
А скорость не упадет? Один диск избыточный, 4 пашут, а время идет и на операцию проверки. Вполне может стать слабым местом процессор. Думаю, выигрыш в 3 раза по скорости не очевиден. Не удивлюсь и проигрышу.
Quote Ну не верю я в такую скорость... Самый первый (и единственный раз) - да, долго, пока весь каталог считает, а потом - всё из кеша на уровне винды - достаточно быстро...
Не знаю, о каком кэше речь. Реально, то мгновенно, то не дождаться. Иногда вообще приходится перезапускать программу с использованием Task manager.
Quote (Vadim_03)
Вы же вполне можете завести себе некую таблицу - котрольная сумма - путь к файлу
Quote Дык дело в том, что считывать каталог всё равно прийдется!!! Путь и так указан в настройках...
Не знаю, как у вас задумано. Если уж я сел за библиотеку, то, значит, что то ищу, и это больше часа. Так что переходные процессы в начале меня не волнуют. Я могу во время этих процессов и что то другое делать. Но вот я составил с помощью системы поиска некий список из пары десятков или сотен книг и решил выбрать из них то, что нужно, просматривая аннотации и сами книги. И вот тут ждать появления книги на экране по несколько минут или часов я не согласен!
Quote Да естественно, не мешает, и я это делаю, но.... На это уходит дико большое количество времени. Ведь этот дамп либгена надо всё-равно скачать, распаковать, преобразовать, загрузить в базу... А потом еще и преобразовывать в свой формат.... Пара часов - минимум... Если обновлять раз в месяц - ладно, а если ежедневно???
А где вы нашли свежий дамп базы? У меня годичной давности и скачать более новый я не сумел. Откройте тайну, бите! Но пусть есть некто, имеющий возможность и желание качать гигабайтную свежую базу каждый день. Процесс ее переработки фоновый. То, что на нее уйдет два часа работы компьютера, даже и не заметишь. Сидишь, что то делаешь, а он молотит базу. Ну и что?Добавлено (09.07.2012, 18:58)
---------------------------------------------
Quote (Vadim_03)
Вот если бы заставить ее не проверять наличие файла, а сразу запускать предусмотренную настройками программу, было бы проще.
Quote Я согласен с тем, что такая форма поиска имеет место быть, но... Одним из пунктов ТЗ была реализация поиска книги в разных каталогах (в том числе и на разных дисках), а такая постановка задачи с вышеуказанным вариантом жесткой привязки никак не совместимы
Вполне совместима и я совместил и проверил. Я делаю сводную таблицу, в которой имеется путь и MD5. Для 130000 файлов (взял для теста, это несколько библиотек – Ингсат, колхоз, драгар и т.п.) она примерно 20 мегабайт. Затягиваю ее в переменную (string[130000]), сортирую по MD5 (пока не знаю, полезна ли сортировка) и ищу индекс заданной контрольной суммы. Найдя индекс, ищу по нему путь. Это занимает от 30 до 60 милисекунд при самой тупой реализации одной командой(Array.IndexOf()). Наверное, можно и ускорить, но пока не знаю, нужно ли. А путь может вести куда угодно – хоть и на другой компьютер по сети. Лишь бы хватало 260 байт. Вся эта фигня сидит на диске заранее подготовленная, и просто считывается в переменную при запуске программы.
Quote ммм... я не уверен, конечно, но если при попытке обращения к книге не считывается весь каталог - практически мгновенно... Но при этом - малейшее изменение структуры хранения контента - и программа работать не будет. Ведь моя программа, в принципе, так и делает - лепит к файлу путь, но потом ищет файл, а не сразу его открывает (на что и идет 99% времени). Если-бы путь к хранилищу был один - твой вариант был бы оптимален, но, к сожалению, в общем случае он не катит. Хотя... Знаешь, я попробую открывать файл без поиска... В конце концов, можно это сунуть в try - except и отслеживать по наличию ошибки... Может и сработает... Тут только экспериментировать надо Может действительно ускорится..
Конечно, у меня вполне может возникнуть ситуация, когда я одну из опрашиваемых библиотек куда то сдвину. Так что заранее приготовленный файл (или пакет линков) накроется медным тазом. Тут два варианта. Накрылся и я начал получать сообщения – файла нет. Тогда просто редактором (изменить кусочек пути для новой ситуации) или тем же способом, которым готовил изначально, обновлю файл. Но это ведь огромные массивы, 100-400 гигабайт и больше. Я не склонен таскать их каждый день с места на место.
А что означает – лепит путь? Я что то не заметил, что программа просматривает реальные места хранения книг. А в базе пути просто быть не может. Чтобы лепить путь его же надо иметь!
Пока что я не могу найти приемлемого решения для отключения поиска. Если я в настройках указываю, что книг нет, (пустое окошко с указанием путей к книгам) программа запрашивает грузить – не грузить, но куда девает после этого книгу, я не нашел. Нашел бы – отследил бы файл (объектом watchDirectory) и прочитал там данные книги, после чего бы нашел ее за несколько миллисекунд. Не нашел файлы, временные метки которых бы менялись после такого запроса. Если же указываю, что книги есть – она их ищет долго и упорно. Вот как ее заставить, родимую, при запросе «открыть книгу» просто передавать MD5 книги внешнему агенту? Или, хотя бы, подскажите, куда она пишет данные книги, которую надо грузить. Больше всего подходит libdownload, но он почему то не меняется, по крайней мере, сразу после ответа да, надо грузить. Вообще в этом массиве ничего не меняется. И ни один служебный файл не меняется. Чертовщина какая то. Похоже на то, что вы все это коварно держите в переменных и сбрасываете в файл только при закрытии программы.Добавлено (09.07.2012, 19:05)
---------------------------------------------
Примечание.
Я составил каталог с линками на пакет математических журналов. Примерно 250000 линков в одном каталоге. Так вот, после щелчка Тотал Коммандером по этому каталогу (чтобы войти внутрь) он засыпает примерно на полчаса час. Хоть отключай. Я это к тому, что в норме программы не расчитаны на работу с такими массивами. Здесь не любой подход годится. А в генезисе 800000 книг и 800000 обложек.
|
| |
| |
|
Главная 
