Неизбежность нодокалипсиса

    Каждый объект в OpenStreetMap имеет уникальный номер. Базовый элемент карт — точка, из них состоит всё, и их очень много. 9 февраля идентификаторы точек превысили 2³¹−1: максимальное число, помещающееся в 32-битный int со знаком. О надвигающейся проблеме предупредили за полтора года, и все более-менее популярные программы успели перейти на long. Та суббота прошла без приключений.

    На самом деле, нет.

    Все знают, что через 25 лет метки времени тоже перестанут влезать в int, но никто не беспокоится: времени исправить более чем достаточно. Точно так же мы подумали про свои инструменты в мае 2011 года, когда Фредерик Рамм впервые поднял этот вопрос. Идентификаторы точек стремительно росли, и график как бы намекал. В osm2pgsql (главной программе для загрузки данных в PostgreSQL) ввели переключатель для 64-битного режима, затем начали обсуждать, нельзя ли как-нибудь перенумеровать узлы или обойтись unsigned int, оттуда разговор перешёл на необходимость отрицательных идентификаторов и сдулся.

    Сменился год, количество участников OpenStreetMap приближалось к миллиону, французы вовсю импортировали из кадастра контуры сараев о полусотне вершин каждый, немцы разрабатывали схемы тегирования для поребриков, канализационных люков и дорожной разметки. Среди мапперов распространились смартфоны и планшеты, и для них написали удобные редакторы. Исследования сообщали о неудержимом росте OSM и о поразительном качестве данных. Microsoft пополнял массив спутниковых снимков Bing, и тысячи энтузиастов дни напролёт их обклацывали. Подошёл декабрь 2012 года.

    «Ещё 62 миллиона точек — и ваши программы могут сломаться», — напомнил Фредерик, — «Я загрузил в SVN несколько файлов с большими идентификаторами, чтобы вам было проще проверить свои инструменты». Есть ли смысл предупреждать людей за пять дней до Нового года, через неделю после «апокалипсиса»? Не до того, участникам приятнее другие разговоры: о новом js-редакторе и рейтинге по количеству нарисованных домов.

    Наступил февраль, Пол Норман заметил в рассылке, что уже без пяти миллионов 2³¹. Пользователи добавляют примерно по миллиону точек в день — считайте сами. Дряхлая программа для подготовки шейпов береговых линий не переживёт этого потрясения, но ей есть замена. PHP-скрипты могут сломаться, поскольку 64-битные числа распознаются только на 64-битных ОС. Вроде, ничего серьёзного: вики-страничка со списком требуемых версий программ росла, но из заметного — только требование дополнительного ключа для популярного Osmosis, программы для фильтрации и преобразования данных OSM.

    Участники возбуждённо следили за обратным отсчётом, в другом окне загружая свеженарисованные домики и леса.

    Первым зрителей порадовал сайт отсчёта: конечно же, написанный на PHP и запущенный в 32 битах. Сапожник без сапог. Через несколько часов Тоби Мюррей захотел добавить на карту прокат машин, и редактор для андроида Vespucci вылетел. Затем японец запустил iOS-редактор POI+, чтобы отметить фаст-фуд в Нагое, но вместо создания новой точки тот воспользовался уже нарисованной с номером 2³¹−1, которая принадлежала контуру дома на юге Германии. Дом стал выглядеть примерно так:



    Затем появились озадаченные пользователи Osmosis. Не важно, что об обязательном ключе предупредили на форуме, в новостном блоге, в чатике, в рассылке и в вики. Снова и снова пришлось объяснять, что дописать в командную строку, — и на форуме, и в чатике. И в новостном блоге во второй раз. Помогло не сразу: поскольку Osmosis используется для региональных выгрузок, последние не обновлялись несколько дней. А вместе с ними застыли экспорт в навигаторы и валидация.

    Наконец, очередной дамп планеты удивил всех своим размером: вместо 26 гигабайт — 80 байт. Небольшой скрипт на С++ для подготовки самого важного в проекте файла хранил идентификаторы в поле типа int.

    Всю прошлую неделю сервисы понемногу выправлялись. Обработчик береговой линии починили, и попутно обновили саму линию (она обрабатывается отдельно от остальной карты, поскольку это один 300-мегабайтный мультиполигон; обновление запускают раз в пару месяцев). Выпустили новый Osmosis, куда помимо исправления бага вошёл новый мощный обработчик тегов. Авторы Vespucci и POI+ починили проблемы с идентификаторами почти сразу, но в мобильной среде всё непросто: Google Play и AppStore выложили исправленные версии лишь 16 февраля. Планету собрали, пусть и с третьего раза. Отсчёт перестал быть обратным.

    В отличие от истории с 25-летними cookies, «нодокалипсис» был предсказан, про него напомнили за два месяца и за несколько дней. Все описанные программы — с открытым исходным кодом, проверить тип переменной, в которой хранится номер точки, мог любой. Тем не менее, даже инструменты, которыми пользуются тысячи человек, были исправлены лишь когда полезли ошибки.

    Вывода два. Не игнорируйте предупреждения, в том числе свои. И, как месяц назад посоветовал блогер из PJ Online, если ровно через 25 лет семь утра вас застанет за рулём — сверните на обочину, постойте минут двадцать. Так, на всякий случай.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 40
    • +7
      Долго думал, к чему тут 25 лет, и почему именно 7 утра… Не у всех UTC+4 (^_-)
      • +13
        UTC+4, т.е. московское время: проблема наступит в 3:14 UTC (несложно запомнить, да) 19 января.
        • +8
          Pi — time.
          • +7
            Тут, скорее, это время запомнится благодаря другому слову, которое на ц заканчивается:)
          • НЛО прилетело и опубликовало эту надпись здесь
        • +16
          Пока гром не грянет мужик не перекрестится.
          • +1
            Ух, захватывающая история!
            • +1
              Главное, что с хэпиэндом :)
            • +22
              Автор, хороший слог. Интересно а что делать через 25 лет в 7 утра тем кто будет лететь в самолете? :)
              • +11
                4, 8, 15, 16, 23, 42… Нэ?
                • +1
                  К тому времени перейдут на 64-битные парашуты
                  • –1
                    Громко читать «Канон молебный ко Господу нашему Иисусу Христу и Пречистой Богородице при разлучении души от тела» наизусть.
                • +55
                  Планету собрали, пусть и с третьего раза.

                  Отличная фраза. :)
                  • +1
                    Звучит как дебаг 2645 года и проблемы с 128bit int.
                    • +1
                      Звучит как продолжение известной серии книг.
                      • +13
                        Вспомнился случайно замеченный комментарий в чейнджлоге Far Manager:
                        www.farmanager.com/svn/trunk/unicode_far/changelog

                        drkns 17.12.2010 18:58:27 +0200 — build 1762
                        1. Поступили слухи, что в диалоге атрибутов некорректно отображались пятизначные года.

                        Вот это забота о будущих поколениях, а не какая-то там ошибка 2000 или 2038 года, и даже не 2645. Особенно радует оптимизм авторов консольного файлового менеджера.
                    • +1
                      У меня тоже не всегда с первого раза собиралась.

                      emerge -vuDN world
                      • +1
                        И что вы этим хотите сказать?
                        • +5
                          Из хабры уже, я смотрю, давно, некоторые комментаторы, пытаются сделать 9fag.
                      • 0
                        Примерно так же республиканцы с демократами тянули до последнего вопрос договоренности по бюджету на фоне потенциального фискального обрыва. Проблемы парламентской неавторитарной среды.
                        • +1
                          А какой умник вообще додумался идентефикатор держать в int? По-моему, базовых знаний о базах должно хватать, чтобы понимать абсурдность таких действий.
                          • +6
                            Не судите строго, когда у вас 2^31 объектов, то на какие только оптимизации не идешь, чтобы сэкономить пару сотен Gb.
                            • +1
                              И на чем же? )))
                              Если рассматривать в «чистом» виде, то разница в 4 байта — это ровно 16 гиг экономии (на максимальных 2^32 рекордах). Экономить на строках надо.
                              Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!
                              • 0
                                Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!

                                Опасаюсь, что ваша память вам всё-таки изменяет.

                                Но вот зачем OSMу отрицательные идентификаторы, я и сам не понимаю.
                                • +2
                                  Отрицательными числами многие программы — например, редакторы, — нумеруют объекты, которых нет в базе OpenStreetMap. Новые или временные. При обработке существующих данных они едва ли нужны: так, роутинговые библиотеки везде используют unsigned int.
                              • 0
                                Соглашусь с первым комментатором — экономия на спичках. 32-битные системы — тоже не оправдание — для идентификатора не нужно сложной математики, вроде умножения или деления. Ну будет 8 тактов вместо 5 для сравнения для ARM.

                                Подозреваю — обычный быдлокод непродуманность архитектуры.
                                • +1
                                  Обработчики данных OSM стараются как можно больше загрузить в память. База сейчас приближается к половине терабайта. Поэтому те, кому это критично, экономят. Своп — не выход. Например, роутинговая библиотека OSRM хранит весь дорожный граф в памяти.

                                  Хотя в большинстве случаев, конечно, причиной простая безалаберность: редко в реальной жизни встречаются такие большие числа, забываешь.
                            • 0
                              Нод, который сломал планету
                              www.openstreetmap.org/browse/node/2147483648
                            • 0
                              Мда, ничему жизнь не учит… Спасибо за историю! И смех и грех, как говорится)
                              Сам использую OSM, поэтому для меня тема очень актуальна.
                              Только я что-то пропустил, последние добавленные точки похерили старые? В итоге все живы?
                              • 0
                                Интересно, а какой процент всех этих данных составляет мусор: неточные, устаревшие и просто бесполезные (в стиле «гараж Васька») данные?
                                • 0
                                  Если Васёк нарисовал свой гараж значит не так уж это и бесполезно. Неточности уточняются, устаревшие удаляются. А идентификаторы инкрементируются только вперед. Карма наверное.
                                  • 0
                                    А что делать с неоправданной детализацией, создающей на карте кашу? Я, например, давно имею зуб на автора вот этих паутинных разрывов в полигонах, обозначающих, видимо, муравьиные тропы: osm.org/go/0zPIkCLAK-
                                    • 0
                                      Как обычно в таких случаях — связаться и обсудить. Показать как надо. Чутка надавить, потребовать треки в конце концов. Думаю компромисс будет найден.
                                • +1
                                  А ещё люди полагаются на «уникальность» всяких там GUID, MD5, SHA1 и прочих. Вероятность совпадения посчитать-то просто, но мало кто думает, что будет, если это всё-таки случится в какой-нибудь системе, к каким электронным «взрывам» это приведёт.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.