TwitterЗадача для разбирающихся в “облачных” вычислениях
Posted on November 8th, 2010 by Max Kraynov
Задача: у вас есть супермаркет, собирающий информацию о покупателях:
- Историю покупок – купленный товар, стоимость, дата приобретения, используемый тип платёжного инструмента и т.п.;
- Историю посещения магазина – в каждую тележку и корзинку встроен сенсор, позволяющий отслеживать перемещения по магазину покупателя и человека, ушедшего ни с чем;
- Факт снятия товара с полки – товар попал либо в корзину, либо обратно на полку. Так отслеживается интерес покупателя к новым товарам.
Ежедневно генерируется 200 миллионов точек данных. Данные хранятся на протяжении 7 дней. Со временем планируется добавить ещё несколько источников данных, чтобы в любой момент времени можно было создавать предложения, уникальные для посетителя. Понятно, что основная сложность – это не хранение, а выборка данных.
Возникают следующие вопросы:
- Как лучше построить данную систему? С нуля или воспользовавшись фреймворками / дополнительными технологиями? Какими?
- Стоит ли рыть в сторону MongoDB/NoSQL? Или можно обойтись MySQL с базой полностью в памяти + MemCache?
- Можно ли сделать распределённую систему таким образом, чтобы можно было гонять выборки / отчёты по этому массиву данных? Или требуется определить срезы / dimensions и пытаться их строить почти в реальном времени?
- Решается ли такая абстрактная задача за $3-5M? (В бизнес-кейсе использовалась стандартная ставка $125/час работы программиста. Да, такие ставки есть.)
Приветствуются ссылки на имеющиеся реализации схожих (по сложности, необязательно по тематике) задач.
ЗЫ. Спасибо всем комментаторам, подкинувшим много интересной информации.
Filed under: Бизнес, Мысли вслух
Подписаться по Email
По поводу второго пункта вопроса вспомнил свежую статью http://l-o-n-g.livejournal.com/153756.html “Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду”. Возможно, будет интересно.
Да, читал эту статью. Интересный эксперимент.
Мы (pushme.to) сейчас рассматриваем вариант построить на этой штуке preproduction мессенджера и погонять. В порядке изуччения. Уж больно интересная штука.
Этот проект лишь доморощенная версия облегчённого биндинга, на описанном Максом кол-ве данных не даёт ничего, так как используется для простых паттернов доступа. По той же причине не оптимально официальное решение MySQL Cluster. Для BI / Decision Support / Datawarehousing ни одна мелкая СУБД или NoSQL не имеет оптимальных инструментов. Потуги в этом направлении совершает Oracle, MS, IBM (Informix).
*Хранение* этих данных – ерунда, задача совершенно тривиальная.
*Выборки* по этим данным – вот где спрятана вся сложность.
Но чтобы ответить на второй вопрос, нужно больше конкретики: что именно мы храним, и примеры основных выборок, которые хочется получить в режиме реального времени. Тогда можно будет подобрать правильный сторадж или их комбинацию, а также технологию аггрегирования данных. Тогда же можно будет ответить и на третий вопрос.
Те, кто решал подобные задачи, не всегда готовы светить ссылками в паблике. 🙂
Оценивать бюджет вашей задачи еще рано, мягко говоря, но $3-5m кажутся чрезвычайно завышенной суммой.
>>но $3-5m кажутся чрезвычайно завышенной суммой.
[sarcasm]просто сумма меньше не может появится в этом блоге в заметке не о личных финансах[/sarcasm]
см. мой предыдущий ответ по поводу суммы.
Есть некоторые задачи, стоящие $50k, на которые тратится по миллиону и больше. Причина – zero release (он же – стоимость собственно говоря релиза, без каких-либо изменений)
все бабки уйдут на сборку инфы а не на хранение и анализ 🙂
Дело в том, что я и настоящую задачу в паблике светить не могу. Выбрал максимально похожую, чтобы не выдавать клиента 🙂
Основная сложность – да, именно в понимании того, как эти данные будут использоваться. Точнее, в том, что есть 10 человек, ответственных за системы, которые используют эти данные, но которых всё и так устраивает.
200 мультов на запись выдержит почти кто угодно из приличных реляционных. Но не MySQL точно, вообще не понимаю, как он у тебя в эту тему попал.
Да, отчеты явно надо собирать чем-то многомерно-OLAPовским.
Цена на софт может быть и нулевой, теоретически. Если попробовать реализовать на Постгресс + Мондриан (http://ru.wikipedia.org/wiki/Mondrian). По железу даже прикидывать не берусь 🙂
Примеры кстати можно покопать в победных реляциях BI систем. Явно ограничение по скорости будет не при занесении данных, а при сборке их в кубы.
(offtopic) вы, наверное, предпочитаете FreeBSD?
Да вроде как нет… Даже не умею ни разу 🙂
Я предпочитаю MS SQL + Cognos Просто больше из BI ничего не умею толком 🙂
Хм. Ну я в том смысле, что на WinSrv у нас все. И в прошлом проекте и в этом.. И в позапрошлом… Ибо 1С толком до сих пор больше ни на чем не живет, не смотря на все заявления. Так что и хостинги под неё (текущий проект-продукт) тоже полнсотью на Win делаем, после долгих попыток попыток как-то запустить на линуксах.
ок, я обознался, значит. 🙂
Максим, использовать mysql (или другую rdbms) нужно, если будут явно и активно использоваться joins. В этом примере я бы предложил использовать nosql, в частности Redis, который хранит некоторую часть данных в памяти, а остальное в файлах. И периодически записывать сжатую/обработаную информацию в mysql для формирования отчётов из него. Memcache – тоже надо использовать, но только там, где это нужно.
Технологии – это смотря кто что умеет. Тут нет чёткого требования или ограничений. Я предложил бы такую систему разработать используя Symfony PHP Framework, так как я понимаю как это сделать, и знаю, что php не будет являться bottleneck.
Задача решается в указаном бюджете.
А, да, кстати. А облака то тут при чем ?
Как-то задача очень абстрактно описана. Особенно неясен пункт “найти”, видно только “дано” 🙂
Если вопросы касаются задачи хранения данных для одного конкретного супермаркета, то неясно при чем тут облачные вычисления :/
1. при наличии денег и требований к гибкости всегда, имхо, лучше сделать что-то свое. естесственно используя какие-то инструменты для решения определенных задач.
2. как показывает мой опыт с mongodb – стоит смотреть, особенно на таких объемах insert’ов в сутки(у меня 4-5M в день). MySQL хорош и достаточно быстр(особенно после последних хаков вокруг его sql-парсера) но имеет свои недостатки и риски.
3. что для mongo, что для mysql для аналитики будет критически важно иметь интересующие нас данные\индексы в памяти. в этом случае грамотно отшарденная база будет писаться на мастерах, а запросы бегать на слейвах с “многомозгов”.
4. видимо я не очень понял задачу(или Ваши реалии), но имхо, за $3-5M она решается раз 10 в различных позах 🙂
Я пробовал использовать MongoDB для сохранения биржевых тиков в реалтайме (а это много больше чем 200mln/day). Привлекала возможность гонять mapreduce из коробки по этом бешеному массиву данных.
Но увы – MongoDB от такого трафика не выдерживал и часа, умирал каждый раз в разной позе. Версия была 1.4. Это при том, что мы в продакшне используем MongoDB на мессенджере pushme.to и счастливы.
Видимо, это инструмент для не всех задач.
map\reduce в монго полезен только в академических целях пока что.
как именно умирал mongodb? хотелось бы подробности про позы смерти 🙂
ну и еще достаточно интересно, сколько в тачке было памяти.
…и, кстати, для биржевых данных была в итоге написана на C собственная система хранения, невероятно примитивная, но крайне надежная и производительная.
Зависал, segfault’ился, задумывался или распухал на диске. Не может он в реалтайме кушать много данных. Повторюсь, тот же Mongo прекрасно работает под нагрузками другого рода на соседнем проекте.
MongoDB делает mmap() на файлы, поэтому ОЗУ он использует принципиально иначе, чем все остальные базы данных. В данном случае памяти было меньше, чем данных.
“Пухнет” на диске он всегда, валился у меня только на 32битной машине при достижении лимита в 2G.
Вообще очень странно это, я помню стресс-тестил монго, кассандру и мускул инсертами. Никто лучше монги не справлялся, на слабенькой девелоперской машинке 10М записей(по 200-300 байт) вставлялись меньше чем час без всяких сайд-эффектов(разве что маппинг файлов затормаживал слегка процесс). Мне все ж кажется, что у вас были какие-то эффекты связанные с окружением на машинке.
Да нет, там была стоковая убунта и стоковая, от 10gen, MongoDB. 64bit.
http://highscalability.com/display/Search?searchQuery=hadoop&moduleId=4876569
Я честно сказать не великий специалист в этом вопросе, но анализировать скорее всего можно хадупом. Его можно периодически запускать в облаке, есть примеры.
200м строк в день в память врядли влезут, но есть куча тех же nosql которые влегкую такое потянут
цена на порядок завышена на мой взгляд
целесообразно воспользоваться готовыми решениями
базовый софт – несколько десятков тысяч $, начать можно и с тысяч $
настройка модели (консалтинг+тех.настройка) – несколько десятков тысяч $ – можно и больше (если нужно вчера)
плюс свое железо или облако в зависимости от бюджета – здесь цена железа/аренды облака
итого – задача решается меньше чем за $1M
тестовую демо-настройку модели могу сделать бесплатно
мой ящик webbox77@gmail.com
На мой взгляд такую систему на базе одного фреймворка не построить, можно использовать тот или иной инструментарий для решения конкретной подзадачи.
На мой взгляд “режим реального времени” для такой системы не нужен. В связи с чем достаточно собирать всю информацию в некторое хранилище, затем аггрегировать необходимые данные и выносить в другое хранилище для последующего анализа.
Мое видение архитектуры такое:
Раразбатывается неторое API (неважно на какой платформе и с каким фреймворком), который принимает данные и складывает их в какое-нибудь NoSQL хранилище (например, MongoDB). От такого API нужно совсем немного – обработать несколько типов POST запросов сформировать из параметров запроса простой JSON объект (c такими данными работать удобней, чем с простым Key-Value хранилищем, как Memcache) и сохранить его. Никаого UI. Если делать реально крутую систему, можно реализовать такое API на языке Scala (на Scala реализован API Twitter-а http://www.artima.com/scalazine/articles/twitter_on_scala.html, Scala в боевых условиях на нашем проектк показала себя очень-очень красиво)
Почему NoSQL?
– его легче машстабировать, по сравнению с более традиционными SQL решениями
– масштабирование можно делать в полуавтоматическом режиме
– при уменьшении нагрзуки (объемов данных) лишнии инстансы можно отключать
– поскольку потеря части данных не является критичным для такого проекта, то не так страшны сбои в оборудовании, кроме того скорость запиши данных в хранилище увеличивается за счет отсутствия транзакций, отсутствия индексов.
Понятно, что основная нагрузка на сервер будет приходиться на дневное время работы магазина. Поэтому в ночное время можно запускать отдельный сервис, который будут аггрегировать RAW данные и складывать их в какое-нибудь OLAP-хранилище (OLAP наиболее подходящее решение для анализа данных). После работы этого сервиса, RAW данные можно смело удалять.
Используя данные из OLAP хранилища можно реализовать приложение (Web/Desktop), которое будет формировать те или иные выходные данные:
– предопределенные выборки/отчеты
– графики
– что-нибудь по типу PivotTable (http://www.crazybikes.com/mrcjava/servlet/CBB2E.R00180s)
Тут можно выбрать какой-нибудь удобный фреймворк или набор компонентов для удобного и красивого построения UI
Насколько я знаю, идейно похожие решения используются в системах по типу http://www.flurry.com/product/analytics/index.html. Но это сервис, а не коробочное решение.
За указанный Вами бюджет реализовать наверняка можно. Не совсем ясно что же должно быть на выходе.
Брата спросил, порекомендовал посмотреть ещё в сторону StreamDB.
Описание идеи :
http://citforum.ru/database/articles/sqlstream/
Продукты:
http://www.streambase.com/
http://www.sqlstream.com/
http://esper.codehaus.org/
Посмотрите архитектуру ВКонтакте
http://www.insight-it.ru/masshtabiruemost/arkhitektura-vkontakte/
По сложности думаю примерно равные задачи.
Спасибо, но “собственная субд на С” меня как-то смущает 🙂
А пусть не смущает. Си это такой же язык программирования как и другие, а “база данных” – это всего лишь хранение чего-либо. Я выше в комментах написал, что мы нам пришлось разработать собственную базу на си для биржевых данных. Всего в ней получилось несколько десятков экранов кода на Си, работает предельно быстро и позволяет любые выборки. Просто специфика задачи такова, что эти данные легко хранить и обрабатывать вне зависимости от количества. Может и у вконтакте такая же специфика, может и у вас.
не совсем понятно зачем memcached ? проблема кол-ва запросов не стоит, так как это заранее определено. задача хранить много данных и быстро делать нужные выборки.
один вариант warehousing+olap на основе продкутов от известных брендов. второй, кластер mysql или nosql с применением map/reduce для обработки. здесь конечно руками все придеться делать.
1. PHP
2. MySQL + Memcache/Redis
3. Sphinx Search для создания распределенной системы
4. Craiglist использует Sphinx, возможно для похожих целей…
5. Сколько миллионов? надо чтоб прокормить команду разработчиков из 3-5 человек в течении полугода – года?
Как Егор сказал, надо бы поподробней описать requirements, тогда можно будет точнее выбирать технологии.
Исходя из моего опыта из разработок в банковской индустрии могу посоветовать KDB с языком “K”. Он используеться в живых банковских реал-тайм системах, практически индустриальный стандарт. Тянем миллионы запросов в час без проблем.
2Egor Egorov: может быть для вас KDB будет альтернативой “велосипеда на С” ? Как-ни-как провереная годами система, документация на неё есть – риски походу меньше 🙂
Я посмотрю, спасибо.
Для расчетов по большим массивам map/reduce работает хорошо, только проектировать надо сразу под нее.
Из NoSQL можно посмотреть на hadoop/hbase. В зависимости от требований по отчетам: скорость или масштабируемость, хоть в coachdb залить.
Я вот сейчас в redis данные от букмейкеров закидываю, тоже очень быстрое хранилище. Redis как раз позицианируется как замена связки mysql + memcache.
Сумма кажется завышенной, видимо overhead заложен, на случай если выбранная DB – например mongo как у егора, откажется работать в produciton и все придется быстро переписать.
Если есть интересный проект хотел бы поучаствовать.
Сумма взята по минимуму. Используется штатная ставка программиста $125/hr.
По моему мнению, это издевательство, но иначе нельзя.
full-text index (lucene or sphinx) и выборка в реальном времени готова
Gothy прав, задача описана абстрактно. Я занимаюсь разработкой систем управления рекламой с десятками миллионов запросов в сутки. Это конечно не сотни миллионов, но кое-что. Я бы скорее всего решал эту задачу путём написания демона для приёма сообщений, их обработки и складирования в логи. Логи бы периодически обрабатывал с целью формирования “стандартных” отчётов и аггрегации данных для дальнейшей работы.
Я так понимаю, сбор и хранение данных — это малая часть задачи? Эти данные должны использоваться… Наверное 3-5М включает не только сбор и хранение, а то это как-то сильно много?
Бюджет включает в себя ещё и создание поискового механизма в режиме pull (запрос-ответ) и push (триггер вызывает событие, которое передаётся нужному приложению).
Сложность не в коллекционировании write-mostly информации (что является самой простой задачей на свете) и натравливания на неё ETL cкриптов, а именно в использовании нужной информации в реальном времени. Например, я снял с полки молоко, и когда моя тележка проезжает мимо груды с коробками cereal, на тележке вспыхивает лампочка.
Я бы в таком магазине тележку не брал =) Оно же покупателю мозг порвет. Точно скоро холодильник будет сам за тебя продукты заказывать…
Если мой холодильник читает мой блог про список покупок – то однозначно это риск 🙂
Да ладно. Все уже все поняли, можно называть вещи своими именами.
Не тележка будет лампочкой вспыхивать, а мобильник-коммуникатор будет покупателем командовать. И все мы в скором времени, ну четверть населения примерно, превратимся в приложения к гаджетам.
UPD: я в марте этого года размышлял о подобной системе. только подходил со стороны heatmap’a посетителей у стеллажей и анализа кассовых чеков.
[]Историю покупок[]
[]Историю посещения магазина[]
[]Факт снятия товара с полки []
Да нет тут нигде офигенных потоков данных, тот же порядок, что и в традиционном потоке регистрации покупок – справляется обычная БД, оракел рулит. Облаков не надо.
3-4m$? Ну если только сильно постараться и запрячь под это дело ‘облака’ – тогда можно и освоить.. нет, даже маловато будет 😉
А вообще – имхо, во всей этой идее засада будет с сенсорами. Особенно по п.3.
описано что и как можно анализировать. достоинства и недостатки разних подходов. http://www.ozon.ru/context/detail/id/4877842/
По моему все предыдущие комментаторы не увидели главного в этом вопросе – а ради чего это собственно затевается. Видимо из-за того, что вопросы сформулированы были только в технической области. А на то что система нужна “чтобы в любой момент времени можно было создавать предложения, уникальные для посетителя” почти никто не обратил внимание.
Согласен, объемы достаточно большие, но не экстремальные, и правильная платформа для хранения важна. Но вот как вы собственно будете на этих данных решать главную задачу – формирование next best offer для покупателя? Это уже аналитика, требующая своего правильного инструмента, если вы не хотите делать все вручную или в полу-ручную, занимаясь программированием при каждой новой гениальной придумке маркетологов.
При таком бюджете думаю можно смело начинать смотреть в сторону больших аналитических платформ SAS к примеру (почти реклама, просто с ним работаю:)) или еще какой-нибудь и крупных игроков, включающий в себя весь спектр технологий, необходимых для такого решения – не только BI-CI-data mining для аналитики и управления маркетинговыми компаниями, но и скажем data integration когда понадобится скажем скрестить новую систему с CRM, например для перехода от модели анонимного покупателя к учету всей истории покупок конкретного человека/семьи или web-аналитика для анализа хождений по каталогу интернет-магазина и скрещивания этого всего с данными по оффлайновым продажам.
Мне кажется подход слежения за каждым покупателем слишком затратный. Нужно подходить ‘en masse’, охватывать так сказать целиком. Оптимальный вариант для реальной жизни heatmaps из веба. Мне всегда хотелось убедиться что весь этот мерчандайзингг с товарами на уровне глаз работает.
Ещё можно посмотреть в сторону CouchDB. Там как раз довольно приличная производительность views, задаваемых заранее через map-reduce. MongoDB – штука хорошая, но если база поломается, то можно сильно влипнуть.
Лично я бы делал на обычной RDBMS, но в режиме key-value storage с ручными индексами.
А готовые решения не рассматриваются? Я как-то переводил документацию по очень похожему на это описание решению для супермаркетов. Правда, там был комплекс софт+оборудование (сканеры штрих-кодов, кассы самообслуживания, дистанционные сенсоры и пр.), но если это новый супермаркет, железо все равно придется покупать, так что может и не дороже выйдет.
Только вот никак не могу сейчас сообразить, кто был производителем системы. Но если необходимо, могу поднять и прошерстить весь архив – найти можно, это только вопрос времени.
Антон, спасибо, пока необязательно. Если (когда?) надо будет – обращусь.
Без понимания что именно нужно отслеживать очень сложно вообще что-либо сказать. Если я верно уловил цель – Вы хотите на основе истории покупок и истории “просмотров” товаров определить что предложить юзеру в будущем. Побочный эффект анализа этих данных это оптимизация полок. Тут нет технологической сверхзадачи, HPC, по крайней мере я их не вижу в описании. В зависимости от широты интересов Вам нужна мощная платформа аналитики, не обойдётесь СУБД инструментами + несколкьо спецов по behavioral аналиике, консультация аналогичного психолога возможно. Так или иначе тут всё решают BI спецы, и вопрос решения зависит не от денег а от их уровня, от точности разработанного алгоритма, ибо процент точности будет решать принесёт разработка миллионы или вылетит в трубу
У нас работает схожий проект для аптечного бизнеса, анализируются все покупки в нескольки тысячах аптек, но в этом бизнесе запрещена привязка к конечному клиенту.
Вообще главным смпецом в этом сегменте в Европе считается Payback, возможно сможете погуглить что у них. А главное препятствие законы, так в Германии например запрещено использовать данные не отделив предварительно данные о клиентах от данных о продажах, что убивает всю ценность на корню.
В вашем случае хранить данные можно стандартными средствами – субд, in-memory data grids – главное логика и алгоритмы анализа, тут под ваш юзкейс я бы взял спецов с опытом работы в cегменте shopping suggestion и желательно с опытом в shopping comparison, 2-3 спеца с окладом по 150к в год за полгода вполне должны создать то что вы хотите. Дальше сотни тысяч вылетят в борьбе за гениев которые будут выдавливать доли процентов эффектвиности
Спасибо, действительно, указанные проблемы присутствуют. С программистами хорошими сложнее, т.к. их тут днём с огнём не сыщешь 🙁
с прайваси проблема решается так: в тележку встроен pda, в который покупатель вставляет свою клиентскую карту. на ней как раз и хранятся все личные данные и история покупок, а не в системе ритейлера. pda на основе данных карты и товаров в корзине и предлагает дополнительные продукты
В Macy’s для подобных целей используют Hadoop. Подробностей не знаю, но могу познакомить с человеком, который этим занимается.
Запишем, спасибо. Если потребуется – обращусь.
Интересная задача. Я с такими объемами не работал, потому не могу ничего сказать по этому поводу.
Но мне очень интересно стало как реализуется третий пункт? Сенсоры? Но как это соотносится с конкретным покупателем? Не с видеокамеры же распознавать образы.
сенсор встроен в тележку и кассу. При обработке покупки идентификатор тележки сопоставляется со списком покупок.
Да, с этим понятно. Я имел в виду именно третий пункт. “Факт снятия товара с полки”, с попадание в корзину или возвратом на полку.
RFID сканеры помогают отследить траекторию товара (обратно или в корзину).
Спасибо. Пойду погуглю для подробностей.
я не в курсе последдних разработок RFID но сомневаюсь что получится отслеживать перемещение товара в корзину по RFID. Интерференция и прочие дела из двух источников корзины и полки, убьют всю затею. А вот если в тележку встроить сканер штрих кодов и бонусом подсчета стоимости конечного ценника заставить клиента сканировать товар. Вот это было бы здорово, но опять же зачем? (разве только есть идея убрать кассы вообще)
А для анализа количества товаров на полках достаточно повесить камеру под углом к стелажам с товарами и анализировать по картинке то как полка пустеет.
Сканеры встраивают, чтобы сократить очереди на кассах (кассиру не надо паковать товары), ну и для особо скромных покупателей, которые не хотят, чтобы другие видели какие-то их покупки (с полки можно снять, когда никто не видит, провести по сканеру и сразу в пакет, а на кассе только рассчитаться).
не проблема отслеживать количество оставшегося товара на полке и вызывать мерчендайзера, когда товара становится мало, или когда покупатель выложил товар обратно из корзины не на ту полку.
у RFID до сих пор не решена проблема сбоя при размещении рядом с жидкостями. в лаборатории я видел различные попытки решить эту проблему, используя деревянную прокладку и размещая метку под углом к емкости, но, насколько я знаю, полноценного решения до сих пор нет
Насколько я знаю, в супермаркетах RFID-метки вешают на горлышки бутылок – так они прекрасно работают. В принципе, они и при наклейке на бутылки работают, но расстояние считывания на порядок уменьшается.
по крайней мере то, что мне показывали в немецкой rfid лаборатории – из-за воды воды у них метки читались нестабильно. по их опыту необходимо, чтобы между водой и меткой было несколько сантиметров.
с чтением серийных меток на каждом товаре при провозе паллеты через ворота – тоже не все было гладко – 2-3 метки периодически не читались.
с rfid в сетях есть еще один prerequisite – синхронизация мастер данных с поставщиками посредством электронного каталога. без качественных данных о товарах в инф. системе ритейлера проект обречен на неудачу
Привет Макс. MS BI отлично подходит для таких задач.
У меня есть опыт использования в подобных проектах – очень рекомендую.
Также, могу посоветовать очень хорошую компанию в Сиднее которая решает похожие задачи для крупных страховых и финансовых компаний.
Виталий:
я не понаслышке знаю, что такое MS BI (классная штука), но не уверен, что он может решать задачи выборки в реальном времени. Я ошибаюсь?
Все очень от требований зависит, насколько и какая именно нужна “реалтайминость” и т.п. В целом, MS BI позволяет анализировать одновременно исторические и “почти” реальные данные через ROLAP.
Конечно, это не настоящее реальное время типа “бегут цены на акции”, но вам возможно такого и не надо для проекта.
Привет.
Для такой задачи хорошо подойдет InterSystems Cache. Она позволяет работать с данными в трех режимах – объектном, реляционном и нереляционном (NoSQL), что позволяет избежать ненужной сложности в тех местах, где она не нужна и, в то же время, добиться максимальной производительности там, где это необходимо. Кроме того, есть встроенный модуль BI (DeepSee), который опять таки можно расширять вручную на критических по объемам и времени выборках.
У нас большой офис в Сиднее (я там как раз и работаю), с австралийскими сейлами и саппором. Если интересно, пиши на почту, организую для тебя встречу. Лучше, как говорится, лучше один раз увидеть =)
=Сергей Шутов,
InterSystems Sydney
Сергей:
запишу контакт на память, но думаю, что через preferred vendor list не смогу протащить. У меня товарищ – директор аналогичной фирмы Quantalytic, и у них та же проблема, когда каждый аккаунт надо с кровью выбивать.
Но кто знает, как получится. Задача пока неструктурирована, и я думаю, связываться ли.
OK, пиши если что. ISC все таки достаточно большая компания (1000 человек в 35 офисах), и имеет удачные примеры крупных внедрений как раз в интересующих тебя индустриях – финансах и телекоммуникациях (ну, правда, врать не буду, основной рынок – медицина), так что может и протащишь… Просто под такую задачу, я считаю, наши решения очень хорошо подойдут.
=Сергей
PS: В предыдущем комменте адрес электронки неправильно указал. Правильный – logist.ru собака gmail.com (был loigst.ru)
Разрабатывал CRM-систему на Intersystems Cache. Надо сказать сильно пожалел: ни с чем хуже в жизни сталкиваться не приходилось. На уровне глобалов особо не работал, но по SQL и объектному доступу система не впечатлила.
SQL очень слабый. Нет поддержки MVCC, с блокировками какая-то каша, из-за чего нормальные запросы, которые легко выполняются на других СУБД на Cache падают из-за конфликтов блокировок. Нормально поддерживается только изоляция транзакций READ UNCOMMITTED, READ COMMITTED заявлена но реально работает с такими ограничениями, что легче думать, что её нет, чем она есть. Другие уровни изоляции, ясное дело, даже не заявлены. Планировщик очень слаб, составляет тупые планы уже на довольно простых запросах, заставляя систему выполнять запрос несколько часов вместо нескольких секунд. В добавок запросы частенько падают с невменяемой ошибкой в недрах Cache, приходится, экспериментируя, находить вариант который работает. Ну и ещё куча косяков, которые долго можно перечислять.
Объектный доступ не понравился слабой функциональностью (например не встроенной поддержки отношения многое-ко-многому или нельзя извлечь объект кроме как по его id (а id получать либо через глобалы, либо через SQL)) и медленностью. В целом эта хваленая объектность показалась мне куда хуже, чем любая ORM, с которой доводилось пользоваться.
Когда Intersystems пишет о “равноправной и эффективной поддержке сразу трех способов работы с данными”, то, мягко говоря, лукавит, как и во многих других заявлениях. Целостность, например, не гарантируется. Если, например, объявить в хранимом классе индекс, и забыть переиндексировать таблицу, то будут выполняться кривые запросы, а следовательно кривые транзакции, которые будут портить данные. Так что целостность поддерживается исключительно усилиями тех, кто разрабатывает и эксплуатирует систему, а не самой СУБД. Да иудачные примеры внедрений, на мой взгляд, заслуга исключительно тех людей, которые внедряли, а никак не платформы.
И в целом во многих местах видна кривизна архитектуры, недоделки, и баги, баги, баги…
Например на вопрос о зависании менеджера задач, сотрудник поддержки Intersystems мне ответил, что разработчик, который этим занимается не способен его исправить, и проще мне будет написать то, что мне надо самому, чем ждать, пока Intersystems исправит его. Про DeepSee тот же сотрудник говорил, что это говно не работает вообще. И я ему верю )))))
Возможно при использовании глобалов напрямую и действительно есть какие-то преимущества в производительности, но я советую рассматрировать Intersystems Cache только когда все другие варианты будут отброшены.
Максим, добрый день.
Не совсем по теме. Относительно давно слегка изучил вопрос RFID меток, и уже тогда появилась идея использования их в супермаркетах, но не с аналитической точки зрения, а для упрощения процесса покупки. Если вы намерены лепить метку на каждый товар (несколько лет назад это упиралось в высокую стоимость метки и размер), то можете в каждую корзину вмонтировать ридер, чтобы человек сразу видел стоимость всего того, что лежит у него в корзине, что позволит ускорить процесс покупки, поднять лояльность к супермаркету и снизить очереди в кассу… Подумал, что может это будет вам интересно в текущем проекте.
Подобные вещи уже делаются. Берешь с полки товар, подносишь к ридеру и кладешь сразу в пакет. На кассе с тележки снимается общая сумма, сразу рассчитываешься и уходишь со своими пакетами. Получается быстро, к тому же никто не видит, что ты там купил.
Плюс еще существуют кассы самообслуживания (на них сам прогоняешь товары через ридер и рассчитываешься картой) и терминалы мгновенного подсчета стоимости покупок (в одном варианте товары выкладываются на ленту и проезжают через ридер, а в другом вообще тележка прокатывается через специальные ворота и все метки считываются сразу).
mysql на больших объемах будет проблемматичен. изменение структуры таблиц, добавление индексов (под новую выборку, например, ибо без индексов будет жопа) – это на больших объемах тяжело и долго.
плюс наверняка придется логически рубить данные на куски, шардингом заниматься.
если хочется держать всю вссе данные в памяти, то можно глянуть в сторону Mysql Cluster. Размазывается на множество узлов, выживает при падении части узлов. Достаточно стабилен сейчас, 7я версия уже не крашится у нас. Из минусов – хорошо очень работает с primary key, с остальным похуже. Сильно хуже делает Join – все вытягивает на api ноду вначале. Реализация с отдельным джойном по узлам еще только пишется.
Еще плюс – есть api для разных языков для работы с таблицами напрямую, без sql. И подобное сделали для Innodb – прямой доступ мимо sql, но сейчас не вспомню как проект называется.
На nosql можно глянуть в принципе… Да, учтите, “не все облака одинаково полезны”. Тот жу Mysql cluster чувствителен к задержкам между узлами.
Похожая система работает сейчас у меня в компании, систему написал самостоятельно, фреймворк помогали писать еще двое программистов, писалось все это примерно 4 месяца, харакретистики такие:
– два сервера, в каждом их них: 4-х процессора Xeon, 32Гб памяти, 320Гб диска
– LAMP (база данных PostgreSQL)
– система обрабатывает примерно 50млн записей в день
– каждая запись состоить из примерно 60 полей
– оба сервера дублируют друг друга, максимальная загрузка каждого из них 50%
– данные аггрегируются в 25 разннобразных отчетов с возможностью фильрации и сортировки по полям
– обработанные данные переодически архивируются и откладываются в бекап
– отчеты хранят аггрегированные данные за последние 4 года
– отчеты откликаются на запрос менее чем за 3 сек (зависит от фильтров)
– данные никогда не удаляются, при необходимости добавления нового отчета просто создается конфигурация для него и происходит пересчет по данным из бекапа, что конечно занимает некоторое время.
Вобщем сумма даже в $1млн кажется завышенной, хотя все конечно же зависит от спецификации. Если что обращайся, чем смогу помогу.
Какая-то ерунда, на лицо ведь тренд полного отказа от посещения супермаркетов в ближайшие 10-15 лет.
Всем участникам рынка будет выгодно иметь чёткую систему доставки продуктов надом с электронными заказами и оплатой.
Английский TESCO уже делает первые шаги в этом направлении:
http://www.guardian.co.uk/money/2010/oct/26/tesco-app-barcode-reader
За эти 10-15 лет владельцы супермаркетов еще успеют заработать много-много денег.
Только успеют ли стартапы, ориентирующиеся на гостей супермаркетов, откусить часть этих денег.
It is not scalable business in a long term. The ROI is red for this model!
в статье лишь говорится об упрощении заказа доставки, но никак о глобальном тренде. учитывая рост сетей – очень сомнительно, что тренд имеет место быть.
Имеет имеет, например в американском Минниаполисе овощи на великах уже развозят: http://www.veloveggies.com/
Если данных очень много и нужно быстро по ним делать выборку – я бы посмотрел в сторону Hadoop/MapReduce. Т.к., он старается располагать данные как можно ближе к вычислениям.
Кроме того, автоматически решается задача с бекапом данных (они автоматически реплицируются) и вводом нового железа и заменой старого.
Как минус, для Hadoop нужны специфические навыки в программировании и администрировании. Ну и, конечно, оптимально продумать принцип разбивки данных по узлам весьма непросто.
Еще можно попробовать использовать тупо MySQL c sharding, деля данные между шардами по клиент_ид. Тут будет все проще изначально, в первую очередь, в наемом персонала. Но потом добавяться неприятные задачки с расчетами для которых необходимы данные сразу с нескольких shards (похожие товары, customers who bought this also bought …), а также вводом в строй новых машин и удалением старых. Это придется делать вручную.
Максим, скажи, а что за устройства для считывания данных на полке?
есть описание как оно работает с товаром и как передаются данные?
Без понятия. Пример с ритейлом я привёл только для того, чтобы показать сложность задачи. Реальная задача жутко секретная 🙂
rfid scanner, встроенный в полку и rfid метки на каждом товаре