Я так понимаю, вы про сайты на платформе.
По нашим данным на вашем IP адресе висит tor exit node, поэтому вы попали на капчу.
Так как наши недруги боты никак не успокаиваются и в последнее время любят tor, мы теперь показываем капчу на таких IP адресах.
Основная особенность: нет скриптовых языков при работе сервиса, всё работает быстро на модулях nginx.
Другая особенность: скачайте себе скрипты и конфиги и у вас есть такое же сервис.
Мы же выложили даже готовый образ системы «для ленивых», запустить его — 5 минут.
1) потому что ключ к АПИ в нашем случае это число типа 123456 (особенности наших внутренних решений)
2) у нас уже сейчас есть настройка «доступ к АПИ с определённых IP-адресов или подсетей»
3) через какое-то время доделаем https://
Единственная сила текдока — это его известность. Текдок известен в кругах сотрудников магазинов запчастей, как наиболее доступный (физически и по цене) каталог для подбора. Эти же менеджеры предполагают, что покупатели мыслят как и менеджеры и поэтому заказывают размещение текдока на интернет-магазинах. На самом деле пользователи на сайтах практически не используют текдок для выбора и покупки товара. Именно поэтому в реальных действующих интернет-магазинах вы не встретите только текдок. Его дополняют другими каталогами.
Текдок изначально разрабатывался как каталог для WINDOWS для подбора и ЗАКАЗА товара. Т.е. прямо в нём есть корзина и возможность отправки заказа поставщику. Поэтому последний этап визарда текдока исторически выглядит как результаты поиска. Всё это довольно странно, учитывая что в предложениях интернет-магазина есть и другие товары, к примеру оригинал. Но текдок продвигает только НЕоригинал (за что берёт с каждого бренда огромную сумму в квартал). tecdoc.abcp.ru/catalog?man=16&model=3397&modelVariant=8963&group=100260 — вот пример последней страницы визарда. Интернет-магазинам приходится его выводить. На самом же деле нужно вместо этого сделать переход в поиск от какого-нибудь из этих артикулов для выдачи всех предложений. Пример клика на первом предложении: tecdoc.abcp.ru/?pbrandnumber=PC2232E&pbrandname=Ac-delco
Таким образом, текдок не подходит тем, кто торгует в т.ч. оригиналом и вообще не подходит тем, кто торгует только оригиналом.
>> Я не имел ввиду, что mysql не очень. Если его использовать в таком плане, отличий от других noSQL критических не будет.
>> Все все равно будет утыкаться в скорость накопителей. Вопрос то в горизонтальном масштабировании, шардинге,
>> как организовали, какие конкретные проблемы возникали, как поиск организовали. вот это интересно.
Это тема отдельной большой статьи, но если кратко, то:
1. В нашем случае мы определили оптимальный объём одной базы в 10 млн.записей
2. На одном средненьком сервере вполне умещается 4 таких базы параллельно.
3. Поисковой запрос выполняется параллельно в нескольких базах, не во всех, а только в тех, где есть прайс-листы по которым запущен поиск в данный момент. Несколько прайсов может быть в одной базе.
4. Обновление прайс-листов также происходит параллельно. Планируется к разработке алгоритм распределяющий прайсы одного заказчика по разным базам.
5. Однако есть случаи, когда под определённого заказчика создаются выделенные базы, чтобы исключить конкуренцию за ресурсы.
6. Разработан механизм автоматического распределения данных между базами. Логический балансер. Система определяет самые незагруженные склады и при каждом обновлении решает в какую базу залить этот прайс.
7. Можно в любой момент добавлять сервера и склады, включать их в глобальный список и прайсы при обновлении перераспределятся, что приведёт к оптимальному количеству записей на базу (см.пункт 1).
8. Можно для каждой базы включить режим освобождения и база постепенно очистится до нуля. Используем для обновления ПО, для переноса данных между серверами и для других целей.
>> Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update
>> where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
>> Ниже уже написали про infile, insert on dublicate. Вообще трудно предложить хороший вариант, не зная деталей.
infile это хороший вариант, но не в нашем случае, я немного раскрыл смысл об этом камментом выше.
1. Да. Огромное количество инсертов может привести к проблемам с производительностью диска.
2. Фактически, заливаются операционные данные, к которым идут постоянные обращения. И тут надо, во-первых, обеспечить валидность данных в любой момент времени. Во-вторых, закладываться на пиковую нагрузку, чтобы в любой момент обеспечить допустимое время отклика.
Для обеспечения этих требований в наших условиях вариант с предварительным расчетом дифа между заливаемыми прайсами и апдейтом только изменившихся строк работает быстрее.
Ну, а там, где прайс изменяется кардинально или заливается в первый раз применяется как раз похожий insert.
Конечно поставщиков слишком много и возможно встречаются одинаковые прайсы (ну или почти одинаковые). Но нам легче заливать всё подряд, чем сравнивать файлы друг с другом.
Разумеется нет. Если поставщик даёт всем клиентам одинаковый прайс — мы таких поставщиков клиентам подключаем централизованно, ведь для всех одинаковые данные. И соответственно обновляем один раз сразу для всех клиентов.
Приношу извинения за то, что пост воспринимается Вами в таком духе. Никого в том числе нас не интересует молодцы мы или нет. Поверьте, мы уже давно переболели этой болезнью. Всех, в т.ч. нас интересует только результаты, которые можно оценить реальным рублём. И мы такую оценку получаем, с этим всё впорядке. Насчёт полезности — я лишь хотел донести то, что упомянул камментом выше — для достижения целей иногда годятся и простые технологии, что мы и проверили на себе.
> Как-то совсем непонятно. У вас прайсы которые никому не интересно читать но зачем-то интересно писать?
Это не у нас прайсы ) это у автолюбителей прайсы. Представьте себе обычный прайс-лист компании Mercedes содержит более 600 тысяч позиций. А mitsubishi — более миллиона. Но в ближайшие сутки из этого объёма покупатели будут искать примерно 5000 позиций и нельзя угадать какие позиции будут затребованы. А цены и наличие меняются каждый день. Нужно всё обновлять и желательно каждый день.
> Или вы там на полном серьезе делаете на каждый чих update where id =.?
Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
> На счет полезности информации — создать топик для откровений «мы смогли только innoDB как noSql заюзать» в 2015 году это сильно.
А это топик о том, что даже в 2015 году можно не стесняться и использовать простые способы для достижения результатов в бизнесе. Возможно люди на хабре ждут каких-то новых технологий, я же писал о реальных результатах.
По нашим данным на вашем IP адресе висит tor exit node, поэтому вы попали на капчу.
Так как наши недруги боты никак не успокаиваются и в последнее время любят tor, мы теперь показываем капчу на таких IP адресах.
будет возможность, кидайте сюда отзывы.
org-name: NOKIA Corporation
Почему-то в MaxMind GeoLite название организации посчиталось названием города.
Попробуйте сообщить в MaxMind об ошибке.
и добавили в него nginx из официального репозитория.
Ну и конечно, наши скрипты.
А sypexgeo.net — проект отличный.
Другая особенность: скачайте себе скрипты и конфиги и у вас есть такое же сервис.
Мы же выложили даже готовый образ системы «для ленивых», запустить его — 5 минут.
2) у нас уже сейчас есть настройка «доступ к АПИ с определённых IP-адресов или подсетей»
3) через какое-то время доделаем https://
Текдок изначально разрабатывался как каталог для WINDOWS для подбора и ЗАКАЗА товара. Т.е. прямо в нём есть корзина и возможность отправки заказа поставщику. Поэтому последний этап визарда текдока исторически выглядит как результаты поиска. Всё это довольно странно, учитывая что в предложениях интернет-магазина есть и другие товары, к примеру оригинал. Но текдок продвигает только НЕоригинал (за что берёт с каждого бренда огромную сумму в квартал). tecdoc.abcp.ru/catalog?man=16&model=3397&modelVariant=8963&group=100260 — вот пример последней страницы визарда. Интернет-магазинам приходится его выводить. На самом же деле нужно вместо этого сделать переход в поиск от какого-нибудь из этих артикулов для выдачи всех предложений. Пример клика на первом предложении: tecdoc.abcp.ru/?pbrandnumber=PC2232E&pbrandname=Ac-delco
Таким образом, текдок не подходит тем, кто торгует в т.ч. оригиналом и вообще не подходит тем, кто торгует только оригиналом.
>> Все все равно будет утыкаться в скорость накопителей. Вопрос то в горизонтальном масштабировании, шардинге,
>> как организовали, какие конкретные проблемы возникали, как поиск организовали. вот это интересно.
Это тема отдельной большой статьи, но если кратко, то:
1. В нашем случае мы определили оптимальный объём одной базы в 10 млн.записей
2. На одном средненьком сервере вполне умещается 4 таких базы параллельно.
3. Поисковой запрос выполняется параллельно в нескольких базах, не во всех, а только в тех, где есть прайс-листы по которым запущен поиск в данный момент. Несколько прайсов может быть в одной базе.
4. Обновление прайс-листов также происходит параллельно. Планируется к разработке алгоритм распределяющий прайсы одного заказчика по разным базам.
5. Однако есть случаи, когда под определённого заказчика создаются выделенные базы, чтобы исключить конкуренцию за ресурсы.
6. Разработан механизм автоматического распределения данных между базами. Логический балансер. Система определяет самые незагруженные склады и при каждом обновлении решает в какую базу залить этот прайс.
7. Можно в любой момент добавлять сервера и склады, включать их в глобальный список и прайсы при обновлении перераспределятся, что приведёт к оптимальному количеству записей на базу (см.пункт 1).
8. Можно для каждой базы включить режим освобождения и база постепенно очистится до нуля. Используем для обновления ПО, для переноса данных между серверами и для других целей.
>> Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update
>> where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
>> Ниже уже написали про infile, insert on dublicate. Вообще трудно предложить хороший вариант, не зная деталей.
infile это хороший вариант, но не в нашем случае, я немного раскрыл смысл об этом камментом выше.
2. Фактически, заливаются операционные данные, к которым идут постоянные обращения. И тут надо, во-первых, обеспечить валидность данных в любой момент времени. Во-вторых, закладываться на пиковую нагрузку, чтобы в любой момент обеспечить допустимое время отклика.
Для обеспечения этих требований в наших условиях вариант с предварительным расчетом дифа между заливаемыми прайсами и апдейтом только изменившихся строк работает быстрее.
Ну, а там, где прайс изменяется кардинально или заливается в первый раз применяется как раз похожий insert.
нужно искать скопом по всем залитым прайсам, нужно чтобы скорость ответа была менее 0.5 секунды с учётом всего-всего
> LOAD DATA INFILE
кто-то должен был это написать, спасибо. Но к сожалению это не подходит, искать надо скопом по всем прайс-листам.
Это не у нас прайсы ) это у автолюбителей прайсы. Представьте себе обычный прайс-лист компании Mercedes содержит более 600 тысяч позиций. А mitsubishi — более миллиона. Но в ближайшие сутки из этого объёма покупатели будут искать примерно 5000 позиций и нельзя угадать какие позиции будут затребованы. А цены и наличие меняются каждый день. Нужно всё обновлять и желательно каждый день.
> Или вы там на полном серьезе делаете на каждый чих update where id =.?
Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
> На счет полезности информации — создать топик для откровений «мы смогли только innoDB как noSql заюзать» в 2015 году это сильно.
А это топик о том, что даже в 2015 году можно не стесняться и использовать простые способы для достижения результатов в бизнесе. Возможно люди на хабре ждут каких-то новых технологий, я же писал о реальных результатах.