Веселые новости про Sphinx3.0 sphinxsearch.com/blog/2017/07/24/sphinx-2017/

альтернативы?!

elastic уж

Спасибо)

Lucene. Solr. Самому написать в конце концов. Тыжпрограммист!

lucene & solr это же все по сути elasticsearch

lucene & solr это же все по сути elasticsearch

только наоборот ^_^

Ну да, попарные аксиомы эскобара так сказать

Итого, получается что есть лишь два уникальных решения - sphinx и ES

Ну и еще postgres fulltext search ;)

ES базируется на lucene, а lucene пилят те же парни, что и solr :)

Сделать часть функций сфинкса платными - очень правильно и хорошо. Иначе вообще не представляю как проект может развиваться на чистом энтузиазме.

он так и развивался, как ни конфа, так ждите 3.0 :) и так каждый год

может к наступающему HL выйдет наконец

HL 3 ?

HL++2017

а он вообще нужен? 3.0

Комрады, нужна помощь коллективного разума. Вводные данные - есть большая БД, в которые есть денормализованные записи данных в одной таблице Количество записей - миллиарды. изменения (upsert) - до 500 операций в секунду. Есть набор воркеров, которые с этими записями что-то делают. Чтение со слейва (репликация асинхронная). Воркеры, в зависимости от задачи делятся по типу. В рамках каждого типа воркеры должны быть линейно масштабируемы количеством. Воркеры не изменяют состояние оригинальной записи в данные в БД откуда читают вообще. Разные по типу воркеры не должны взаимно блокировать запись. При этом естественно воркеры одного типа должны взаимно блокировать одну и ту же запись друг для друга для исключения повторной обработки. Типов воркеров сейчас 5, но будет больше (допустим 10). Как решить проблему взаимной блокировки в рамках одного типа и обработки новых данный? Пока самое оптимальное что придумал - таблицы очередей в отдельной БД, с оказание pid, времени блокировки, статуса, айдишника записи. Но вижу минусы: - отдельная БД, сетевые расходы, дисковый ввод/вывод сильно сократят скорость обработки. - количество записей в очередях = кол-во записей * кол-во типов воркеров. - IOPS на очереди будет 500 * 10 *2 (скорость изменения основных данных на количество типов воркеров + сначала заблокировать, потом поставить статус). РСУБД не сдохнет под такими обьемами и IOPSами? А если не РСУБД то можем потерять очередь и придется заново обрабатывать все данные что не есть ок. Поговорите со мной, а? А то я мозг сломал...

А не проще над воркерами поставить менеджер который собственнои будет рулит тем какому воркеру отдеать на обработку очередную запись? Аля балансер.

Ну как бы если так, то либо банасер может потенциально стать узким местом, либо он должен быть масштабируемым и тогда мы опять получаем проблему блокировки. Хотя и в меньшем объеме. Ну и вертеть все равно какое-то хранилище для промежуточной связи балансер - воркеры (не будет же балансер ждать ответа?:)

Узкоместо всегда будет. Вопрос лиш в том как ты можешь это отмасштабировать и за какие суммы. В любом случае говорить о её необходимости сложно без нагрузочных тестов. И да естественно нужно отдельное хранилище под записи балансера, какое это уже смотри из задачи. И да балансер ждет подтверждения о том что работа выполена, иначе данные могу улететь в трубу или не долететь до неё (упал воркер, выключили свет и т.д.). Думаю для обмена сообщениями можно использовать что то вроде RabbitMQ.

Как то из конкретики пошли в теоретику про деньги и постоянное наличие боттлнека. Спасибо за предложенное решение, но мне оно кажется еще более плохим, т.к. балансер - еще один лишний компонент, появляется хранилище обмена данных балансер - воркеры, и никуда не делалось хранилище балансера (которое в моем случае - то же самое хранилище блокировок для воркеров)

А что значит "что-то делают?" выбирают следующую запись и что-то с ней делают? Или пачками. Как вообще выбор записи для воркера происходит

пачками по Х штук

Что-то делают - берут пачку записей и каждую из них как то обрабатывают, результат куда-то отправляя.

что значит пачку? как они эту пачку выбирают то

Воот:) ты фактически ткнул в самое больное место.

а, ну так я думал у тебя уже работает система

Пока только в один воркер каждого типа

Сейчас оно ориентируется на метки времени обновления записей и время последней обработанной записи

А мне бы эти воркеры линейно смаштабировать

А записи прибывают постоянно или тебе фиксированный объем нужно отработать?

Постоянно

Макс скорость 500 измененных или добавленных записей в сек.

Не, ну тут все же менеджер какой-то свехру нужен будет. Узким местом он может стать только если воркеры очень бястро отрабатывают.

другой вариант - если ты найдешь что-то в базе, по чему можно равномерно партицировать воркеры... тогда ваще лафа

Еще погугли про консистентное хеширование, может наведет на какие то мысли

Хм...

Паша я наверное тупой. Я вроде в курсе про это но не очень связываю это и мою задачу...

Если ты равномерно партициируешь задачи по воркерам то это замечательно. Но когда один воркер упадет, получается его задачи останутся без обработки. Надо по алгоритму так перестроить задачи чтобы они распределились по остальным воркерам

по сути воркер это получается "хеш-корзина" эдакая

id задачи должно отображаться в номер воркера

А вообще, почему в условии надо обязательно не блокировать запись на чтение? Имхо если у тебя прибывает данных со скоростью 500 в секунду, то тут уж по любому будет большая нагрузка как ни крути

а смысл ему блокировать на чтение, у него скорее проблема выбрать - какой воркер какой кусок кушает

По хорошему надо заапдейтить запись

Поставить в ней флаг что она обрабатыаается воркером

Заапдейтить исходную не могу потому что читаю со слейва

А блокировать на чтение надо но только в рамках воркеров одного типа

Ну тогда это случай очереди

дорого апдейтить то как-то

И апдейт не сразу доедет

Накидываешь в очередь что прилетела работа, а воркеры толпой разгребают ее

Ну я это и имел ввиду под изначальным решением. Но мне это не нра потому что размер очереди кратен количеству типов

либо так либо нагрузка на io :)

А использование решений которые в памяти хранят может привести к потере очереди

Вроде реббит надежно хранит

С реббитом опыт есть

При таких обьемах надо уже эрланг учить:) ибо у него не так хорошо

Похоже на то

Кароче пока склюняюсь к тому что сделаю демона который будет по новым записям плодить сообщения в очереди соответсвующих воркеров. А в очередях уже блокировать по пиду и на определенное время на случай если воркер упал.

Но очередь на рсубд делать...

Всем хау! Ребят, на чём сейчас интернет-магазины лучше делать? Долго выбирал и сомневался, но всё-таки начал проект на PrestaShop 1.7.0. Лучше бы я этого не далал. Что не понравилось: 1. сырой, очень сырой, аж влажный 2. плагины от 25 $ и выше, было приобретено для проекта порядка 7 плагинов, из них 5 оказались откровенным говнокодом (за два из них был возврат средств, три допилил кое-как) 3. чтобы запилить сверстанный дизайнерский шаблон (дизайн разрабатывался не под престашоп) потребовалось сделать override половине классов с переписыванием стандартного функционала. но это не совсем недостаток, благо хоть есть такая возможность и не надо было корёжить код ядра. 4. возможно в 1.6 было бы меньше сырости, но, как я понял, там тоже хватает своей кривизны. Проект я таки доделал и сдал, но баги до сих пор прилетают и приходится их фиксить. В общем, я вряд ли ещё буду делать интернет-магазин на PrestaShop. Если я правильно понял, сейчас в тренде Magento и OpenCart. Но magento потянет не каждый сервак. Пока что я остановился на OpenCart. Если кто что может сказать по этому поводу, буду рад. Если с OpenCart всё так же тухло как и с PrestaShop, то, видимо, надо велосипедить свой движок, чего делать нет абсолютно никакого желания.

modx?

modx?

а он разве eCommerce?

он как joomla и wordpress, надо ставить компоненты eCommerce

Да, все верно, нужно ставить дополнительные компоненты, которые кстати бесплатные и поддерживаются. Написать свои дополнения к компонентам не составляет труда. В modx очень удобно работать со сниппетами. Я сам раньше на joomla, dle, bitrix1с работал, но как испытал опыт на modx, работаю, в основном, теперь с ним. Это универсальный вариант подходит для разных рода задач.

хм, поковыряю его на досуге, но меня не покидает мысль, что в движке, который не заточен изначально под ИМ, многое придётся допиливать ручками, но это лишь предположение.

для магазинов OpenCar

t

для modx есть дополнение shopkeeper

отлично работает

но тоже много что нужно править ручками

но тоже много что нужно править ручками

в основном системы оплаты интегрировать

систему оповещения, статусов, отправки в CRM если нужно, ну и много много всего

тогда лучше minishop2. Буквально недавно занимался интеграцией с amocrm

не знаю как в шопкипере, но у минишоп есть события на смену статусов, можно плагины написать

небыло у мен яеще проекта - чтобы магазин сделать только при помощи модулей. Modx был выбран для калькулятора, так как побоялся что не смогу его сделать на опенкарте

https://citybaget.ru/calc.html

вот такая вот штука получилась

ну да, на modx самое то такие проекты делать

Мне видится что мало смысла делать интернет-магазин без встроенного программиста в штате. Всегда нужно дорабатывать юзабилити, акции проводить, реагировать на фидбек, следить за тех. метриками. А раз так, то и магазин лучше делать на фреймворке - так будет гибче.

Мне видится что мало смысла делать интернет-магазин без встроенного программиста в штате. Всегда нужно дорабатывать юзабилити, акции проводить, реагировать на фидбек, следить за тех. метриками. А раз так, то и магазин лучше делать на фреймворке - так будет гибче.

ну это идеальный вариант. но его не потянуть многим начинающим бизнесменам

Может оно и к лучшему, а много случаев когда начинающие бизнесмены делали магазин на CMS и потом он становился успешным и развитым?

да не, для мелких штат слишком жирно, хватит аутсорсера

Аутсорсер тоже же может быть в штате

Главное чтобы постоянно контрибьютил