Несколько вопросов:
1. Что у вас используется для мониторинга и управления кластером?
2. Сколько суммарно используется оперативки на мастер-нодах без учёта реплик?
3. Какая у вас ширина индекса?
4. Как долго вставляется документ?
Спасибо за ответы!
Подскажите, пакетами какого размера вы заливали данные при тестировании в Solr и с какими параметрами коммитили?
Мы сейчас выбираем между Solr и Elastic. В защиту Солара хочу сказать, что тест на скорость поиска в статье совершенно нерепрезентативен, т.к. там коммитили после вставки каждого документа, а по-молчанию Solr после коммита перезапускает searchers и делает подогрев кеша, что само собой не быстрая операция сама по себе и плюс к этому пока не перезапустится searcher, поиск будет в ожидании чуда. Отсюда и тормоза.
В нашем дерби пока выигрывает Солр. В основном за своё умение делать сплит шардов и модифицировать update workflow с помощью плагинов.
Если начинать мыслить Вашими крайностями, то давайте предположим, что завтра случится война, отключат Интернет и отпадёт потребность в офисных крысах. И у меня вопрос: кто кому будет подавать хлеб? Вы со своими правильными взглядами на жизнь, или презренный Вам человек, объехавший весь мир и не знакомый со словом «невозможно»?
Долго искали? ))
Потому что у меня получилось, что в 9 альбомах только в последнем есть часть фото без хайреза.
Будем продолжать спорить или пора уже набросать скриптик спайдера, который нас рассудит? )))
Я отлично дружу с английским. И я смотрел коллекции с 11 и 12 миссии. На большее — времени пока нет.
Ещё раз прошу Вас, просто посмотрите фото. Они прекрасны. Особенно в разрешении 3900х3900. :)
Отсканировать 70мм плёнку с Хаселя и не показать исходники народу — это было бы слишком жестоко.
А так — есть отличный шанс распечатать себе плакат метр на метр с поверхностью Луны с орбиты.
Возможно, это вопрос не баланса белого, а качества современных фото-материалов. Плюс к этому, плёнке из Аполло уже 40 лет и имеет место вполне природное выгорание цвета.
Да я понимаю, для чего это придумано :)
У меня только есть подозрение, что большинство пользователей смартфонов мыслят по-человечески и им нафиг не надо распознавать ценники с вероятностью ошибки близкой к нулю чтобы сохранять данные в домашнюю бухгалтерию у себя в девайсе с автоматической категоризацией и раз в полгода делать data mining с целью выявить возможности уменьшения расходов.
Нормальным людям это просто не нужно :)
Практически — тоже. :) В начале 2000-ных мы в стенах веб-студии девелопили полнофункциональную CMS на С++. Скорость работы была феерической. Но вот с саппортом — реально проблема, ибо каждый проект это был по-сути отдельный форк со своими допилками.
И лично у меня был проект интернет-магазина для немцев с абсолютно безумными требованиям: C++, Windows, Apache+FastCGI, MSSQL. Тоже весьма шустро работало.
Отфильтровать — не проблема. Тут основное — это просчёт за один проход количества отелей, соответствующие каждому из сервисов. И таки да. Можно на С написать демона, который будет держать всю базу отелей с сервисами в памяти и делать обсчёт. :) Вопрос в целесообразности.
Да, отправная точка поиска — страна. И дальше поиск идёт по любой из характеристик отеля плюс поиск по ценовым предложениям с разнообразными критериями.
Можно узнать приблизительный размер шарда, структуру документов и индексов и сколько памяти кушает Монга под обработку 10М документов?
И ещё уточнение. Я так понимаю, в Монге вы храните некую статистику? Т.е. данные только вставляются и не обновляются?
Всё, что я читал/слышал об aggregation framework подтверждает это мнение. Но. Лично моё мнение, что они решают несколько разные задачи. Да, с помощью map-reduce можно решать задачи простейших группировок и конечно же он будет проигрывать инструментам, заточенным под эти задачи. Но когда речь идёт, скажем, о классической для map-reduce задаче анализа и классификации текстов, то тут уже в принципе не получится сравнивать map-reduce и aggregation, т.к. последний просто не справится с поставленной задачей. Т.е. сравнение изначально не совсем корректное. Под каждую задачу — свой инструмент.
Так и есть. В основной БД структура под хранение отелей насчитывает около 30 нормализованных таблиц. И конечно же есть ещё одно решение этой задачи, в котором строится темповая таблица с отелями после фильтрации и с помощью нескольких запросов с группировками можно получить тот же список сервисов с подсчётом количества отелей для построение фильтров. Но решение с Монгой показалось красивее и проще.
Иерархический map-reduce ИМХО хорош, когда нужна сложная аналитика по данным. В нашем случае — простейший подсчёт количества отелей в разрезе сервисов и других характеристик. Решается задача за один проход. Основной вопрос был в том, как именно мапить. При решении задачи в лоб, получалось слишком много значений на этапе маппинга. Оптимизированное решение упиралось в производительность интерпретатора JS в Монге. Как оказалось, серебряной пули не существует :)
Проект в разработке и поэтому ТТХ могу привести только сервера, на котором альфа развёрнута. Восьмиядерник, 24Гб оперативы и 2 ХДД в рэйде. Из которых Монга сейчас кушает что-то около 200Мб. Рабочих отелей до 5К. Тестировалось всё на 100К. Чистый RPS не замерял, так как считаю это сферическим конём в вакууме. Главный вопрос в том, сколько времени займёт полный цикл получения данных, на сколько активно при этом можно использовать кеш и какая алгоритмическая сложность решения, т.к. всё это добро придётся ещё не один год саппортить. По-факту, в данном случае резалтсет после фильтров по сервисам можно складывать в очень длинный кеш, т.к. данные по отелям редко меняются, а финальный резалтсет после фильтров по цене — в короткий кеш и миксовать их. Самое главное, что после всех этих махинаций страницы на разогретом кеше и с нагрузкой в 100 конкурентных соединений отдаются за 20-30мс и это полностью нас устраивает.
В перспективе будет 3-5 серверов с похожими конфигурациями, но по-большей части они будут использоваться для работы с ценовыми предложениями по отелям. Для начала — шардирование. По мере роста нагрузки будут докидываться слейвы.
1. Что у вас используется для мониторинга и управления кластером?
2. Сколько суммарно используется оперативки на мастер-нодах без учёта реплик?
3. Какая у вас ширина индекса?
4. Как долго вставляется документ?
Спасибо за ответы!
Мы сейчас выбираем между Solr и Elastic. В защиту Солара хочу сказать, что тест на скорость поиска в статье совершенно нерепрезентативен, т.к. там коммитили после вставки каждого документа, а по-молчанию Solr после коммита перезапускает searchers и делает подогрев кеша, что само собой не быстрая операция сама по себе и плюс к этому пока не перезапустится searcher, поиск будет в ожидании чуда. Отсюда и тормоза.
В нашем дерби пока выигрывает Солр. В основном за своё умение делать сплит шардов и модифицировать update workflow с помощью плагинов.
Потому что у меня получилось, что в 9 альбомах только в последнем есть часть фото без хайреза.
Будем продолжать спорить или пора уже набросать скриптик спайдера, который нас рассудит? )))
Ещё раз прошу Вас, просто посмотрите фото. Они прекрасны. Особенно в разрешении 3900х3900. :)
Отсканировать 70мм плёнку с Хаселя и не показать исходники народу — это было бы слишком жестоко.
А так — есть отличный шанс распечатать себе плакат метр на метр с поверхностью Луны с орбиты.
Мало того, что это просто круто. Так ещё и внизу каждого фото есть ссылочка «Hi Resolution Image(s):».
У меня только есть подозрение, что большинство пользователей смартфонов мыслят по-человечески и им нафиг не надо распознавать ценники с вероятностью ошибки близкой к нулю чтобы сохранять данные в домашнюю бухгалтерию у себя в девайсе с автоматической категоризацией и раз в полгода делать data mining с целью выявить возможности уменьшения расходов.
Нормальным людям это просто не нужно :)
И лично у меня был проект интернет-магазина для немцев с абсолютно безумными требованиям: C++, Windows, Apache+FastCGI, MSSQL. Тоже весьма шустро работало.
Островок — классный проект. Мы попроще :)
И ещё уточнение. Я так понимаю, в Монге вы храните некую статистику? Т.е. данные только вставляются и не обновляются?
Иерархический map-reduce ИМХО хорош, когда нужна сложная аналитика по данным. В нашем случае — простейший подсчёт количества отелей в разрезе сервисов и других характеристик. Решается задача за один проход. Основной вопрос был в том, как именно мапить. При решении задачи в лоб, получалось слишком много значений на этапе маппинга. Оптимизированное решение упиралось в производительность интерпретатора JS в Монге. Как оказалось, серебряной пули не существует :)
В перспективе будет 3-5 серверов с похожими конфигурациями, но по-большей части они будут использоваться для работы с ценовыми предложениями по отелям. Для начала — шардирование. По мере роста нагрузки будут докидываться слейвы.
Основная СУБД — MariaDb.