Приветствую, уважаемые форумчане! Дано: Сайт-магазин оптовик с API Сайт-магазин розничный. Владелец розничного магазина хочет получить каталог товаров (600k) с оптового магазина через API И ежедневно обновлять базу данных через Cron. Вопрос: Как не положить БД под такой долбилкой? Полагаю, что сервак должен быть выделенный однозначно... Жду Ваших комментариев.
в АПИ оптовика предусмотреть метод который будет возвращать только разницу при запросе (например после даты последней синхронизации) - вот объемы значительно и уменьшатся. Да, и тема поста странная при чем тут количество запросов... в идеале запрос может быть вообще один - хоть на 100 тысяч мильенов данных
Индексы и больше памяти под кэш. То что на обычном хостинге тебя попросят пойти лесом, таки да, но впска вида 2 ядра - 2 гига, должна переварить всё это. Если конечно не начудить с настройками и не нагвнокодить на пыхе ) --- Добавлено --- Кстати, обрати внимание на такой момент: тебе нужно отдавать не только текущие товары / цены / остатки но и как-то обозначать позиции которых уже в наличии нет. Вообще, @ADSoft верно написал, должно быть api для получения данных о товарах и дифф за период, что бы каждый раз не грузить всё заново.
Дело в том, что АПИ уже готово. И подобной фичи я там не видел. Дока большая, мог просто провтыкать. Я работаю (предположительно буду работать в ближайшее время) только с розничным магазином на 1С битрикс.
Ну что скажу... кроме вас эту доку за вас никто не изучит и если это действительно оптовый монстр и у него я подозреваю не только ваш магаз - то вопрос у них возникал этот в самом начале и скорее всего был успешно решен....
А, так тебе надо что бы битрикс выдержал ежедневное обновление 600к товаров? Тогда удачи ) Я битрикс всегда обходил стороной, но судя по тому что видел, он уже на 100к начинает превращаться в живой труп (
Если это оптовый монстр, с такими запросами, то мб стоит им намекнуть, что это не тот случай, когда можно экономить на серваках? Именно во множественном числе. Несколько машин в горизонталке будут работать лучше одной, ваш К.О. Нагрузка будет примерно обратно пропорциональна количеству машин. На входе можно поставить 1 коробку с nginx. Судя по тому, что я видел, он является таковым уже "искаропки", выживая лишь за счет костылей и живительных клизм в виде битрикс-VM, "спец.услуг тонкой настройки вашего сервера под битрикс" и тд. Даже на хостингах в странах СНГ порой глядишь тарифы: Дедики, ВПС, Шареды, БИТРИКС-ХОСТИНГ! Но маркетологи у них от бога, это факт, учитывая популярность продукта. Это с их-то ценами и требованиями.
Оптовый монстр - владелец API. Сотрудничество будет не с ними. Они лишь ограничивают количество запросов в секунду (250 запр/сек). Так что вряд ли смогу им на что-то намекнуть. А битрикс буду грузить по нарастающей плавно. Убеждать кого-то, что вордпрессы с джумлами и битриксами являются кучей известно чего - бесполезно. Юзали, юзают и будут юзать. Тем более он уже куплен. И меня ни кто не спрашивал, стоит ли его покупать.
Я всё ещё не понял в чём проблема. Загнать 600 000 записей в базу, серверу работы на 30 сек. (в зависимости от структуры - до пары-другой минут). Если ты про это.
да проблемы пока нет никакой. Просто хотел посоветоваться заранее. Больше всего меня интересовали необходимые мощности. загнать и раз в сутки обновлять кроном. Подгонять изменения по ценам, остаткам и т п --- Добавлено --- Пардоньте, 250 запросов/10 сек
Без разницы. Почти. Обновление даже побыстрее будет, чем добавление нового. Хотя конечно, всё зависит от задачи и алгоритмов.
Надо прост формировать большооооой запрос, как при дампе бд, сохранять его в файл и вызывать команду mysqlimport.
@TeslaFeo Да 600 000 это фигня. Я по фтп грузил баш скриптом, в базу каждый час обновление семи миллионной таблицы (имеется ввиду строк). Обновление происходило примерно за 40 сек - минута. С учётом скачивания на сервер. А заливка в базу вообще быстрой была. То есть старая удалялась, новая добавлялась там в районе 3-4 секунд вообще было добавление. --- Добавлено --- Если ты на экран не выводишь циклами 600к строк а всё это делаешь внутри кода. То там всё реактивно добавится Чухнуть не успеешь. Это надо постараться на 7-ьмом пыхе сделать так чтобы где то чё то подвисло.