- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Собственно, проблема в следующем.
Давно хотел сделать поиск(файловый/ftp/etc). Возникла проблема: как хранить индекс.
Объемы данных, примерно:
Сотни серверов, миллионы файлов и папок.
СУБД. Хочется open source, т.к. предполагается, что работать это все будет на unix-системах и с весьма скромным бюджетом.
Но, как вариант, рассматривается и SQL Server.
Поиск хочу сделать не полнотекстным(т.е. средства предоставляемые той или иной СУБД мне не подходят).
Вопрос в следующем. Какой будет оптимальный алгоритм хранения древовидной структуры в СУБД.
Понятно, что «рекурсивный» parentid id мы не рассматриваем.
Nested Sets наверное тоже не подходит, т.к. здесь не только частая выборка, но и весьма частая вставка, и каждый раз перестраивать все дерево — ресурсов не напасешься.
Вообще возможно на таких данных делать неполнотекстный поиск по СУБД или стоит задуматься о хранении индекса отдельно(скажем в файлах).
p.s. машинка у меня не очень мощная. Athlon 1700 xp, 2x256 RAM, SATA-винт 200 ГБ.
Пардон, но "Сотни серверов" не сочетаются с "весьма скромным бюджетом".
Sherman, я бы на вашем месте думал в сторону файлов и ReiserFS. Mysql вообще не вариант, т. к. MyISAM скопытится на выборках, а InnoDB на вставках. :)
Однако-ж сам видел работающую систему на MySQL. Проиндексированно ~500 серверов, ~6 000 000 файлов. Количество запросов ~0.1 в секунду. Машина класса PIII, 512mb памяти под управлением Debian Linux. Так что MySQL вполне вариант.
FireBird ?
Однако-ж сам видел работающую систему на MySQL. Проиндексированно ~500 серверов, ~6 000 000 файлов. Количество запросов ~0.1 в секунду. Машина класса PIII, 512mb памяти под управлением Debian Linux. Так что MySQL вполне вариант.
И все же. Давайте обсудим, какова будет более менее оптимальная сруктура индекса в СУБД с сохранением информации о дереве.
Вот, например: http://wildhoney.netbynet.ru — используется вроде PostgreSQL.
А зачем хранить дерево?
Если предполагается искать только по именам файлов (или по полному пути) то можно представить файл как документ состоящий из слов которые содержатся в имени файла. И строить индекс по этим словам.
Не могу не пожаловаться: у меня, после недели непрерывной работы таки почти скопытилась :) Журнал она, вишь ли, ведет... зафлудила inod...
А может, Oracle попробовать?
Sherman, Вы бы определились чего вы хотите от базы. Если нужно просто искать файлы, то зачем вам дерево? Я, например, сделал выделил на каждый сервер по одной таблице и разом избавился от всякого геморойя со вставкой. При переиндексации убиваем старую таблицу и создаем новую. Работает в разы быстрее. От полнотекстового поиска ИМХО вы отказываетесь зря. Как показывает практика, он достаточно шустро работает, и выдает достаточно качественный результат.
tester999,
AFAIK, interbase и иже с ним на таких данных молча курят в сторонке.
Дерево нужно обязательно, т.к. структура будет использоваться весьма активно, группировки, сортировки и т.д. и т.п.