Кому не интересны изобретения велосипедов, дальше просьба не читать и не плевать в спину.
Кому есть что сказать по существу вопроса — всегда рад.
Сейчас я собираюсь рассмотреть основные вопросы, которые мне необходимы для масштабирования системы.
Для успешного масштабирования систему, включая данные, необходимо разбить на элементарные «кирпичи». Так, чтобы этот процесс был максимально прост. Чем проще, тем меньше путаницы в будущем. Удачное разбиение может оказаться плюсом и в решении других проблем. Такое уже бывало в моей практике, когда детально проработанная структура данных позволяла решать новые задачи, о которых в самом начале проекта и не думали. Но если честно, в основе этой тщательно проработки лежала элементарная лень, поэтому делалось так, чтобы легко можно было заменить один кирпич на другой незаметно для всей конструкции.
Лирика кончилась.
На мой взгляд, основной информационной единицей при поиске должен быть сайт. Судя по всему, у крупных поисковиков так и устроено, а если нет, мне их жалко. Просто страшно представить, что при поиске в разделе Яндекс-каталога происходит не поиск по группе сайтов, а фильтрация результата глобального поиска. Или когда если Гугл настраивает фильтрацию выдачи для Китая не отключением (не)нужных сайтов, а прореживанием выдачи. Впрочем не удивлюсь, если он просто строит отдельный «китайский» индекс.
Итак. Что нам дает хранение индекса и возможность к нему обращаться посайтово?
1. Возможность предоставления сервиса поиска отдельным сайтам. У крупных поисковиков есть ограничение поиска отдельным сайтом, но почему-то сами сайты этим не пользуются, предпочитая ставить локальные поисковики. По крайней мере данный рынок (локальных поисковиков) существует и этим можно пользоваться к взаимной выгоде — площадки для тестирования и обкатки функционала.
2. Возможность поиска по группе сайтов, наподобие Яндекс-каталога. Эта идея не нова, но вряд ли станет когда-либо неактуальной.
3. Возможность исключения из поиска нежелательных сайтов. Например «семейный поиск», которым могут пользоваться дети. Вряд ли кто из родителей захочет, чтобы, пусть даже случайно, они увидели в выдаче порносайты.
Т.е. посайтовая организация индекса предоставляет широкие возможности для инклюзивной и эксклюзивной фильтрации (включения-исключения отдельных сайтов или целых групп).
4. Эта мысль пожалуй самая крамольная — не нужен бэкап! Вместо бэкапа вы запускаета построение индекса с нуля. Это займет больше времени, чем восстановление их бэкапа, зато сокращает ваши аппаратные затраты. Ведь не надо держать фактически вторую копию индекса. Пока вы работаете с отдельным сайтом, это не сильно напрягает. Но с ростом объемов проблема хранения и поддержки бэкапа будет расти аналогичными темпами.
Я не собираюсь польностью отказываться от резервного копирования. Но делать это только для критически важных участков — ключевые справочники и индексы. Во-первых, объем этих данных намного меньше, во-вторых, их потеря — реальная катастрофа.
5. Мобильность. Перенос части индекса на другой сервер выполняется быстро и безболезненно, что сильно облегчает процесс обновления машинного парка. Это если собираемся развивать проект достаточно долго.
Сколько таких кирпичиков-индексов расположить на отдельном сервере — решается в зависимости от наличия ресурсов и это следующая тема.
PS. Я пока не рассматриваю вопрос, что делать, если индекс сайта слишком велик для одного сервера.
Во-первых таких сайтов не так много и об этом можно будет думать по мере приближения к ним.
Во-вторых, эту проблему можно решать параллельно, не вмешиваясь в работу основной системы и не расстраивая ее переделками.
UPDT:
Вариант, когда сайт хочет организовать у себя не только сквозной поиск, но и возможность ограничиться одним или несколькими разделами нормально ложится в предложенную структуру. Схема сайт-группа_сайтов-группа_групп-...-все подменяется схемой группа-группа_групп-....-сайт.
И то и то носит общее имя — иерархическая структура. Главное — какие ей присущи базовые ограничения? Количество уровней вложенности, сколько может быть дочерних узлов у отдельного раздела? Отсутствие ограничений даст гибкость, но скажется на скорости работы. Жесткие рамки позволят оперировать списками фиксированной длины, что ускорит работу. Главная задача — предложить такие ограничения, чтобы они устраивали в большинстве случаев. За развитие идеи спасибо Infanty
Кому есть что сказать по существу вопроса — всегда рад.
Сейчас я собираюсь рассмотреть основные вопросы, которые мне необходимы для масштабирования системы.
Для успешного масштабирования систему, включая данные, необходимо разбить на элементарные «кирпичи». Так, чтобы этот процесс был максимально прост. Чем проще, тем меньше путаницы в будущем. Удачное разбиение может оказаться плюсом и в решении других проблем. Такое уже бывало в моей практике, когда детально проработанная структура данных позволяла решать новые задачи, о которых в самом начале проекта и не думали. Но если честно, в основе этой тщательно проработки лежала элементарная лень, поэтому делалось так, чтобы легко можно было заменить один кирпич на другой незаметно для всей конструкции.
Лирика кончилась.
На мой взгляд, основной информационной единицей при поиске должен быть сайт. Судя по всему, у крупных поисковиков так и устроено, а если нет, мне их жалко. Просто страшно представить, что при поиске в разделе Яндекс-каталога происходит не поиск по группе сайтов, а фильтрация результата глобального поиска. Или когда если Гугл настраивает фильтрацию выдачи для Китая не отключением (не)нужных сайтов, а прореживанием выдачи. Впрочем не удивлюсь, если он просто строит отдельный «китайский» индекс.
Итак. Что нам дает хранение индекса и возможность к нему обращаться посайтово?
1. Возможность предоставления сервиса поиска отдельным сайтам. У крупных поисковиков есть ограничение поиска отдельным сайтом, но почему-то сами сайты этим не пользуются, предпочитая ставить локальные поисковики. По крайней мере данный рынок (локальных поисковиков) существует и этим можно пользоваться к взаимной выгоде — площадки для тестирования и обкатки функционала.
2. Возможность поиска по группе сайтов, наподобие Яндекс-каталога. Эта идея не нова, но вряд ли станет когда-либо неактуальной.
3. Возможность исключения из поиска нежелательных сайтов. Например «семейный поиск», которым могут пользоваться дети. Вряд ли кто из родителей захочет, чтобы, пусть даже случайно, они увидели в выдаче порносайты.
Т.е. посайтовая организация индекса предоставляет широкие возможности для инклюзивной и эксклюзивной фильтрации (включения-исключения отдельных сайтов или целых групп).
4. Эта мысль пожалуй самая крамольная — не нужен бэкап! Вместо бэкапа вы запускаета построение индекса с нуля. Это займет больше времени, чем восстановление их бэкапа, зато сокращает ваши аппаратные затраты. Ведь не надо держать фактически вторую копию индекса. Пока вы работаете с отдельным сайтом, это не сильно напрягает. Но с ростом объемов проблема хранения и поддержки бэкапа будет расти аналогичными темпами.
Я не собираюсь польностью отказываться от резервного копирования. Но делать это только для критически важных участков — ключевые справочники и индексы. Во-первых, объем этих данных намного меньше, во-вторых, их потеря — реальная катастрофа.
5. Мобильность. Перенос части индекса на другой сервер выполняется быстро и безболезненно, что сильно облегчает процесс обновления машинного парка. Это если собираемся развивать проект достаточно долго.
Сколько таких кирпичиков-индексов расположить на отдельном сервере — решается в зависимости от наличия ресурсов и это следующая тема.
PS. Я пока не рассматриваю вопрос, что делать, если индекс сайта слишком велик для одного сервера.
Во-первых таких сайтов не так много и об этом можно будет думать по мере приближения к ним.
Во-вторых, эту проблему можно решать параллельно, не вмешиваясь в работу основной системы и не расстраивая ее переделками.
UPDT:
Вариант, когда сайт хочет организовать у себя не только сквозной поиск, но и возможность ограничиться одним или несколькими разделами нормально ложится в предложенную структуру. Схема сайт-группа_сайтов-группа_групп-...-все подменяется схемой группа-группа_групп-....-сайт.
И то и то носит общее имя — иерархическая структура. Главное — какие ей присущи базовые ограничения? Количество уровней вложенности, сколько может быть дочерних узлов у отдельного раздела? Отсутствие ограничений даст гибкость, но скажется на скорости работы. Жесткие рамки позволят оперировать списками фиксированной длины, что ускорит работу. Главная задача — предложить такие ограничения, чтобы они устраивали в большинстве случаев. За развитие идеи спасибо Infanty
