Есть Intel DAAL, который наверняка используется в вашем питоне, если это anaconda. Так что вряд-ли получится что-то ускорить если написать SIMDов самому.
Видимо мало было читателей знакомых с CH, потому что не ответили что ClickHouse умеет читать данные из Kafka напрямую. Сам. Правда вопрос в формате записей, что вы там шлете, поддерживает ли его Clickhouse (хотя переложить данные из kafka в kafka сменив формат это всё же лучше чем из Kafka в Influx, но возможно я не понимаю что такое «прямо транзакционка»).
Ещё — InfluxDB (бесплатный) не масштабируется и не реплицируется (только если руками шардировать и слать данные в отдельные реплики, наличие kafka тут всё упрощает, но тем не менее), а ClickHouse умеет в Cross-DC репликацию и распределенные запросы из коробки.
По скорости и плотности хранения информации ClickHouse тоже выигрывает.
Там все вычисления уже на GPU, всё изначально векторизировано. Но как вариант для декодирования такого видео вполне можно приспособить habr.com/company/intel/blog/430492 :).
Переключил с локальных векторных карт на тайлы, посмотрел как оно. Действительно иногда подтормаживает (зумил туда-сюда районы Стокгольма, где сейчас нахожусь). Количество объектов на средних зумах стоит уменьшить — серая пиксельная каша из дорог не нужна, мелкие здания которые сливаются в пиксели — тоже. Девайс — Xiaomi Mi5, если это имеет значение.
Вот скрины для сравнения — yadi.sk/a/aB4VvOHz3ZX2rL. Обратите внимание на количество объектов на карте гугла.
У вас что-то не так. 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 полем, и набором не индексируемых полей данных, разным для разных документов, которые просто удобно сразу получать в результатах поиска.
> метрики — это в основном числовые значения. Почему вы их не индексируете? Они не так уж много места занимают.
Я не говорил что не индексирую метрики, просто отметил как отдельный случай в котором может быть допустимо выключить индекс.
Я про то что код на питоне внутри тоже может использовать низкоуровневые библиотеки с оптимизациями вплоть до SIMD :).
Есть Intel DAAL, который наверняка используется в вашем питоне, если это anaconda. Так что вряд-ли получится что-то ускорить если написать SIMDов самому.
Ещё — InfluxDB (бесплатный) не масштабируется и не реплицируется (только если руками шардировать и слать данные в отдельные реплики, наличие kafka тут всё упрощает, но тем не менее), а ClickHouse умеет в Cross-DC репликацию и распределенные запросы из коробки.
По скорости и плотности хранения информации ClickHouse тоже выигрывает.
Вот скрины для сравнения — yadi.sk/a/aB4VvOHz3ZX2rL. Обратите внимание на количество объектов на карте гугла.
Там же есть ссылки на munin с графиками, на 4-х render нодах в сумме средняя нагрузка 2-3k RPS (в зависимости от дня недели) — munin.openstreetmap.org/openstreetmap/render.openstreetmap/apache_accesses.html.
Тут можно посмотреть как система на одном из серверов это переживает — munin.openstreetmap.org/openstreetmap/orm.openstreetmap/index.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 полем, и набором не индексируемых полей данных, разным для разных документов, которые просто удобно сразу получать в результатах поиска.
> метрики — это в основном числовые значения. Почему вы их не индексируете? Они не так уж много места занимают.
Я не говорил что не индексирую метрики, просто отметил как отдельный случай в котором может быть допустимо выключить индекс.