Уточню: в инсталляциях YDB у нас есть нечто похожее на "конкретный мастер", точнее это либо L3-балансер, либо DNS-балансер. Это (начальный endpoint) надо задавать явно. Поэтому первый запрос Discovery/ListEndpoints действительно "выясняет" конфигурацию кластера и дальше работает клиентская балансировка в SDK уже с конкретными нодами YDB. Или у вас умный клиент и он сам определяет куда подключится? Как будто бы умный клиент получается
Я бы даже рекомендовал посмотреть в сторону serverless YDB в Yandex.Cloud. Пока ваш магазин маленький - плата ничтожная. Если начнет лавинообразно расти нагрузка (например в случае успеха продвижения товаров/бренда/магазина) - произойдет автомасштабирование, соответственно пропорционально вырастут расходы на сервис. О железе/хостинге думать вообще не надо
Подскажите, а как осуществляется подтверждение доставки пакетов?
Никак в документации (по mavlink, PX4, Ardupilot, QGroundControl и пр.) не могу найти ответ на этот вопрос.
Пакет в сторону коптера выплевывает наземка, но где гарантия того, что пакет дошел, а не потерялся в процессе доставки (радиоволны испортились, помехи, сигнал слабый и т.п.). Если пакет не доставлен, то его надо повторить — замутить retry-логику. Нельзя же просто записать в serial port device байты и верить, что они дойдут до абонента…
С полгода назад что-то подобное было. Я использую docker-compose на одноплатниках. Настроены CPU и Memory Limits. Без kubernetes — режим работы IoT, offline. Хостовая ОС — Debian 9/10 с ядрами 4.9-4.19. На одной тачке решил опробовать Ubuntu 18.04 LTS с ядром 5.+
Так вот, на этой Ubuntu-тачке docker ps -a выводил что все процессы спят, либо рестартуются. Так глубоко (как автор статьи) я не копал, да и точно не помню как я дошел до того, чтобы убрать CPU quota в контейнерах — но это помогло. Несколько дней ушло на это развитие инженерной мысли.
Возможно, проблемы разные, но симптомы проблем похожие, да и решения тоже.
За прошедший период я разобрался с форматом метатайла (на основе мануала по renderd), сам его паковал. Сейчас я могу с уверенностью сказать, что метатайлинг исключает дедупликацию в принципе (о чем я отметил в исправленной версии данной статьи). Поэтому у меня в продакшине крутятся Redis'ы с пре-рендеренными дедуплицированными тайлами (152ГБ), а все остальное перенаправляется lua-скриптом к серверу динамической генерации тайлов: мой lua-скрипт + мой git-клон библиотеки mapnik-c-api + mapnik2.3. Безо всяких apache, mod_tile, renderd и пр. лишних на мой взгляд прослоек. Кэш метатайлов хранится в nginx'e в lua_shared_dict на 10ГБ, что позволяет писать в него и читать из нескольких worker'ов nginx'а. Он также опеспечивает очистку/перезапись данных по алгоритму LRU, что очень удобно, т.к. не нужно заботиться об очистке кэша от неиспользуемых данных.
В Китае, видимо, слабо заполнены карты. У меня platet-latest.osm.pbf в БД занимает 144ГБ. А pbf файл Китая занимает всего 209 Мб. Возможно, он был еще меньше на момент написания статьи.
Есть такие сервисы, которые выкачивают все подряд. Я писал такие когда-то. Например, в Google, в Яндекс и в Спутнике установлено ограничение по количеству запросов тайлов с одного клиента. Если этого ограничения нет, то рендеринг по запросу наплодит тайлов, в т.ч. и в океане. От этого никакой веб-ресурс не застрахован. Тот же Гугл и Яндекс стабильно «обкачивают» все доступные сайты, чтобы создать быстрые индексы для поиска. Это нормально. А кто-то будет выкачивать все тайлы.
Я отталкивался от инструментария, который уже применяется в продакшине у моего работодателя. Ничего не имею против CouchDB, но на поддержку еще одной СУБД мой работодатель не был готов. Зато Redis за год на бою показал себя исключительно положительно. И там тоже есть репликация из коробки.
Собственно, я в статье и не отвергал эту технологию. Но выходя за рамки статьи, Вам скажу, что хранение метатайлов в tilecache, с одной стороны решает проблемы маленьких файлов в блочных устройствах, с другой — дедупликация тайлов менее эффективна при объединении нескольких тайлов в метатайл. Да и дупликацию тайлов, наверное, как-то обошли. Можно, конечно, отгородиться от проблем дедупликации и блочных файловых систем убеждением, что в столь мощном и широко-используемом инструменте эти проблемы КАК-ТО решены. Но мне в продакшине еще один черный или серый ящик, честно говоря, не нужен. Вот и разбираюсь как это работает :)
Чтобы узнать точные доли, читайте мою статью :) А если серьезно, то меня поразил масштаб проблемы, о чем я и захотел поделиться с хабра-общественностью. Возможно, мои исследования как-то помогут будущим разработчикам оптимальнее строить свои WMS.
Лет 7 назад я работал с SQLite3 и неприятно для себя обнаружил, что эта субд поднимается из дампа и ПОЛНОСТЬЮ висит в ОЗУ (т.е. объем в памяти = размеру дампа), периодически сбрасывая данные обратно в дамп. Там не было как, например, в PostgreSQL в момент выполнения select обращения к файлам, а в памяти хранятся только индексы. Может я тогда плохо сконфигурировал, может тогда sqlite3 не умел не весь подниматься в память. Точно так же работает Redis. Только оперативки сейчас у меня много, да и no-sql субд работает всегда немного быстрее любых sql-субд за счет отсутствия необходимости поддержки sql синтаксиса.
Между прочим весьма распространенный формат карт mbtiles работает в СУБД sqlite3, которая, насколько мне известно, вся висит в памяти при работе. У них тоже пустая трата памяти? Память — это быстрый доступ к данным, а также возможность продлить ресурс жесткого диска, который явно будет служить меньше, если постоянно дергать файлы.
Это прекрасно, что предусмотрено. Но укажите хоть один ресурс, в котором говорится, что задублированы 60-70-80-90% тайлов? Неужели и это всем известно?
Вы правы. Но оставлю как есть в статье. Ибо суть в том, что в пуле хранятся только 2 соединения, если никак не настроить пул.
Вы правы, поправил
sqlc в планах ... на студентов ВУЗов. Они такие задачки любят.
В roadmap команды, к сожалению, sqlc не входит пока
К сожалению, нет. Для такого JOIN'а не следует использовать PRAGMA TablePathPrefix, а следует писать полный путь таблицы
Уточню: в инсталляциях YDB у нас есть нечто похожее на "конкретный мастер", точнее это либо L3-балансер, либо DNS-балансер. Это (начальный endpoint) надо задавать явно. Поэтому первый запрос Discovery/ListEndpoints действительно "выясняет" конфигурацию кластера и дальше работает клиентская балансировка в SDK уже с конкретными нодами YDB.
Или у вас умный клиент и он сам определяет куда подключится?Как будто бы умный клиент получается
Я бы даже рекомендовал посмотреть в сторону serverless YDB в Yandex.Cloud. Пока ваш магазин маленький - плата ничтожная. Если начнет лавинообразно расти нагрузка (например в случае успеха продвижения товаров/бренда/магазина) - произойдет автомасштабирование, соответственно пропорционально вырастут расходы на сервис. О железе/хостинге думать вообще не надо
Когда клиентский код передал trace с незаполненным OnPing может произойти паника
Никак в документации (по mavlink, PX4, Ardupilot, QGroundControl и пр.) не могу найти ответ на этот вопрос.
Пакет в сторону коптера выплевывает наземка, но где гарантия того, что пакет дошел, а не потерялся в процессе доставки (радиоволны испортились, помехи, сигнал слабый и т.п.). Если пакет не доставлен, то его надо повторить — замутить retry-логику. Нельзя же просто записать в serial port device байты и верить, что они дойдут до абонента…
Так вот, на этой Ubuntu-тачке docker ps -a выводил что все процессы спят, либо рестартуются. Так глубоко (как автор статьи) я не копал, да и точно не помню как я дошел до того, чтобы убрать CPU quota в контейнерах — но это помогло. Несколько дней ушло на это развитие инженерной мысли.
Возможно, проблемы разные, но симптомы проблем похожие, да и решения тоже.