Использование стандартной базы данных

Здравствуйте! Прошу меня простить, если уже обсуждалось. Мне хотелось бы предложить хранить данные с серверов в одной из стандартных баз данных. ИМХО это уменьшит объем и увеличит скорость работы. У меня в базе 800 серверов с объемами до 2-х террабайт. При таком раскладе поиск становится достаточно длительным процессом. Да и каталог программы весит под 500 мегабайт.

Да, уже обсуждалось, и прямо и косвенно. Вы можете посмотреть цепочку здесь и здесь. В первой ветке, правда, тема была другая, однако, принцип то же.
Насчет уменьшения объема и увеличения скорости работы... Думаю, Вы все поймете из указанных выше веток.

Для сокращения времени поиска и уменьшения размера файлов данных попробуйте воспользоваться опциями "Удалять файлы в недоступных каталогах" и "Не запоминать удаленные данные", а также установкой игнорирования на определенные папки сервера, если Вы еще не пользуетесь этими настройками.
Для ускорения опроса можно воспользоваться опцией "Игнорировать каталоги по маскам", настройкой корневого каталога сервера и настройками игнорирования и игнорирования с сохранением для определенных папок сервера. Дополнительно можно попробовать разбить долгоопрашиваемый сервер на несколько серверов. Иногда помогает и, как правило, на широком канале. Как это сделать смотрите здесь в пункте 8.

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

P. S. В версии 1.9.1 beta 4 поиск идет быстрее.

Спасибо, Oleg. Указанные ветки просмотрел. Но, честно говоря, все еще не совсем согласен с отказом от применения эмбедед базы (например того же Фаербёда). Ну да ладно, автору виднее.

По поводу различных ухищрений для оптимизации. Спасибо, сделал. Но хочу отметить, что многие из приемов хороши при использовании десятка серверов. Для большего количества подходят мало. Так как настраивать все это для каждого сервера, да еще и следить, чтобы не изменилась структура каталогов на каждом... Это не слишком удобно, мягко говоря.

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

Совершенно с Вами согласен! У одного из форумчан подобная настройка заняла порядка 4 - 5 часов (1500 серверов), у меня меньше (слава Богу) - около часа (более 400 серверов).

В качестве утешения могу добавить, что такие настройки делаются раз в достаточно долгое время. Почему? Предполагается, что когда мы устанавливаем игнорирование папки без сохранения, то нас не интересует ее содержимое и его изменение. А если нам нужно содержимое папки, но изменения в ней происходят достаточно редко, то мы можем установить на эту папку игнорирование с сохранением. Подобный подход вовсе не претендует на единственно верный, однако, для себя я нашел его удовлетворительным. В дополнение к данному способу, я иногда ставлю игнорирование с сохранением на целые каталоги с музыкой, драйверами и даже с софтом, если в данный момент меня интересуют, например, фильмы. Это еще один подход. Конечно, если нужна 100% информация по всем серверам, то тут уж ничего не поделаешь...

А для проверки содержимого заигнорированных с сохранением папок была предложена специальная функция (см. здесь) и MAS заинтересовался ей. Также уже отслеживается наличие самого заигнорированного с сохранением каталога в версии 1.9.1 beta 4.

Конечно, все равно потребуется потратить время на настройку и ускорение происходит только при опросе, при поиске ни чего не меняется, но похоже, что других способов нет в принципе, кроме как менять формат хранения данных. Но здесь надо хорошенько подумать, прежде чем отваживаться на такой шаг, потому как прирост производительности дает не столько наличие БД, сколько продуманная организация структуры БД, а в нашем случае выбирать особо не из чего: файлы да папки . Да еще необходимость в дополнительном софте...

А толку то от фаербёрда? Сам элемент "запись" короткий, что там - только имя, дата, флаги, ну и привязка к каталогу (для файлов). А вот количество этих элементов...
И всё равно придеться делать "один сервер - одна БД" , так что выигрыша по количеству файлов не будет.
По поводу размера файлов баз.... имхо тоже не будет, а то и наоборот!

Хм, а как ещё можно настаивать?
Если тебя интересуют изменения на всём сервере - тогда придётсья сканить его целиком. Да, это может быть долго. Хотя при скане основная задержка - это связь с серверов, а не "пережевывание" ответа
Не желаешь видеть какие-то каталоги на серверах? Тут только вариант с ручным игнорированием веток.

Воспользуйся автоигнорированием каталогов. Если тебя не интересуют каталоги "*games*", то в настройках масок каталогов пропиши эти маску и включи у нужных серверов игнорирование не нужных каталогов.

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

А какая ещё может быть структура? Только "таблица" каталогов и "таблица" файлов (со связями к файлу).
Всякие деревья каталогов - они не нужны, ибо поиск почти всегда идёт по всму серверу.
А в поиске основной тормоз это не сам поиск в БД (в файле...), а выделение памяти под найденный элемент.

Именно это я и имел в виду!

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

Не знаю, не знаю... Буквально сейчас наблюдал такую картину. Делаю запрос для поиска. Тормоза на минуту. Причем полные, с отсутствием перерисовки. Далее поиск. Ну худо-бедно, процесс идет. Поиск завершился, снова тормоза на минуту. И получаю найденную ссылку. Одну! Это под нее память выделялась во время тормозов? Интересно...

Кстати по поводу памяти. Есть у меня подозрения, что по памяти либо утечка жуткая, либо придуман способ максимально неэффективно ее использовать. Потому что после вышеописанной картины винды жалобно сообщили, что виртуальная память кончилась. Поиск при этом был уже завершен, на экране отображалась одна найденная ссылка.

Да вроде никак. Всего лишь хотел сказать, что предложенные варианты не панацея.

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

Скажу только, что Вы почему-то отделяете саму БД от системы управления ей (СУБД) и что Вы не учитываете тот факт, что "серьезный" сервер базы данных весит от, порядка, 200 мегов до более, чем гига (полагаю, Oracle - серьезный сервер БД). Или что Вы называете серьезной БД?. Так же Вы не учитываете то, что сервера БД рассчитаны на многопользовательский режим доступа и работают с объемами гораздо большими, чем 500 мег. Скажу даже, что для БД в 500 мег - это не только не большой объем, а даже маленький. Объемы в несколько гигов считаются небольшими. А большими считаются объемы в десятки и сотни гигов и более. К тому же основной упор делается (и правильно) на ускорение выборок из нескольких связанных таблиц с учетом многопоточности, а способы выборок из одной таблицы, как правило, давно известны.
И еще Вы не учитываете, что этот сервер БД должен где-то работать, потреблять процессорное время, память и т. д.
Конечно, если у Вас под столом стоит еще и брендовый сервер с парой-четверкой процессоров, немереной оперативкой и жесткими дисками, готовыми взлететь от собственной скорости вращения и лопающимися от гордости за свое время чтения\записи, тогда конечно можно себе позволить и серьезный сервер БД.

Теперь по поводу алгоритма поиска. При поиске только файла без символов подстановки в FI используется (насколько я знаю) поиск по целочисленному ключу по бинарному дереву, который является одним из самых быстрых. Добавлю, что индексы в "серьезных" БД строятся зачастую именно в виде бинарного дерева. Но если Вы ищите с подстановочными символами, то никакие индексы и оптимизация хранения Вам не поможет: необходимо пробежать по всем строкам таблицы с файлами и\или каталогами и сравнить их с искомой строкой с учетом возможных подстановок.

Наверное, человек, занимавшийся более 7 лет поддержкой, разработкой, оптимизацией программ ERP класса и их БД на MS SQL Server и некоторых других, может считаться более-менее специалистом по базам данных. Так вот после 7 лет работы в этой области могу сказать, что Ваше утверждение по поводу "не зря хлеб едят" и про "десяток лет" несколько оптимистично. В том числе и потому, что есть определенные границы производительности БД, которые нельзя перейти, как не крутись.

Вы можете провести эксперимент. Распечатайте список файлов из FI для Вашего самого большого сервера. Залейте его в какую-нибудь БД (например, Access) и засеките время для поиска по этому серверу как без маски, так и по маске в FI и БД. Если увидите значительное ускорение с учетом запуска СУБД, с учетом того, что в нынешнем файле данных FI могут храниться удаленные файл\каталоги и еще некоторая инфа, с учетом того, что в выданном результате (при использовании СУБД) Вы должны видеть каталог, где находится искомый файл (причем живой файл, а не удаленный), а в случае поиска по каталогам Вы должны получить найденный каталог вида: "ааа\ббвгг\" (ищем по строке "бб*гг"), а не "ааа\бб\гг". А если Вы еще прибавите сюда необходимость где-то доставать саму СУБД, устанавливать ее вместе с FI и то, что размер самого файла БД скорее всего будет больше суммарного размера фалов данный FI, вошедших в БД, то, полагаю, выигрыш в производительности должен быть весьма и весьма весомый, чтобы решиться на переход.

У меня размер каталога с данными - чуть более 100 мег. Поиск всего по всем серверам (строка поиска: "*") занимает время - менее 2 минут. Поиск файла с символами подстановки занимает 15 - 17 секунд. В последнем случае память почти что не расходуется. Так что в Вашем случае просто что-то не так работает, короче глюк где-то.

А вот тут поподробнее - какие-же такие хитрые и засекреченные алгоритмы используются в "серьёзных БД"? Что о них никто ничего не знает...

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

После поиска FI только и делает, что по запросу винды отрисовывает строчки таблицы.
А! Ну ещё, "сбрасывает" файл базы сервера, освобождая место. Если памяти мало и она вся в свопе, то тут возможны подвисания. Но опять же - а при чем тут FI?

Хм, значит разработчики "серьёзных БД" все делают правильно, а разработчики STLPort допускают утечки памяти и плохо продумали распределение памяти?
А утечек памяти нет, слишком хорошо знаю что это такое. Да и средства мониторинга не дремлют.

Учитывая тормоза при загрузке базы сервера перед началом поиска - памяти изначально не хватало.

Да вроде никак. Всего лишь хотел сказать, что предложенные варианты не панацея.

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

Ajax асболютно прав. Незачем изобретать велосипед.

Индекс можно использовать если символ-шаблон стоит не в самом начале искомой строки. Это тоже здорово экономит время. А для остальных случаев есть алгоритм Турбо Бойера-Мура. Сомневаюсь что сей алгоритм реализован в FI.

Что можно определить, сделав "поиск по *"? Имхо, только время загрузки данных с диска в таблицу и вывода их юзеру. Ведь никакие поисковые алгоритмы в этом случае не используются.

У меня, например, поиск по маске *слово* занимает в среднем 1.5-2 секунды, если не сортировать результаты. Поиск по с*лово, сл*во, и т.д. - гораздо меньше 1 секунды. База 360 МБ, mysql, 30 МБ в оперативе, 1.6 млн. записей. Система - K7 sempron 2600+.

2MAS&Oleg
Товарищи, если вы не хотите чтобы к 1.5-меговой программой поставлялась 25-мегабайтовая БД - дело ваше, и в чём-то вы здесь правы. Но писать о том, что ваши B-деревья без индексов работают быстрее других B-деревьев, пусть даже в которых есть и индексы, и другие спсобы оптимизации, имхо глупо.

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

B-деревья в реляционных базах данных - это как раз и есть индексы. Это я к вопросу о глупости.

Не придирайтесь к словам.
Вас не удивляет разница в цифрах на порядок? БД mysql делает поиск по *слово* со скоростью 1.2 млн. записей/сек. Естественно, считывая таблицу с диска. И как ни странно, CPU Usage < 70% при этом.

Большая просьба предоставить более подробную информацию про "15-17 секунд" - число записей, конфигурация системы и т.п. Вот потом будем сравнивать, ибо есть что с чем сравнить.

Можно бесконечно спорить, что лучше - БД своими руками, или БД над которой потрудились тысячи людей (не дураков кстати). Но вот есть уникальная возможность - ничего переписывать не надо, достаточно сравнить прозводительной БД mysql на примере моего поискового сервиса, и вашей БД, тогда всё станет на свои места.

И да родится истина в споре

Судя по этой реплике, Вы ничего не поняли из того, что я сказал. Ну и ладно.

Поиск по "*lingvo*11*" 10 секунд (стабильно) (про 15-17 сек. данных не осталось), 437 серверов в базе, общий размер файлов данных серверов - 117 мег, количество живых файлов в базе - 2,35 млн., при поиске сортировка включена. Машина: ноутбук, Р4 2,8 ГГц, оперативка 1 Гиг, HDD - 5400 об/мин, дисковый кэш - 8 мег. Система Windows XP Home, SP2. Объем памяти процесса при поиске не более 27 мег, загрузка процессора - 100%.


P. S. Вы считате, что стоит для уменьшения времени поиска с 10 секунд до 2-х вынуждать пользователя (не админа!) ставить себе еще MySQL?

Это сообщение отредактировал Oleg - 13.05.2006 - 14:45

Судя по этой реплике, Вы ничего не поняли из того, что я сказал. Ну и ладно.

Поиск по "*lingvo*11*" 10 секунд (стабильно) (про 15-17 сек. данных не осталось), 437 серверов в базе, общий размер файлов данных серверов - 117 мег, количество живых файлов в базе - 2,35 млн., при поиске сортировка включена. Машина: ноутбук, Р4 2,8 ГГц, оперативка 1 Гиг, HDD - 5400 об/мин, дисковый кэш - 8 мег. Система Windows XP Home, SP2. Объем памяти процесса при поиске не более 27 мег, загрузка процессора - 100%.


P. S. Вы считате, что стоит для уменьшения времени поиска с 10 секунд до 2-х вынуждать пользователя (не админа!) ставить себе еще MySQL?

Для управления аппаратным фаерволом в матплатах с чипсетом nForce 4 Ultra, SLI уже предлагается установить целый Apache .

А mysql можно в принципе "урезать" и интегрировать в дистрибутив программы... Кстати, mysql не есть панацея, я её просто привёл как одну из "больших" БД. Всё равно, разница в скорости поиска между 1.23 млн. записей/сек у меня на K7 sempron c реальной частотой 1833 МГц, и у вас - 0.235 млн./сек на Р4 2800 МГц - довольно существенна.

И ещё. Использование в программе именно mysql (возможно, в качестве опции) - идеальное средство для создания централизованной поисковой системы с веб-интерфейсом (см. соседнюю ветку). А там время поиска будет гораздо важнее, так как пользователей будет много, а не один.

Немного философии. ИМХО лучше использовать одну выделенную машину, которая будет с определённым интервалом сканировать фтп-сервера. Это выгодно всем: пользователи сэкономят мегабайты, винчестеры владельцев серверов не будут "напрягаться", отдавая листинг файлов по нескольку сот раз на дню.