Да, в результате будет получаться {"value": 0x1.edd2f20000000p+6} вместо {"value":123.456}. К несчастью, пока что все широко используемые в индустрии парсеры JSON с такими документами не справляются совсем. Кроме того, мне жаль глаза наших аналитиков и программистов. Я уверен, они постепенно справятся, но и им будет тяжело, и меня, возможно, жестоко изобьют.
Подавляющая масса наших float это вычисленные движком сигналы ранжирования на выходе движка во-первых, и некоторые вектора фичей для ML моделей (те, которые нельзя квантизовать получше) в исходных данных во-вторых. Две колонки {latitude, longitude}, разумеется, не волнуют вообще никого.
Да, детали public API я подзабыл, но сходные ощущения. Плюс есть еще более общий момент, что в погоне за компактностью и Ryu и другие библиотеки плюют на читаемость совсем. 123000? Ни в коем случае, даешь 123e3, ведь это на 1 байт короче. Такое...
так откуда у вас вообще возникла задача "печатать float"?
Две основных мотивации были:
Улучшить читаемость, заодно улучшить roundtrip. Накипело! Достали мусорные 0.000000 с одной стороны и это при некорректно roundtrip-ающих 123.456 с другой.
Ускорить внутренние большие выборки. Типично это какие-нибудь выгрузки сигналов ранжирования, или "просто" выгрузки документов.
Конечно же, в обслуживающих конечных пользователей OLTP запросах мы распечаткой в таких масштабах, чтобы printf стал заметен по производительности, не занимаемся.
А вот во внутренних выгрузках всякого для ML моделей эффект налицо. Как симпатичный пример, у нас в одном из мест форматированием занимается даже не сам Sphinx, а всунутая в него UDF. Скопировали и туда эту нашу реализацию, и некоторые нужные нам запросы ускорились кратно, вроде бы в диапазоне 2x-3x (точные цифры подзабыл).
Резюмируя, изначально хотелось повысить "качество" распечатки, приоритетом было именно это. Однако заодно удалось вот и подразогнать :)
Текущая ситуация вкратце — сижу вот в офисе Авито; пилим всякое в этот Сфинкс тут в составе группы лиц; не менее успешно его эксплуатируем; закапывать проект мы ни разу не собираемся; а вовсе даже и наоборот, есть некоторое громадьё технологических планов.
Вышло именно так ровно потому — что сколько-то серьёзный интерес к продолжению проекта проявила в нужный момент исключительно компания Авито, все остальные разговоры происходили практически буквально в стиле «срочно почини нам редкий спорадический баг неизвестной сложности в какой-то древней версии за гигантский бюджет в $200 на круг» или там например «сколько-сколько, целых $800 в мес за поддержку?! Не, это очень дорого для нашей маленькой компании на 1000+ человек» — и это, возможно, даже не самые угарные истории :)))
Поскольку пилим мы не только лишь один Сфинкс, а ещё и всю остальную инфраструктуру местного поиска, а толковых рук удаётся нанять не так много, как хотелось бы — то и получается не так быстро, как в Идеальном Мире хотелось бы. Плюс моё личное время на документацию, публичные релизы итп находится строго по остаточному принципу, увы; а каких-то ещё добровольцев помогать мне этим заниматься на данный момент нашлось отчего-то ровно 0 (ноль). Однако движемся явно вперед, ага. У нас тут вокруг всё интересно, и думаю, будет ещё интереснее :) что рано или поздно найдёт своё отражение и в релизах тоже, конечно.
Кто такие эти так называемые «простые смертные» и как их жизнь радикально поменяет наличие исходников, я не знаю.
А переходить, если хочется переходить, очевидно, что уже давно пора на Эластик. Собственно, см. первый же комментарий 4-летней давности :-) Нафига эти полумеры со странными форками сразу некоторым образом леворезьбовых (на данную минуту) проектов, бери текущий индустриальный стандарт.
Да меня в целом в текущей ситуации многое «смущает», в том числе и этот момент. Это не самая большая головная боль.
Увы, в моменте по ряду причин сейчас есть необходимость (или даже вообще обязанность) сделать именно вот так, все другие доступные варианты выглядят хуже.
Замечу ещё, что доступ к исходникам там, где можно и нужно, я тоже обеспечиваю и тоже уже сейчас.
Да у меня пока ещё нет желания тратить время на онлайн-драму и постить все пикантные и феерические подробности. Глобально-то история довольно банальная: начались разные проблемы, люди довольно некрасиво форкнулись, люди довольно некрасиво ушли, люди продолжают делать странные и некрасивые вещи, чем местами тупо мешают и проекту Сфинкс и лично мне.
Я лично пока таки предпочитаю разработкой Сфинкса заниматься, а не вынесением подобных дрязг в публичное пространство и прочим антипиаром. Надеюсь, уже совсем скоро публично покажу всякое интересное.
При этом погонять 3.0 можно прямо сейчас, нужно написать мне в почту и я выдам билд.
У нас явно разные понятия «красоты» — это не красивая в моём личном понимании — это скучный и тупой off-by-one классический.
Последнюю именно «красивую» ошибку даже и не вспомню навскидку. Первое и последнее, что моментально приходит в голову — в итоге оказалось вообще не в C++ коде совсем :)
отсутствие проверок на ошибочные данные было/стало скорее фичёй
Нет, это не совсем так.
Концепция всегда была (и есть) следующая:
Если можно "почти бесплатно" не падать на кривом входе, следует не падать.
Если это дорого, делаем утилиты для проверок (это и assert, и indextool, и т.д.), но сохраняем производительность.
Причём про "вход" тут речь вообще-то в первую очередь скорее о данных индекса, чем пользовательском вводе. Пользовательскому как раз веры почти (почти) никакой, проверяем его что есть сил, где не забываем. Одно хорошо: что не вебсервер, и редко голым поротом в интернет смотрим, типично хотя бы в VPN.
Заодно замечу, что единственный опубликованный тут "уникальный" пример "ошибки" вообще не про это. Там честное кажущееся разыменование NULL, никак не связано ни с какими оптимизациями. При этом, насколько я помню, фактически словить именно в этой точке NULL как бы невозможно, тк. а) наличие элемента в хеше проверяется ранее в функции, и б) по уставу с хешем в этот момент должен работать только текущий тред, вот ровно эта функция, внезапно стереть оттуда элемент некому. Но все эти предположения могли сломаться за годы мутации кода, конечно, и в идеале лучше подложить соломки, хотя бы и ассертом. Подложу, если этот код вообще останется в живых по итогам :-)
Сниппеты в целом с документами до 200 мб должны успешно работать. Ну и для ветки когда-уже-3.0 сделали Solr-style кеш токенов и хранилку документов, штоп умело только заранее проиндексированные документы подсвечивать, зато быстро и без похода в базу. Пишите почту, выдам preview доступ, если интересно.
Понятно. Есть пример в misc/suggest/ и собираемся когда-нибудь встроить автоматику в само двигло (начиная с определенного момента данных внутри индекса наконец хватает и это стало возможно).
Да, в результате будет получаться {"value": 0x1.edd2f20000000p+6} вместо {"value":123.456}. К несчастью, пока что все широко используемые в индустрии парсеры JSON с такими документами не справляются совсем. Кроме того, мне жаль глаза наших аналитиков и программистов. Я уверен, они постепенно справятся, но и им будет тяжело, и меня, возможно, жестоко изобьют.
Наглядный пример - геокоординаты.
Подавляющая масса наших float это вычисленные движком сигналы ранжирования на выходе движка во-первых, и некоторые вектора фичей для ML моделей (те, которые нельзя квантизовать получше) в исходных данных во-вторых. Две колонки {latitude, longitude}, разумеется, не волнуют вообще никого.
Да, детали public API я подзабыл, но сходные ощущения. Плюс есть еще более общий момент, что в погоне за компактностью и Ryu и другие библиотеки плюют на читаемость совсем. 123000? Ни в коем случае, даешь 123e3, ведь это на 1 байт короче. Такое...
Конечно. Так и лет прошло немало!
Две основных мотивации были:
Улучшить читаемость, заодно улучшить roundtrip. Накипело! Достали мусорные 0.000000 с одной стороны и это при некорректно roundtrip-ающих 123.456 с другой.
Ускорить внутренние большие выборки. Типично это какие-нибудь выгрузки сигналов ранжирования, или "просто" выгрузки документов.
Конечно же, в обслуживающих конечных пользователей OLTP запросах мы распечаткой в таких масштабах, чтобы printf стал заметен по производительности, не занимаемся.
А вот во внутренних выгрузках всякого для ML моделей эффект налицо. Как симпатичный пример, у нас в одном из мест форматированием занимается даже не сам Sphinx, а всунутая в него UDF. Скопировали и туда эту нашу реализацию, и некоторые нужные нам запросы ускорились кратно, вроде бы в диапазоне 2x-3x (точные цифры подзабыл).
Резюмируя, изначально хотелось повысить "качество" распечатки, приоритетом было именно это. Однако заодно удалось вот и подразогнать :)
Вышло именно так ровно потому — что сколько-то серьёзный интерес к продолжению проекта проявила в нужный момент исключительно компания Авито, все остальные разговоры происходили практически буквально в стиле «срочно почини нам редкий спорадический баг неизвестной сложности в какой-то древней версии за гигантский бюджет в $200 на круг» или там например «сколько-сколько, целых $800 в мес за поддержку?! Не, это очень дорого для нашей маленькой компании на 1000+ человек» — и это, возможно, даже не самые угарные истории :)))
Поскольку пилим мы не только лишь один Сфинкс, а ещё и всю остальную инфраструктуру местного поиска, а толковых рук удаётся нанять не так много, как хотелось бы — то и получается не так быстро, как в Идеальном Мире хотелось бы. Плюс моё личное время на документацию, публичные релизы итп находится строго по остаточному принципу, увы; а каких-то ещё добровольцев помогать мне этим заниматься на данный момент нашлось отчего-то ровно 0 (ноль). Однако движемся явно вперед, ага. У нас тут вокруг всё интересно, и думаю, будет ещё интереснее :) что рано или поздно найдёт своё отражение и в релизах тоже, конечно.
А переходить, если хочется переходить, очевидно, что уже давно пора на Эластик. Собственно, см. первый же комментарий 4-летней давности :-) Нафига эти полумеры со странными форками сразу некоторым образом леворезьбовых (на данную минуту) проектов, бери текущий индустриальный стандарт.
Увы, в моменте по ряду причин сейчас есть необходимость (или даже вообще обязанность) сделать именно вот так, все другие доступные варианты выглядят хуже.
Замечу ещё, что доступ к исходникам там, где можно и нужно, я тоже обеспечиваю и тоже уже сейчас.
Я лично пока таки предпочитаю разработкой Сфинкса заниматься, а не вынесением подобных дрязг в публичное пространство и прочим антипиаром. Надеюсь, уже совсем скоро публично покажу всякое интересное.
При этом погонять 3.0 можно прямо сейчас, нужно написать мне в почту и я выдам билд.
Последнюю именно «красивую» ошибку даже и не вспомню навскидку. Первое и последнее, что моментально приходит в голову — в итоге оказалось вообще не в C++ коде совсем :)
Нет, это не совсем так.
Концепция всегда была (и есть) следующая:
Причём про "вход" тут речь вообще-то в первую очередь скорее о данных индекса, чем пользовательском вводе. Пользовательскому как раз веры почти (почти) никакой, проверяем его что есть сил, где не забываем. Одно хорошо: что не вебсервер, и редко голым поротом в интернет смотрим, типично хотя бы в VPN.
Заодно замечу, что единственный опубликованный тут "уникальный" пример "ошибки" вообще не про это. Там честное кажущееся разыменование NULL, никак не связано ни с какими оптимизациями. При этом, насколько я помню, фактически словить именно в этой точке NULL как бы невозможно, тк. а) наличие элемента в хеше проверяется ранее в функции, и б) по уставу с хешем в этот момент должен работать только текущий тред, вот ровно эта функция, внезапно стереть оттуда элемент некому. Но все эти предположения могли сломаться за годы мутации кода, конечно, и в идеале лучше подложить соломки, хотя бы и ассертом. Подложу, если этот код вообще останется в живых по итогам :-)
А ряд других людей уже успешно гоняет 3.0 в проде и тестах ;)
Ветку 3.0 откроем, как только переделку формата доведем хотя бы до альфы.
Нету сроков. Конец в целом видно, конкретную дату не видно :(