
dypa
07.08.2017
17:38:53

Adel
07.08.2017
17:44:18
elastic уж

Elizaveta
07.08.2017
17:44:37
Спасибо)

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

Google

Pavel
07.08.2017
17:52:37
lucene & solr это же все по сути elasticsearch

Alex
07.08.2017
21:34:59

Pavel
07.08.2017
21:35:32
Ну да, попарные аксиомы эскобара так сказать
Итого, получается что есть лишь два уникальных решения - sphinx и ES
Ну и еще postgres fulltext search ;)

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

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

Alex
07.08.2017
21:38:29
он так и развивался, как ни конфа, так ждите 3.0 :) и так каждый год
может к наступающему HL выйдет наконец

Pavel
07.08.2017
21:41:20
HL 3 ?

Alex
07.08.2017
21:42:17
HL++2017

Dmitry
07.08.2017
22:37:06
а он вообще нужен? 3.0


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

Google

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

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

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

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

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

Eugene
08.08.2017
10:54:49
пачками по Х штук
Что-то делают - берут пачку записей и каждую из них как то обрабатывают, результат куда-то отправляя.

Dmitry
08.08.2017
10:58:27
что значит пачку? как они эту пачку выбирают то

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

Dmitry
08.08.2017
11:01:08
а, ну так я думал у тебя уже работает система

Eugene
08.08.2017
11:01:29
Пока только в один воркер каждого типа
Сейчас оно ориентируется на метки времени обновления записей и время последней обработанной записи
А мне бы эти воркеры линейно смаштабировать

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

Eugene
08.08.2017
11:03:11
Постоянно
Макс скорость 500 измененных или добавленных записей в сек.

Dmitry
08.08.2017
11:08:07
Не, ну тут все же менеджер какой-то свехру нужен будет. Узким местом он может стать только если воркеры очень бястро отрабатывают.
другой вариант - если ты найдешь что-то в базе, по чему можно равномерно партицировать воркеры... тогда ваще лафа

Pavel
08.08.2017
11:16:20
Еще погугли про консистентное хеширование, может наведет на какие то мысли

Eugene
08.08.2017
11:19:26
Хм...

Google

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

Pavel
08.08.2017
11:25:10
Если ты равномерно партициируешь задачи по воркерам то это замечательно. Но когда один воркер упадет, получается его задачи останутся без обработки. Надо по алгоритму так перестроить задачи чтобы они распределились по остальным воркерам
по сути воркер это получается "хеш-корзина" эдакая
id задачи должно отображаться в номер воркера
А вообще, почему в условии надо обязательно не блокировать запись на чтение? Имхо если у тебя прибывает данных со скоростью 500 в секунду, то тут уж по любому будет большая нагрузка как ни крути

Dmitry
08.08.2017
11:32:26
а смысл ему блокировать на чтение, у него скорее проблема выбрать - какой воркер какой кусок кушает

Pavel
08.08.2017
11:32:56
По хорошему надо заапдейтить запись
Поставить в ней флаг что она обрабатыаается воркером

Eugene
08.08.2017
11:33:34
Заапдейтить исходную не могу потому что читаю со слейва
А блокировать на чтение надо но только в рамках воркеров одного типа

Pavel
08.08.2017
11:34:04
Ну тогда это случай очереди

Dmitry
08.08.2017
11:34:16
дорого апдейтить то как-то

Eugene
08.08.2017
11:34:39
И апдейт не сразу доедет

Pavel
08.08.2017
11:34:50
Накидываешь в очередь что прилетела работа, а воркеры толпой разгребают ее

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

Pavel
08.08.2017
11:36:10
либо так либо нагрузка на io :)

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

Pavel
08.08.2017
11:36:52
Вроде реббит надежно хранит

Eugene
08.08.2017
11:37:08
С реббитом опыт есть
При таких обьемах надо уже эрланг учить:) ибо у него не так хорошо

Google

Pavel
08.08.2017
11:42:43
Похоже на то

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


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


iillii
08.08.2017
13:05:41
modx?

Максим
08.08.2017
13:06:57
modx?
а он разве eCommerce?

Андрей
08.08.2017
13:08:07
он как joomla и wordpress, надо ставить компоненты eCommerce

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

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

Sparrow
08.08.2017
13:41:41
для магазинов OpenCar
t

Vladimir
08.08.2017
14:15:17
для modx есть дополнение shopkeeper
отлично работает
но тоже много что нужно править ручками

iillii
08.08.2017
14:17:39

Vladimir
08.08.2017
14:18:25
систему оповещения, статусов, отправки в CRM если нужно, ну и много много всего

iillii
08.08.2017
14:19:48
тогда лучше minishop2. Буквально недавно занимался интеграцией с amocrm
не знаю как в шопкипере, но у минишоп есть события на смену статусов, можно плагины написать

Vladimir
08.08.2017
14:21:57
небыло у мен яеще проекта - чтобы магазин сделать только при помощи модулей. Modx был выбран для калькулятора, так как побоялся что не смогу его сделать на опенкарте
https://citybaget.ru/calc.html

Google

Vladimir
08.08.2017
14:22:24
вот такая вот штука получилась

iillii
08.08.2017
14:23:27
ну да, на modx самое то такие проекты делать

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

Максим
08.08.2017
14:38:19

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

Dmitry
08.08.2017
14:39:49
да не, для мелких штат слишком жирно, хватит аутсорсера

Pavel
08.08.2017
14:40:16
Аутсорсер тоже же может быть в штате
Главное чтобы постоянно контрибьютил