- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени...
Возникает вопрос, если кто сталкивался - помогите вынести решение: поисковой системе для быстроты хватает обычной СУБД (Oracle, MySQL, Postgress, etc....), или все-таки, не учитывая криворукость разработчика, лучше писать свой механизм хранения индекса?
Насколько мне известно, большая часть БД хранит таблицы в виде B-деревьев (не путать с бинарными). Если я ошибаюсь, поправьте.
Распространенное мнение гласит, что быстрее чем по б-дереву ни по какой структуре ходить невозможно :rolleyes:
Многие утверждают, что скорость выборок(в общем, не только выборок, но и остальных операций над данными) ни одной из существующих БД не подходит даже для слабенького поисковика, сколько бы там ни было машин и ресурсов, и как бы индекс ни был организован...
В пользу такого мнения приводится множество задач, под которые "заточены" современные СУБД, чтобы стать универсальными. Для индексации и поиска эти задачи - что пятое колесо телеге (не считая проблем защиты данных)
С другой стороны, все серьезные СУБД были придуманы не сразу и не вдруг, над ними долго корпели... стоит ли изобретать велосипед дважды?
Тут вопрос надо ставить по другому: а есть ли альтернатива ораклу ? :)
Miha Kuzmin,
Пожалуй, перефразировать вопрос не буду.
Оракл, конечно, штука неплохая, но разве она стоит на первом месте по скорости? Пока мускул не стал слишком навороченным (обязательно ему надо было все фичи дорабатывать), на первом месте по многопоточным серверам стоял, насколько я знаю, он.
Вот видите, мы и вернулись в эту самую проблему - не усложняют ли эти самые навороты жизнь поисковых систем...
Мускул при выполнении сложных запросов и работе с большими обьемами данных тихо курит в сторонке.
Miha Kuzmin,
Гм... тогда, если не сложно - цифры привести можете? (нет, не подумайте, что я недоверяю...)
Давайте подойдем так...
1) Что такое большие объемы данных? Должна повториться, что разнесением поискового индекса можно сильно уменьшить величину отдельно взятой из БД таблицы, и потому - о скольких нулях идет речь? :)
2) Мы с вами не обсуждаем преимущества оракла, верно? Нет, драться не будем: я поклонница обеих СУБД.
Вопрос нужно поставить в другом плане: нужно ли писать свою СУБД, заточенную под быстрый поиск по определенному алгоритму, или в этом нет ни капли смысла (потому что подойдет и любая универсальная СУБД)?
тут по другому вопрос ставить надо...
какой индекс Вы примерно хотите держать в БД и какими мощностями распологаете?
какой индекс Вы примерно хотите держать в БД и какими мощностями распологаете?
Balabass,
Давайте поставим задачу так: заданная мощность неограничена, как, впрочем и поисковый индекс - не на локализованном сервере корпорации, а в пределах, скажем, одной глобальной темы или региона... - можете представить сами. :)
Пара слов насчет мощности: речь, разумеется идет не об одном сервере, а о нескольких, объединенных какой-нибудь умной киской, умеющей распределять нагрузку.
После столь долгих объяснений хотелось бы получить ответ (ну, или хотя бы вопрос) поконкретнее :)
1. На разных размерах (зависит от таблиц). В среднем, от нескольких гигабайт.
2. Ни капли (любая все таки вряд ли подойдет).
Miha Kuzmin,
С несколькими гигабайтами неплохо справляется и мускул... хотя, в сложных запросах скорость не сравнивала.
Будут еще мнения?
Думаю мускл с таблицей в 2Г помрёт
Dzmitry,
Не помрет, но будет долго ломаться. :) Пробовала. Результат неутешителен. :(
Сейчас буду на эту тему мучать оракл.