Я ознакомился с Boost.PFR и вы правы, в том, что большая часть использований может быть им покрыта. Если мы говорим про POD/POCO типы.
Но, тот же linq2db активно пользуется атрибутивной разметкой и прочей метаинформацией, которая свзяна с полями и свойствами. Насколько я понимаю, такого сделать с помощью Boost.PFR нельзя и опять же, имхо, без поддержки со стороны языка невозможно. Можно придумать обходные варианты с fluent mapping или builders (и в новых версиях linq2db оно тоже доступно).
Также я посмотрел что Boost.PFR использует loophole, что принципиально снимает ограничение на использование типов из других сборок/DLL.
Но даже у вас в userver запросы пишутся вручную (я ознакомился бегло, рад буду ошибиться). Что является источником ошибок (привет sql injection), хотя, насколько я понял, вы стараетесь от этого защищаться.
LINQ и различные библиотеки (linq2db, EntityFramework) и другие снимают с меня как с программиста необходимость писать SQL запросы руками (при этом linq2db генерирует очень качественные запросы), готовя за меня prepared statements и передавая туда параметры (с проверкой типов на уровне С#). т. е. я принципиально не могу написать неправильный запрос и забыть передать в него параметры или передать не те.
Я за все время могу наверное вспомнить единицы запросов, котороые я бы написал.
При этом тот же linq2db позволяет расширять список функций, которые он может использовать при создании запросов или при обратном отображении — функции могут быть помечены специальными атрибутами и «выполняться» либо на серверной либо на клиентской стороне.
Судя по тому, что вы делаете в Boost.PFR и в целом куда движется язык аналогичную функциональность (с ограничениями) можно сделать и на С++, но выглядит это все очень дорого и нужны эксперты‑энтузиасты, вроде вас для этого. Тот же С# дает более простые инструменты.
Разговор же был не про то что можно сделать через std::function или обычный делегат в c#, а про то что для этого можно сгенерировать специализированный код в рантайме, который будет эффективнее списка предикатов.
На второй вопрос выше я попробую ответить позже - несколько последних лет я не пользуюсь c#.
Я наверное не понимаю вашего вопроса. Но все равно попробую ответить :)
Зачем создавать в рантайме - потому что в компайл-тайме всего выражения еще нет, например. В с++ есть аналог - это expression tree, но он ограничен статическими выражениями, но при этом позволяет создавать код, который нам нужен и как нам нужно . В c# позволяет сделать тоже самое, но не ограничивает вас только статическими выражениями.
А классы в рантайме для этого надо создавать, чтобы в сгенерированном коде не было дополнительных накладных расходов и он был создан только под конкретную задачу. Хороший пример производительного orm, который использует эту технологию - linq2db. Я бы посоветовал ознакомиться, но вы вряд ли будете этим заниматься :)
Более продвинутая структура t‑digest явно применяет k‑means кластеризацию для получения лучшего отношения размера к погрешности. Её реализация уже успешно применялась в Яндексе.
Применялась вообще в Яндексе или в YTsaurus? Планируется применяться вместо Q-digest? У вас своя реализация или от Facebook?
В оригинале " This means, that the regular expression ^aa(.+)cc(dd)\1$does match the sting aaHELLOccddHELLO, but does not match the sting aaHELLOccddGOODBYE "
Насколько я понимаю — вот есть один вариант — https://ned14.github.io/outcome, насколько я понимаю пока нативной поддержки в языке не будет — там все держится на программисте и обмазано макросами. Затащить это в проект я не решился, хотя пробовал LLFIO: Main Page, в котором оно используется.
Я уже упоминал ниже, но я бы к ваше списку добавил Database Internals (Распределенные Данные) Алексея Петрова. Там и обзорно и есть необходимые подробности и ссылки для дальнейшего изучения.
А чтобы ответить на этот вопрос, автор должен пойти немного дальше просто реализации B+ дерева (в которое он в примерах клал лишь строки) и построить реальный индекс по JSON структурам. А может и не один, если под поиском вы понимаете поиск по ключам JSON с учетом их вложенной структуры.
Ценность цикла статей о Boson - это пошаговый разбор алгоритмов и подходов реализации минимальной документальной СУБД с key/value хранилищем для тех кому интересно как это устроено - вот тут вы тоже немного лукавите, например, в этой статье нет никакого пошагового разбора алгоритмов. Есть ссылки на ваш код, базовое описание алгоритма, но пошагового разбора нет.
Более наглядные, на мой взгляд, иллюстрации есть в книге Database Internals (или, в русском переводе, Распределенные данные — там только вторая половина книги про распределенные СУБД, а первая про то как они устроены внутри) — главы вторая, четвертая и шестая. Ваша иллюстрация, тем кто не знает, что такое B+ дерево ничего особо не объясняет.
По поводу вашего вывода — реализация СУБД по описанному в начале тех заданию выполнима каждым, кто знаком с методами и алгоритмами описанными с цикле статей — то это очень смелое заявление. Сказать, что реализация документного хранилища возможна — да уместно, но не СУБД. Даже если оставить за скобками ACID, то надежность это неотъемлемое (опять же на мой взгляд) качество СУБД, потому что если последняя не дает гарантии получить из те же данные, которые ты ранее в ней сохранил то называть это системой управления базами данных некорректно.
Для тех кто хочет копнуть глубже - цикл статей от разработчика оптимизирующих компиляторов - Поговорим об оптимизирующих компиляторах. Сказ первый: SSA-форма / Хабр
Речь пойдет об одном из наших open source инструментов ― трекере ошибок Хоук.
Хорошо бы дать тогда ссылку на репозиторий, а не на сам трекер, тем более с отслеживанием переходов.
А только я один обращаю внимание на дату первого апреля или это известная всем не шутка?
Я ознакомился с Boost.PFR и вы правы, в том, что большая часть использований может быть им покрыта. Если мы говорим про POD/POCO типы.
Но, тот же linq2db активно пользуется атрибутивной разметкой и прочей метаинформацией, которая свзяна с полями и свойствами. Насколько я понимаю, такого сделать с помощью Boost.PFR нельзя и опять же, имхо, без поддержки со стороны языка невозможно. Можно придумать обходные варианты с fluent mapping или builders (и в новых версиях linq2db оно тоже доступно).
Также я посмотрел что Boost.PFR использует loophole, что принципиально снимает ограничение на использование типов из других сборок/DLL.
Но даже у вас в userver запросы пишутся вручную (я ознакомился бегло, рад буду ошибиться). Что является источником ошибок (привет sql injection), хотя, насколько я понял, вы стараетесь от этого защищаться.
LINQ и различные библиотеки (linq2db, EntityFramework) и другие снимают с меня как с программиста необходимость писать SQL запросы руками (при этом linq2db генерирует очень качественные запросы), готовя за меня prepared statements и передавая туда параметры (с проверкой типов на уровне С#). т. е. я принципиально не могу написать неправильный запрос и забыть передать в него параметры или передать не те.
Я за все время могу наверное вспомнить единицы запросов, котороые я бы написал.
При этом тот же linq2db позволяет расширять список функций, которые он может использовать при создании запросов или при обратном отображении — функции могут быть помечены специальными атрибутами и «выполняться» либо на серверной либо на клиентской стороне.
Судя по тому, что вы делаете в Boost.PFR и в целом куда движется язык аналогичную функциональность (с ограничениями) можно сделать и на С++, но выглядит это все очень дорого и нужны эксперты‑энтузиасты, вроде вас для этого. Тот же С# дает более простые инструменты.
Разговор же был не про то что можно сделать через std::function или обычный делегат в c#, а про то что для этого можно сгенерировать специализированный код в рантайме, который будет эффективнее списка предикатов.
На второй вопрос выше я попробую ответить позже - несколько последних лет я не пользуюсь c#.
Вместо того, чтобы неумно зубоскалить ознакомьтесь с linq2db, например.
Например, набор фильтров, которые пользователь создает через UI или предикаты бизнес-логики, которые мы загружаем из отдельной сборки.
Я наверное не понимаю вашего вопроса. Но все равно попробую ответить :)
Зачем создавать в рантайме - потому что в компайл-тайме всего выражения еще нет, например. В с++ есть аналог - это expression tree, но он ограничен статическими выражениями, но при этом позволяет создавать код, который нам нужен и как нам нужно . В c# позволяет сделать тоже самое, но не ограничивает вас только статическими выражениями.
А классы в рантайме для этого надо создавать, чтобы в сгенерированном коде не было дополнительных накладных расходов и он был создан только под конкретную задачу. Хороший пример производительного orm, который использует эту технологию - linq2db. Я бы посоветовал ознакомиться, но вы вряд ли будете этим заниматься :)
Прям не тяжело тяжело, но позволяет создавать эффективный код для linq запросов, оптимизированный под конкретное выражение - https://learn.microsoft.com/ru-ru/dotnet/csharp/linq/how-to-build-dynamic-queries
Есть хорошая ретроспектива - Дизайн и эволюция constexpr в C++ / Хабр
Спасибо за ответ!
Применялась вообще в Яндексе или в YTsaurus? Планируется применяться вместо Q-digest? У вас своя реализация или от Facebook?
В оригинале " This means, that the regular expression
^aa(.+)cc(dd)\1$does match the stingaaHELLOccddHELLO, but does not match the stingaaHELLOccddGOODBYE"Вы с переводом разговариваете.
У него там есть сравнение с ним, да.
Насколько я понимаю — вот есть один вариант — https://ned14.github.io/outcome, насколько я понимаю пока нативной поддержки в языке не будет — там все держится на программисте и обмазано макросами. Затащить это в проект я не решился, хотя пробовал LLFIO: Main Page, в котором оно используется.
Я уже упоминал ниже, но я бы к ваше списку добавил Database Internals (Распределенные Данные) Алексея Петрова. Там и обзорно и есть необходимые подробности и ссылки для дальнейшего изучения.
А чтобы ответить на этот вопрос, автор должен пойти немного дальше просто реализации B+ дерева (в которое он в примерах клал лишь строки) и построить реальный индекс по JSON структурам. А может и не один, если под поиском вы понимаете поиск по ключам JSON с учетом их вложенной структуры.
Ценность цикла статей о Boson - это пошаговый разбор алгоритмов и подходов реализации минимальной документальной СУБД с key/value хранилищем для тех кому интересно как это устроено - вот тут вы тоже немного лукавите, например, в этой статье нет никакого пошагового разбора алгоритмов. Есть ссылки на ваш код, базовое описание алгоритма, но пошагового разбора нет.
Более наглядные, на мой взгляд, иллюстрации есть в книге Database Internals (или, в русском переводе, Распределенные данные — там только вторая половина книги про распределенные СУБД, а первая про то как они устроены внутри) — главы вторая, четвертая и шестая. Ваша иллюстрация, тем кто не знает, что такое B+ дерево ничего особо не объясняет.
По поводу вашего вывода — реализация СУБД по описанному в начале тех заданию выполнима каждым, кто знаком с методами и алгоритмами описанными с цикле статей — то это очень смелое заявление. Сказать, что реализация документного хранилища возможна — да уместно, но не СУБД. Даже если оставить за скобками ACID, то надежность это неотъемлемое (опять же на мой взгляд) качество СУБД, потому что если последняя не дает гарантии получить из те же данные, которые ты ранее в ней сохранил то называть это системой управления базами данных некорректно.