- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть полгига данных, которые растут и в обозримом времени перерастут память. Данные содержат информацию для построения списка найденных товаров. Грубо говоря, если в поисковике запрашивается "хлеб", то ищутся все точки, где он продаётся, плюс номера фраз с наименованиями товаров. По номерам наименований товаров извлекаются все наименования товаров, в которых упоминается это слово "хлеб". Но не более 10 на точку. Обратный индекс, список товара и индекс для быстрого доступа к названиям товаров сейчас храню в памяти. Но чувствую, что память под список товара через какое-то время кончится. Время ответа нужно сохранить около 0.1 секунды (написано на С, пока данные в памяти, всё летает очень шустро).
Хранить фразы в базе MySQL смысла не вижу. Извлекать из неё на некоторые запросы одну-две тысячи записей по 20-30 символов - не сказка. Memcached здесь поможет, но не сильно.
Хранить в BerkeleyDB? В принципе, возможно. Но боюсь, что иногда будет по 100-200 позиционирований головки для чтения данных. То есть по секунде-две сервер будет только читать с диска.
Пытался сжимать gzip. Даёт выигрыш по памяти в 2 раза, при этом некоторые блоки получаются по 8 Мб. Да, в некоторых магазинах очень много товара. На расжатие таких блоков требуется время, а иногда таких блоков по 20-30 за раз.
Пока думаю продолжать хранить данные в памяти в обычном виде и при росте объёма данных за разумные пределы разнести части базы по разным серверам. Разумно ли это?
Да, ещё приходится раз в три часа делать реиндексацию. Всё хорошо в случае своей базы - просто перезапускается время от времени скрипт и меняются старые файлы на новые. Но что делать для целостности в случае хранения данных в MySQL/Berkley? Ставить в записях номер реиндексации и пересохранять десятки миллионов записей? А затем, спустя время, удалять другие десятки миллионов?
Ой. Все серьезно.
Скажем так, уходить от самописного варианта надо. Почему? Не думаю, что вы реализовали его лучше (не говорю, что хуже!) чем разработчики серьезных БД.
Серьезно MySQL не занимался, но на MS SQL вполне шустро бегают базы более 1 Гига и запросы на 20-30 тысяч записей выполняются менее чем за 1 сек. Ясное дело, правильные инексы рулят.
К чему я это все...
ИМХО стоит таки переходит на нормальные СУБД. Продвинутые сами умеют всю выделенную для них память забивать самыми "нужными" данными, нет проблем с индексацией и т.д. Еще и индекс разделять умеют.
Проблема еще как я понял в том, что идет полнотекстовый поиск, а не простой WHERE type = 3?
Ой. Все серьезно.
Скажем так, уходить от самописного варианта надо. Почему? Не думаю, что вы реализовали его лучше (не говорю, что хуже!) чем разработчики серьезных БД.
Не лучше - иначе.
Проблема еще как я понял в том, что идет полнотекстовый поиск, а не простой WHERE type = 3?
Проблема в полнотекстовом поиске с морфологией + значительных ограничениях на время поиска + на 2 млн. документах и более MySQL начинает безбожно тормозить.
на 2 млн. документах и более MySQL начинает безбожно тормозить.
?
2 млн документов - ну пусть по 1024 байта - это всего 2 гигабайта
А у Вас какие документы?..
HungryFoerster, от 0 байт до 32 Мб.
У меня сайт с 1.6 млн мелких заметок (до 1 к). Мускуль. Всё летает (правда, повозился над оптимизацией производительности, механизмами кеширования и т п).
У меня сайт с 1.6 млн мелких заметок (до 1 к). Мускуль. Всё летает (правда, повозился над оптимизацией производительности, механизмами кеширования и т п).
1. У него, наверное, не обновляется 1/3 всех данных раз в сутки.
2. На нём, наверное, не нужно по 10-20 раз в секунду делать полнотекстовый поиск, при котором находится 100-200-1000 записей.
3. Он, наверное, не должен держать "всплески посещаемости" по 100-200 запросов в секунду.
4. У него, наверное, нет "длинного хвоста": 30% всех запросов за месяц уникальные (а значит данные лежат на диске).
5. У него, наверное, нет морфологии.
6. На сайте, наверное, не ведётся статистика обращения к каждой записи. А это 20-200-1000 записей на запрос.
Господа, давайте не будем обсуждать мой полнотекстовый поиск и почему в нём не используется MySQL. Да, использование MySQL было бы счастьем: более быстрая разработка, более простая доработка, более дешёвые и заменяемые программисты. Но использование MySQL здесь крайне затруднено. Почему - см. поиск по этому подфоруму.
Вы, как крутые MySQL-щики, лучше скажите, как оптимально реализовать вытаскивание данных, описанное в первом сообщении. И насколько быстро будет это происходить, если данные, как правило, лежат на диске из-за редкости запросов? Как оптимально и с сохраненим во время обновления данных работоспособности сайта реализовать обновление данных, если за сутки обновляется 1/3 записей из 30-50-100 млн. (сейчас 30, планируется больше)?
И что, по 10-20 раз в секунду абсолютно уникальные запросы?
И что, по 10-20 раз в секунду абсолютно уникальные запросы?
Михаил, не поверите. Лишь 1/4 повторяется хоть раз в сутки. Соответственно, кеширование не даёт никакого существенного прироста 🙅 И данные Андрея Иванова из Ашманов и Ко по статистике поиска на Рамблере (26% запросов приходится на 547 147 различных формулировок, данные 2003 года) не дают никакого повода для оптимизма 🙅
Распиши тогда подробней, чем в первом посте. Всегда мона обойти.
а там нельзя вместо полнотекстового поиска делать поиск по тегам (точное соответствие)?