Вероятно работает файловый кеш...
Данных всего 4гб ?
Пробовали какой-нибудь "ramdrive" ?
Т.е. смонтировать том "в оперативную память" загрузить это всё на него и делать к нему точно такие-же запросы ?
У меня при таком решении буст был даже по сравнению с SSD очень ощутимым.
Тут еще надо смотреть как вы там читаете... не окажется ли так, что чем дальше от начала файла ваши данные, тем дольше выполняется всё это и по факту он не по смещению читает, а действительно перебирает начиная с начала. Это надо проверить. Проверить легко. Допишите в каждый файл 1-10мб в начало(любого мусора), сделайте офсет всего что у вас есть на эти 1-10мб и посмотрите изменится ли время.
ЗЫ. Нельзя ли как-то по-другому данные сгрупировать прям сразу...
Было бы неплохо до того как ставить эксперименты немного подумать, ну и почитать там какие-нибудь "********и для детсада" итп.
Чтобы по результатам можно было сделать сколь-нибудь ценные "выводы", а не просто "сайт А взлетел, сайт Б нет".
Так разбивайте, в чем проблема ? Всеж равно придется.
В CRM... ИМ-то тут причем. Причем в CRM данные только приходят, оттуда они не уходят уже.
Я что, придя к вам в оффлайн-точку буду как-то авторизован через ИМ как покупатель ?
А когда ваш ИМ под "ддос" мне будут говорить "не можем пробить скидку потому, что что-то не работает" ?
Взачем вам это ?
Хотите ЛК... нет проблем, только зачем его в базе хранить ?
В чём резон ?
Части ЛК всё равно не меняются.
Статус заказов ? Выгружается из системы управления при изменении.
Разумеется. Однако не очень понимаю, зачем вы вообще внешние обмены какие-то хотите осуществлять.
Не надо этого делать. Вообще не надо.
Исключение - подтвержденный заказ. Его надо "пропихнуть" туда, куда надо.
И, разумеется, копию сохранить локально.
Кстати, можно просто локально сохранять и потом уже забирать по sftp и разворачивать в свою систему.
Я не очень понял о какой нагрузке речь, проясните пожалуйста ?
Что, на 99% статический сайт с одним скриптом приема заказа будет выдерживать меньше нагрузки, чем ИМ в котором для показа любой страницы по 100 запросов в базу и по 300мб php кода "собирается" ? почему ?
ИМ как вы понимаете работает и принимает заказы абсолютно автономно.
Система учета-то тут причем.
Даже если она "ляжет" ИМ будет продолжать работать.
Учет ведет система учета, при факте заказа она меняет соответствующую страницу(ы) ИМ уменьшая количество товара.
Статистику собирает гугл, яндекс и нгикс.
Аналитика... не знаю о какой речь, но, полагаю она тоже легко реализуется отдельно.
Если статически - вообще 0 проблем.
Смотря какие связи. Если статически - нет проблем, стройте. В ИМ-то зачем тащить.
Если вы мните себя "амазоном", и хотите "персональную витрину" то таки да, придется писать гигантскую систему аналитики поведения пользователя.
Сколько магазинов, где это даст реальный выхлоп кому-то, кроме того кто получит за это бабки?
Пожалуй, наверное, 100-1000.
В мире.
Если резервация и заказ осуществляется внутри вашей системы управления, то там будут и ваши транзакции.
Как таковые "транзакции" обеспечить можно и без БД. В том одном месте, где это нужно.
От хотелок зависит ей богу.
Если ИМ - это интерфейс "продажи", то проблем не будет.
Если кто-то хочет использовать ИМ, как средство автоматизации бизнеса, то ничего не получится.
(а таких дебилов все больше).
Я уже 20+ лет назад так и делал.... и продолжаю.
Даже свой аналог смарти написал ничего про него не зная. (когда нашелся смарти - выкинул)
Оказалось, что всё это и на простые ИМ с легкостью "натягивается", а при некоторых условиях очевидно можно и на непростые---------- Добавлено 13.01.2020 в 12:31 ----------
У меня в ювелирке как-раз :)) заведена. Но не в 1С правда, а в собственную систему управления.
Не вижу никакой проблемы заводить и в 1С... всёж равно придется заводить так или иначе.
В целом 1С тут неправильно припоминать. Проблемы вашего клиента в том, что вместо того, чтобы иметь связку типа
1С <-> Моя система управления <-> ИМ
Он имеет
1С <-> ИМ
И вынужден реализовывать многие вещи не там, где удобно, а выбирать один из двух сортов "говна", или в ИМ их пихать, или в 1С, а им не место ни там, ни сям.
Но "ваша правда" - это то тонкое место, которое надо очень тщательно продумать.
Но продумать придется в любом случае, иначе никак.---------- Добавлено 13.01.2020 в 12:35 ----------
В чем проблема ? Есть логин пользователя, есть файл в котором хранится его ЛК. БД тут зачем ?
Авторизация по СМС либо через соцсети. Пароль вообще не нужен, кто его помнит-то ?---------- Добавлено 13.01.2020 в 12:51 ----------
Мусор ? Мусор лучше не хранить.
Нужные данные надо где-то хранить. И как правило "это" - это система управления.
Какая-то штука, в которой делать это удобно, и которая "кормит данными" 1С, ИМ, CRM и всё остальное
Давайте с примерами, а :) ?
Иногда лучше читать, чем бредить. Без обид...
Ничего, что речь шла об ИМ на +- 1000 товаров, а вы пытаетесь натянуть эту сову на 100к :) ?
И да, раз в 10 сожмете, а может и в 20.
И да, если вам нужен полнотекстовый поиск по описаниям (зачем?), то лучше-бы его делать как-то по-другому.
ВЕРНЫЙ ВОПРОС !
Зачем использовать sql БД если можно делать и без неё :) ?
Зависит от реалий. Они у каждого свои.
И скажите, что там с поиском получается при таком увеличении ассортимента :) ? Текстовый по описаниям ?
Дайте что-ли пациента, я вам его с сотни-другой прокси на поиск "проверю".
И посмотрим через сколько времени вас отключит хостер.
Думаю мгновенно.
Вы читали тезисы ?
Повторюсь. Это решение может быть использовано только в случае, если размер базы невелик.
Тысячи позиций "в пределе".
Таких ИМ полагаю 99.9% от общего количества.
Если надо больше - лучше сувать в специализированную БД и доставать оттуда.
Но только поиск.
Остальное в sql БД сувать бессмысленно.
Ну они вроде без авторизации отдают... значит так или иначе спарсите свои 50к, пусть даже 1к прокси для этого понадобятся (к примеру).
Думается капча потом появится, запроса после энного.
В чем проблема сформировать url ? Вроде-бы всё в полях кнопки для него есть.
Что не работает ?
Как минимум один.
Когда они отказались менять баксы на золото, припоминаете :) ?
А вы, простите, верите, что если не было, то и не будет :) ?
Я всего лишь описал ТИПОВУЮ схему при которой можно и граждан не злить, и неграждан обуть по самые помидоры.
Да хоть сотни.
Из 1С выгружается готовый какой-нибудь "json" или то, что надо, он упаковывается и посылается один раз пользователю.
И потом с клиентской стороны это всё курочится.
Весь вопрос только в размере файла и объеме обработки на клиенте. Если допустим - делаем, нет, изобретаем что-то еще.
Для сотен и тысяч товаров это будет работать, для сотен тысяч наверное нет.
О какой админке вы говорите :) ?
Нет никакой админки, зачем она ИМу вообще :) ?
Хотите продавать товар ? Заводите в 1С, после чего он синхронизируется с ИМ и товар появляется.
Вы ведь все равно не сможете продать то, чего в 1С нету... никак.
И да, в этом случае пользователи получат новую версию файла для поиска, увы.
Еще раз подчеркиваю: всё это только в случае, если ассортимент не слишком большой и поисковая база может быть доставлена клиенту. Таких случаев 99.99% от общего числа ИМ.
Если "слишком", то увы, вероятно придется из 1С заполнять какую-нибудь базу и в ней искать уже потом.
Будет это SQL или какие-нибудь "эластики" - вопрос 10й.
Однако база эта скорее всего будет содержать только одну таблицу, собственно для поиска/фильтрации по ней.
Возможно весьма избыточную таблицу.
А как еще-то :) ?
Категории получаются "сразу", в том смысле, что выгружаются отдельно из системы управления "готовыми".
Фильтры и поиск - да, проблема. Я об этом пишу в каждом первом сообщении.
Если много и разного - придется городить что-то... возможно БД.
Если мало... то я один раз сгружаю на сторону клиента 100кб данных и уже на его стороне всё это обрабатывается.
100кб - это весьма прилично... я думаю я не 100 сгружаю, а меньше гораздо, это я так... с запасом.
При этом, к примеру, поиск по названию и подсказки для него происходит абсолютно мгновенно.
Да и фильтрация тоже. Приезжает только графика "не сразу"
Да ради бога, кто сказал что я их дам :) ? Мыж говорили об авторизации, не ?
И разницу между "опубликовать от имени предупредив об этом заранее", и "взломать аккаунт", полагаю на этом форуме объяснять не надо.---------- Добавлено 10.01.2020 в 16:52 ----------
Думаю почта сделает всё-таки.... это могло бы спасти наложку.
Не можете.
Если ТСу нужно содержимое файла, то вы не можете ничего побить.
Если он обращается к содержимому по пути, то это будет не медленнее, чем обратиться по индексу, а может быть быстрее.
Если файл невелик, то разницы "считать весь / считать часть" не будет (чтение всё-равно идет блоками).
Если файл невелик, то чтение из него не будет медленнее, чем "достать через индекс из БД только нужное", а может быть быстрее.
Разумеется, если ТС что-то там "перебирает и ищет", то делать так НЕ НАДО, надо строить индексы итп.
Но если он достает файлы по их именам, для работы с их содержимым, то переход на базу не даст ему ничего кроме тормозов.
Давайте поспорим.
Вы делаете обычную, штатную авторизацию через фейсбук у вас на сайте.
Я авторизуюсь.
Вы взламываете мой фейсбук-аккаунт.
Предлагаю в качестве "ставки" - 1000$.
Переводим какому-нибудь "гаранту" с форума.
Если вы побеждаете в течении месяца - деньги ваши. Если я, вашу часть переведем на благотворительность.
Деньгами за свои бредни отвечать готовы ?
