У вас что-то не так. 1 млн тайлов в день — это усредненно 12 RPS, ну пусть будет 30 если считать что пик трафика продолжается 8 часов, а не равномерно размазан по суткам. На 8 ядрах получается по 4 RPS на ядро, звучит вполне нормально… Вообще если без нагрузки оно тоже тратит по 5 секунд на рендеринг одного тайла, при использовании SSD, то явно где-то не хватает какой-то фильтрации объектов, или индексов для их выборки, или просто какой-то компонент в стеке хреново выбран.
Btw, выше по треду предложили ограничиться Европой, это сильно снижает требования по объему дисков.
1. Не получилось совсем от манипуляций с DOM избавиться чтобы выкинуть phantom и взять чистый nodejs? Вот у Игоря тикет про это — https://github.com/zhukov/webogram/issues/124, кажется он был бы очень даже за если бы ему помогли.
2. А реализаций mtproto на Ruby нет? Вот есть https://github.com/platphorm/telegram_rb, правда выглядит сыровато, да. Пробовали её?
3. Зачем вообще нужна функциональность отправки сообщений по mtproto? Кажется через бота все задачи нормально решаются.
> Elasticsearch
> И ещё мы столкнулись со странной особенностью: чем больше шардов в индексе, тем медленнее он работает на запись (хотя здравый смысл подсказывает, что должно быть наоборот).
Есть такое. Лечится группировкой данных в bulk запросах по шардам. То есть в одном bulk запросе все документы должны отправляться в один шард. Этого поидее должно быть достаточно, чтобы избавиться от горлышка на синхронизации запросов в шардах. Но в идеале — смотрим в исходниках elasticsearch алгоритм вычисления номера шарда по routing (https://gist.github.com/ei-grad/c6794b151f6df49b6b6d94befff877e6), получаем через allocation explain API на какой ноде сейчас находится primary-реплика этого шарда, и шлём этот bulk запрос напрямую в неё, а не через Client-ноду (и уж тем более не через произвольную data-ноду).
У меня при такой схеме количество шардов влияет на скорость индексации линейно (на самом деле нет, я просто стал в питонячий клиент упираться на подготовке данных :(, увеличивать число шардов дальше не хочется, и так уже по 10 шардов на 4-ядерную ноду с учетом реплик, а текущих 100к записей в секунду, до которых успевает разогнаться импорт на получасовых батчах вполне хватает).
А, ещё про Apollo забыл, который емнип забросили в пользу Artemis.
Вообще на самом деле сравнивать особо нечего — ActiveMQ медленный из за синхронной архитектуры (они вроде скрещиваются с Artemis чтобы это побороть, но кажется что там в ближайшие N лет вряд ли будет что-то production-ready, проще HornetQ взять, хотя могу ошибаться), Qpid юзабелен скорее как набор библиотек а не готовый брокер. Остается мейнстрим — RabbitMQ, и кажется что других вариантов с AMQP нет.
Высокоуровневые сокеты не совсем верное название, более правильное — набор примитив для передачи сообщений. Нужна гарантированная доставка — реализуй на этих примитивах свой протокол, this is how it works. Btw, в обычном AMQP 0.9 даже подтверждений доставки нет. У RabbitMQ свое расширение — https://www.rabbitmq.com/confirms.html.
Да, с такими сценариями проще отдельную программу написать, которая с вложенными данными будет разбираться. Но ведь это не специфично для Protobuf, как в случае того же JSON'а поступать?..
В документации описан тип данных Nested, будет ли работать вставка данных, если структура таблицы с Nested-полями и во входящем JSON совпадает? Или на вход поддерживается только JSON с плоской структурой?
> а некоторые поля — это данные, которые нужно получить в довесок
Кажется в случае elasticsearch таких полей обычно не много. А изначально мое замечание было про отключение индексации для всех полей. Хотя сейчас я уже понял что это вполне нормальная ситуация для стандартного сценария использования ES для full-text поиска — с одним analyzed полем, и набором не индексируемых полей данных, разным для разных документов, которые просто удобно сразу получать в результатах поиска.
> метрики — это в основном числовые значения. Почему вы их не индексируете? Они не так уж много места занимают.
Я не говорил что не индексирую метрики, просто отметил как отдельный случай в котором может быть допустимо выключить индекс.
> монга хороша для очень быстрого доступа к данным (в том числе холодным), в этом плане она сильно выигрывает у эластика
> Основное, в чем эластик менее эффективен относительно монги — это объем хранимых данных и объем индексов
Я собственно это и имею ввиду. Опыт — построение сложных отчетов, когда агрегаций ES не достаточно и приходится выгружать миллионы документов в Python. Иногда эффективнее в hadoop'е по сырым сжатым данным пройтись, чем из эластика их достать. Выгрузка данных в JSON по HTTP из эластика сильно проигрывает выгрузке BSON по бинарному протоколу монги.
В текущем кейсе у меня таких выборок не много, ES — нормально, он в основном для агрегаций используется. Хотя иногда приходится выгрузки делать, и это боль. А на прошлом месте работы был вполне успешный опыт подобных выгрузок с монгой.
> взвешивая профит работы с данными, по большинству критериев выигрывает эластик
Согласен, в нашем кейсе для аналитики ES тоже лучше монги :-).
Но если данные не индексировать, то зачем их хранить в ES?.. Выборки по ним делать нельзя. Если для того чтобы просто доставать — лучше монгу взять.
Отдельный вопрос — поля метрик. Не знаю, влияет ли отключение их индексирования на производительность аггрегаций по ним? Какие-то агрегаты для индексов насчитываются, что будет если для метрик выключить индексирование? Да и иногда по метрикам тоже выборки хочется делать.
У вас в документации есть кусок про YT, может лучше убрать, чтоб не смущать общественность? https://clickhouse.yandex/reference_ru.html#Возможные глупые вопросы
Оказывается не совсем правда уже, но в любом случае вот правильный линк который необходимо прочитать при возникновении желания поделать JOIN'ы в ES — https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html.
Если говорить про удобные и эффективные форматы, то у Druid'а есть WOW-фича — указываешь ему класс со структурой Protobuf, и он читает данные через неё. Сложно ли будет вкрутить подобную функциональность в clickhouse-client?
С помощью dynamic templates можно отключить индексацию для всех не заданных полей или по шаблону — https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-templates.html.
Но какой смысл в эластике, если не индексировать поля? Как хранилище он не эффективен, проще монгу взять.
Было бы интересно почему ты пришел к выводу, что я быдло, но не вижу смысла продолжать дискуссию, потому что ты ещё в предыдущих сообщениях успел доказать то что твое слово ничего не стоит, а мнение подкрепляется личными эмоциональными фантазиями.
Btw, выше по треду предложили ограничиться Европой, это сильно снижает требования по объему дисков.
2. А реализаций mtproto на Ruby нет? Вот есть https://github.com/platphorm/telegram_rb, правда выглядит сыровато, да. Пробовали её?
3. Зачем вообще нужна функциональность отправки сообщений по mtproto? Кажется через бота все задачи нормально решаются.
> И ещё мы столкнулись со странной особенностью: чем больше шардов в индексе, тем медленнее он работает на запись (хотя здравый смысл подсказывает, что должно быть наоборот).
Есть такое. Лечится группировкой данных в bulk запросах по шардам. То есть в одном bulk запросе все документы должны отправляться в один шард. Этого поидее должно быть достаточно, чтобы избавиться от горлышка на синхронизации запросов в шардах. Но в идеале — смотрим в исходниках elasticsearch алгоритм вычисления номера шарда по routing (https://gist.github.com/ei-grad/c6794b151f6df49b6b6d94befff877e6), получаем через allocation explain API на какой ноде сейчас находится primary-реплика этого шарда, и шлём этот bulk запрос напрямую в неё, а не через Client-ноду (и уж тем более не через произвольную data-ноду).
У меня при такой схеме количество шардов влияет на скорость индексации линейно (на самом деле нет, я просто стал в питонячий клиент упираться на подготовке данных :(, увеличивать число шардов дальше не хочется, и так уже по 10 шардов на 4-ядерную ноду с учетом реплик, а текущих 100к записей в секунду, до которых успевает разогнаться импорт на получасовых батчах вполне хватает).
Ок) ¯\_(ツ)_/¯
Вообще на самом деле сравнивать особо нечего — ActiveMQ медленный из за синхронной архитектуры (они вроде скрещиваются с Artemis чтобы это побороть, но кажется что там в ближайшие N лет вряд ли будет что-то production-ready, проще HornetQ взять, хотя могу ошибаться), Qpid юзабелен скорее как набор библиотек а не готовый брокер. Остается мейнстрим — RabbitMQ, и кажется что других вариантов с AMQP нет.
Если интересны альтернативы — http://queues.io/.
В документации описан тип данных Nested, будет ли работать вставка данных, если структура таблицы с Nested-полями и во входящем JSON совпадает? Или на вход поддерживается только JSON с плоской структурой?
Кажется в случае elasticsearch таких полей обычно не много. А изначально мое замечание было про отключение индексации для всех полей. Хотя сейчас я уже понял что это вполне нормальная ситуация для стандартного сценария использования ES для full-text поиска — с одним analyzed полем, и набором не индексируемых полей данных, разным для разных документов, которые просто удобно сразу получать в результатах поиска.
> метрики — это в основном числовые значения. Почему вы их не индексируете? Они не так уж много места занимают.
Я не говорил что не индексирую метрики, просто отметил как отдельный случай в котором может быть допустимо выключить индекс.
> Основное, в чем эластик менее эффективен относительно монги — это объем хранимых данных и объем индексов
Я собственно это и имею ввиду. Опыт — построение сложных отчетов, когда агрегаций ES не достаточно и приходится выгружать миллионы документов в Python. Иногда эффективнее в hadoop'е по сырым сжатым данным пройтись, чем из эластика их достать. Выгрузка данных в JSON по HTTP из эластика сильно проигрывает выгрузке BSON по бинарному протоколу монги.
В текущем кейсе у меня таких выборок не много, ES — нормально, он в основном для агрегаций используется. Хотя иногда приходится выгрузки делать, и это боль. А на прошлом месте работы был вполне успешный опыт подобных выгрузок с монгой.
> взвешивая профит работы с данными, по большинству критериев выигрывает эластик
Согласен, в нашем кейсе для аналитики ES тоже лучше монги :-).
Но если данные не индексировать, то зачем их хранить в ES?.. Выборки по ним делать нельзя. Если для того чтобы просто доставать — лучше монгу взять.
Отдельный вопрос — поля метрик. Не знаю, влияет ли отключение их индексирования на производительность аггрегаций по ним? Какие-то агрегаты для индексов насчитываются, что будет если для метрик выключить индексирование? Да и иногда по метрикам тоже выборки хочется делать.
Оказывается не совсем правда уже, но в любом случае вот правильный линк который необходимо прочитать при возникновении желания поделать JOIN'ы в ES — https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html.
Но какой смысл в эластике, если не индексировать поля? Как хранилище он не эффективен, проще монгу взять.
Будут ли пакеты для xenial?