>> Возможно, потому что никто не сделал эффективный способ, потому что никто не просил
у druid в общем случае это обычный отсортированный словарь ключей, по ключу находят строку в bitmap и дальше бегут по ней находя нужные rowid (условно конечно). когда у нас имеется несколько значений в IN, то нельзя просто сканировать один ряд, нужно пачку сразу и результаты результаты клеить.
дальше учитываем что основной протокол общения это rest/json, соответсвенно и передать большой кусок сложно само по себе.
кстати уже ловил проблему, когда несколько historical возвращают большие ответы и 90% времени запроса проводим в broker занимаясь «распарсили ответ от historical — merge результатов — генерация json клиенту»
p.s. это не наезд, из opensource для некоторых задач, особенно в условиях когда нужна доступность и возможность гибко расширять кластер, druid подходит хорошо и в новом проекте собираюсь опять его использовать
нет, там даже большой массив на вхождение будет неплохо снижать производительность. поэтому обычно все укладывается в бакеты (1: 1-10, 2: 11-20 и тд)
отдельно стоит уточнить, что все ключи для dimension когда bitmap строят в string переводят, поэтому использовать float/double как измерение очень не советую (много место сожрет на хранение, а выборку по диапазону все равно не получите)
В общем для некоторых вещей в лоб он очень неплох, особенно с учетом гибкого масштабирования, но вот модель «как и зачем хранить» как и с любым nosql нужно продумывать досконально
нет, в примере в статье говориться «использовать ids из вот этого файла»
lookup в druid это «я хочу чтобы ты вместо id вернул мне строковое значение из этого словаря» и происходит на этапе уже возврата данных клиенту
Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except faster.
так что разработчики не согласны с вами, что это «формат хранения данных, а не передачи».
смотрели в свое время, но если брать список по топику:
те же c++, те же зависимости бинарного кодогенератора по схеме от os где запускаешь
честное признание на их же сайте: Currently it only beats Protobufs in realistic-ish end-to-end benchmarks by around 2x-5x. We can do better. То есть ни о какой разнице на порядки разговор не идет. К тому же учитывая следующий абзац сравнение было на c++ версии, что происходит в java неизвестно
для java нету оффициального сериализатора, а сторонний заброшен с февраля (Cap’n Proto’s reference implementation is in C++. Implementations in other languages are maintained by respective authors and have not been reviewed by me)
как результат: взять такой продукт в продакшен вместо протестированного protobuf лично я не решусь никогда
0. да, можно указать, но он по умолчанию из окружения вытягивается, а в окружение почти все знакомые ставят apt-get/yum/port install protobuf-java
Я пока не видел людей которые считают protobuf серебрянной пулей =) чаще встречаю которые считают, что json это верх совершенства и пихают его везде, а потом ловят несогласованность форматов в рантайме. В свое время лично для меня proto решил много проблем, так как позволяет высунуть контракт протокола на сервисы и гарантировать его соблюдения.
Со строками чаще проблемы не в том что копируются туда-сюда, а в самом кодировании-декодировании в UTF8, так как в java локальное представление Unicode, вот тут CPU и проседает частенько =(
0. https://www.xolstice.org/protobuf-maven-plugin/ уже давно все есть
1. начиная с protobuf v3 одной командой в протофайле option java_multiple_files = true; отключаем генерацию большого файла, получаем набор class=>file. Править полученные протофайлы вам не запрещается, при большом желании можно расширить компилятор и он будет генерить то что вам нужно и прописывать интерфейсы какие хотите
2. как вы предлагаете изменять byte[] в котором по определенным смещениям лежат значения изменяемой длинны? (ваш же пункт 4, чтобы что-то поменять нам нужно будет хвостик сдвинуть влево-вправо и изменить размер самого массива) Если объект в системе вроде как и готов, но возможно еще будет меняться, то перекидывается ссылка на билдер, а вот если нужно отправить в wire клиенту, то тут уже и build() вызывается и получаем готовый слепок.
3. сами же и сказали решение проблемы, dto не должно думать как упаковать граф, а потом его распаковывать, или может JSON уже научился такое делать? с учетом того что proto v3 еще ближе приблизился к json, то упаковка графа в руках того кто упаковывает, а совсем не стандартная операция.
4. [PROTOBUF+ZIP] vs [JSON+GZIP] это спор на уровне: у нас есть SQL и у нас есть NoSQL, в одном схема прописана и если говно пришло то оно сразу отбросится, во втором мы что-то как-то запишем-прочитаем. И далеко не у всех текста гоняются, зачастую только ID нужных элементов. К тому же сами признали увеличенную нагрузку на CPU, что для мобильных приложений очень критично. Хотите еще быстрее, с меньшей нагрузкой на CPU и без схемы, то добро пожаловать в MessagePack, только потом не жалуйтесь, что клиенты прислали очередную кашу.
В общем у вас пожелания: я хочу бинарный формат, который работает быстро, является компактным, сохраняет и проверяет схему, сохраняет ссылочность, позволяет без копирования изменять поля прямо в byte[] и т.д.
Лично я не знаю таких форматов и вижу противоречия в требованиях: компактный vs изменения сразу упакованного массива, компактный-быстрый vs сохраняем целиком ссылки-граф.
все зависит от потребностей, если нету какого-то специфического софта завязанного на windows, то проблем с OC нету
linux-mac консоль и окружение пересекаются почти полностью, за исключением мелких моментов
Так что для девелоперов если брать по возможностям окружения, то для меня в порядке убывания это linux/macos/windows(тут обычно у меня только боль)
если брать полностью все окружение и возможности, то macos более вылизанная и гладкая, меньше телодвижений, чтобы что-то настроить, так как зачастую это не нужно.
что не нравится в windows: поддержку 4к мониторов нормально запилили только в 10ке, до этого разный dpi на ноуте и мониторе нельзя было проставить, в маке с момента появления ретин это возможно и работает отлично
что не нравится в macbook pro (именно железо): 16гб памяти это лимит и обновить нельзя, так как распаяна, а больше даже в новых нельзя купить, мне как девелоперу периодически не хватает…
по железу и батареи если начинать смотреть похожие конфигурации, то по ценнику что маки, что аналоги стоят сопоставимых денег
но по порядку:
1) там было написано МИНИМАЛЬНОЕ что нужно сделать, но до нормального бенчмарка код все равно недотягивает
2) java 490ms, python 330ms
но раз вы уже пошли до «сложных регулярных выражений» со ссылкой на вашу методику, то и тестируйте её, чего сразу и не прогнать конечный регексп написанный вами же?
у меня получилось:
java 855ms и python 750ms
и если сразу не было 2 раза, разрыв не то что в процентных числах, в абсолютных начал уменьшаться при росте общего времени выполнения
пытаетесь доказать, что питон быстрее? так это не питон, а си в данном случае быстрее, причем в треде с этим никто не спорит
вот только java реализация написана на java
python реализация на сях и полный список веселья тут,
а уж если вам так сильно необходимы быстрые регулярные выражений, то возьмите jregex, эта «нехорошая библиотека» на первом regexp выдает 130ms и на втором сложном 290ms, что оставляет глубоко в оппе как стандартную реализацию java, так и python
итого мы доказали: стандартная обертка питона быстрее стандартных реализаций java (разница от 15% до 50%), и в более чем 2 раза медленней оптимизированной java реализации
вывод: нужны быстрые регекспы, берешь не питон/java/js/непонятночто, а нормальную либу
потом можно продолжить поисковым движком elasticsearch (напомните мне схожий по возможностям продукт не на java, вроде sphinx что-то умеет, правда количество упоминаний и инсталяций в разы меньше)
дальше продолжаем быстрой распределенной очередью, чтобы заменить kafka (zeromq это конструктор, а не готовая распределенная персистентная очередь)
так как нам нужно распределенно считать, то следом в очередь spark, storm (даже у последователя heronосновной объем кода это java), gearpump
можно еще упомянуть hbase (бедные Airbnb и Xiaomi не знаю, что нельзя его было использовать) или его сородича accumulo (писалась по заказу АНБ с требованием жестких ACL вплоть до отдельной ячейки)
а вот тут и начинается веселье под названием безопасная публикация объектов. Также как и в плюсах: либо используешь безопасные примитивы, либо сам думаешь где у тебя есть барьеры, а где нету, а если не думая перекинул линку, то можешь вычитать или нули или частично сконструированный объект, единственная гарантия «нельзя прочитать мусор оставленный предыдущим объектом»
на этого говорят что «меряют сферического коня в вакууме и в дополнение неправильно»
но большинству достаточно цифр из желтых газет чтобы начать истерить
1) делать замеры производительности на ideon само по себе глупо
2) в примере java происходит измерение в одном интервале «медленного режима интерпретатора» и «быстрого скомпилированного», общее число 500мс совсем не говорит о том какого режима было больше, а напоминает известный анекдот
вот пример с моей стороны pastebin
он еще содержит туеву хучу потенциальных ошибок измерения в разделе вырезания кода эскейп анализом, но все-таки чуть лучше чем было сразу
итого на моей системе получаем устоявшуюся скорость:
1) nodejs 100ms
2) java 200ms
3) python 400ms
зря @rossws сразу не привел примеры его java кода сразу, было бы меньше вопросов про прогрев и итерации
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен» sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ ) rdd — забили на развитие, используйте dataframe dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
вот возьмите Фрунзенский район =) еще то веселье, даже в ванне запах хлорочки летом может стоять, про чай из этой воды я вообще молчу. Пока жил в Партизанском районе меня все и из под крана устраивало, а после переезда сразу начал покупать бутилированную, потом поставил фильтр с обратным осмосом.
а теперь главные вопросы которые почему-то остаются за кадром:
1. sharding — у вас он ручной,
1.1 что делать если клиенты в разных шардах растут с разной скоростью и у нас на одном шарде 100млн, а на другом 1млн записей?
1.2 как делать перебалансировку в случае если нам нужно добавить +1 сервер в кластер
2. fault tolerance
2.1 мультимастер еще нужно уметь настраивать, в master-slave при выпадении master тоже веселье
если у вас 1 мастер и пачка слейвов, так как нагрузка на запись минимальная, почти все это чтение, то вам конечно повезло,
но ведь nosql любят в первую очередь за то, что у вас ключи разбиты по бакетам которых заметно больше чем серверов и эти бакеты свободно мигрируют между узлами (решаем задачу 1 с балансировкой и добавлением новых узлов), а выпавшего мастера автоматически подхватывает кто-то другой (в hbase и mongodb на основе кворума, у cassandra вообще мастера нету) (решаем задачу сложности конфигурации для задачи 2).
правда если уж начали про mysql в качестве nosql, то я бы ожидал услышать про handlersocket, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных
это пилили уже пол года назад =) все еще пилят
>> Возможно, потому что никто не сделал эффективный способ, потому что никто не просил
у druid в общем случае это обычный отсортированный словарь ключей, по ключу находят строку в bitmap и дальше бегут по ней находя нужные rowid (условно конечно). когда у нас имеется несколько значений в IN, то нельзя просто сканировать один ряд, нужно пачку сразу и результаты результаты клеить.
дальше учитываем что основной протокол общения это rest/json, соответсвенно и передать большой кусок сложно само по себе.
кстати уже ловил проблему, когда несколько historical возвращают большие ответы и 90% времени запроса проводим в broker занимаясь «распарсили ответ от historical — merge результатов — генерация json клиенту»
p.s. это не наезд, из opensource для некоторых задач, особенно в условиях когда нужна доступность и возможность гибко расширять кластер, druid подходит хорошо и в новом проекте собираюсь опять его использовать
отдельно стоит уточнить, что все ключи для dimension когда bitmap строят в string переводят, поэтому использовать float/double как измерение очень не советую (много место сожрет на хранение, а выборку по диапазону все равно не получите)
В общем для некоторых вещей в лоб он очень неплох, особенно с учетом гибкого масштабирования, но вот модель «как и зачем хранить» как и с любым nosql нужно продумывать досконально
lookup в druid это «я хочу чтобы ты вместо id вернул мне строковое значение из этого словаря» и происходит на этапе уже возврата данных клиенту
С druid масштабирование понятно (докинули серверов в кластер, достаточно указать zookeeper-hadoop, там открылись сегменты новых-ребаланс старых)
С ClickHouse на этапе знакомства я не нашел как по быстрому можно расширить кластер.
Как вы собираетесь увеличивать емкость ClickHouse когда увидите, что нагрузка увеличилась x2 и нужно докинуть серверов?
ещё вижу сложности для Druid в случае «Использование внешних данных для обработки запроса», скормить файл на данном этапе в него нельзя.
p.s. Tranquility не использовал, обычно realtime nodes из kafka вычитывали данные самостоятельно.
так что разработчики не согласны с вами, что это «формат хранения данных, а не передачи».
p.s. лучше брать то, что решает конкретную задачу
те же c++, те же зависимости бинарного кодогенератора по схеме от os где запускаешь
честное признание на их же сайте: Currently it only beats Protobufs in realistic-ish end-to-end benchmarks by around 2x-5x. We can do better. То есть ни о какой разнице на порядки разговор не идет. К тому же учитывая следующий абзац сравнение было на c++ версии, что происходит в java неизвестно
для java нету оффициального сериализатора, а сторонний заброшен с февраля (Cap’n Proto’s reference implementation is in C++. Implementations in other languages are maintained by respective authors and have not been reviewed by me)
как результат: взять такой продукт в продакшен вместо протестированного protobuf лично я не решусь никогда
Я пока не видел людей которые считают protobuf серебрянной пулей =) чаще встречаю которые считают, что json это верх совершенства и пихают его везде, а потом ловят несогласованность форматов в рантайме. В свое время лично для меня proto решил много проблем, так как позволяет высунуть контракт протокола на сервисы и гарантировать его соблюдения.
Со строками чаще проблемы не в том что копируются туда-сюда, а в самом кодировании-декодировании в UTF8, так как в java локальное представление Unicode, вот тут CPU и проседает частенько =(
1. начиная с protobuf v3 одной командой в протофайле option java_multiple_files = true; отключаем генерацию большого файла, получаем набор class=>file. Править полученные протофайлы вам не запрещается, при большом желании можно расширить компилятор и он будет генерить то что вам нужно и прописывать интерфейсы какие хотите
2. как вы предлагаете изменять byte[] в котором по определенным смещениям лежат значения изменяемой длинны? (ваш же пункт 4, чтобы что-то поменять нам нужно будет хвостик сдвинуть влево-вправо и изменить размер самого массива) Если объект в системе вроде как и готов, но возможно еще будет меняться, то перекидывается ссылка на билдер, а вот если нужно отправить в wire клиенту, то тут уже и build() вызывается и получаем готовый слепок.
3. сами же и сказали решение проблемы, dto не должно думать как упаковать граф, а потом его распаковывать, или может JSON уже научился такое делать? с учетом того что proto v3 еще ближе приблизился к json, то упаковка графа в руках того кто упаковывает, а совсем не стандартная операция.
4. [PROTOBUF+ZIP] vs [JSON+GZIP] это спор на уровне: у нас есть SQL и у нас есть NoSQL, в одном схема прописана и если говно пришло то оно сразу отбросится, во втором мы что-то как-то запишем-прочитаем. И далеко не у всех текста гоняются, зачастую только ID нужных элементов. К тому же сами признали увеличенную нагрузку на CPU, что для мобильных приложений очень критично. Хотите еще быстрее, с меньшей нагрузкой на CPU и без схемы, то добро пожаловать в MessagePack, только потом не жалуйтесь, что клиенты прислали очередную кашу.
В общем у вас пожелания: я хочу бинарный формат, который работает быстро, является компактным, сохраняет и проверяет схему, сохраняет ссылочность, позволяет без копирования изменять поля прямо в byte[] и т.д.
Лично я не знаю таких форматов и вижу противоречия в требованиях: компактный vs изменения сразу упакованного массива, компактный-быстрый vs сохраняем целиком ссылки-граф.
linux-mac консоль и окружение пересекаются почти полностью, за исключением мелких моментов
Так что для девелоперов если брать по возможностям окружения, то для меня в порядке убывания это linux/macos/windows(тут обычно у меня только боль)
если брать полностью все окружение и возможности, то macos более вылизанная и гладкая, меньше телодвижений, чтобы что-то настроить, так как зачастую это не нужно.
что не нравится в windows: поддержку 4к мониторов нормально запилили только в 10ке, до этого разный dpi на ноуте и мониторе нельзя было проставить, в маке с момента появления ретин это возможно и работает отлично
что не нравится в macbook pro (именно железо): 16гб памяти это лимит и обновить нельзя, так как распаяна, а больше даже в новых нельзя купить, мне как девелоперу периодически не хватает…
по железу и батареи если начинать смотреть похожие конфигурации, то по ценнику что маки, что аналоги стоят сопоставимых денег
но по порядку:
1) там было написано МИНИМАЛЬНОЕ что нужно сделать, но до нормального бенчмарка код все равно недотягивает
2) java 490ms, python 330ms
но раз вы уже пошли до «сложных регулярных выражений» со ссылкой на вашу методику, то и тестируйте её, чего сразу и не прогнать конечный регексп написанный вами же?
у меня получилось:
java 855ms и python 750ms
и если сразу не было 2 раза, разрыв не то что в процентных числах, в абсолютных начал уменьшаться при росте общего времени выполнения
пытаетесь доказать, что питон быстрее? так это не питон, а си в данном случае быстрее, причем в треде с этим никто не спорит
вот только java реализация написана на java
python реализация на сях и полный список веселья тут,
а уж если вам так сильно необходимы быстрые регулярные выражений, то возьмите jregex, эта «нехорошая библиотека» на первом regexp выдает 130ms и на втором сложном 290ms, что оставляет глубоко в оппе как стандартную реализацию java, так и python
итого имеем:
java(standart)/java(jregex)/python(re)
490ms/130ms/330ms
855ms/290ms/750ms
итого мы доказали: стандартная обертка питона быстрее стандартных реализаций java (разница от 15% до 50%), и в более чем 2 раза медленней оптимизированной java реализации
вывод: нужны быстрые регекспы, берешь не питон/java/js/непонятночто, а нормальную либу
потом можно продолжить поисковым движком elasticsearch (напомните мне схожий по возможностям продукт не на java, вроде sphinx что-то умеет, правда количество упоминаний и инсталяций в разы меньше)
дальше продолжаем быстрой распределенной очередью, чтобы заменить kafka (zeromq это конструктор, а не готовая распределенная персистентная очередь)
так как нам нужно распределенно считать, то следом в очередь spark, storm (даже у последователя heronосновной объем кода это java), gearpump
можно еще упомянуть hbase (бедные Airbnb и Xiaomi не знаю, что нельзя его было использовать) или его сородича accumulo (писалась по заказу АНБ с требованием жестких ACL вплоть до отдельной ячейки)
вот так сидят все и формочки клепают
но большинству достаточно цифр из желтых газет чтобы начать истерить
1) делать замеры производительности на ideon само по себе глупо
2) в примере java происходит измерение в одном интервале «медленного режима интерпретатора» и «быстрого скомпилированного», общее число 500мс совсем не говорит о том какого режима было больше, а напоминает известный анекдот
вот пример с моей стороны pastebin
он еще содержит туеву хучу потенциальных ошибок измерения в разделе вырезания кода эскейп анализом, но все-таки чуть лучше чем было сразу
итого на моей системе получаем устоявшуюся скорость:
1) nodejs 100ms
2) java 200ms
3) python 400ms
зря @rossws сразу не привел примеры его java кода сразу, было бы меньше вопросов про прогрев и итерации
есть сильно разряженный граф, но достаточно большой (100млн записай)
имеется 2 вершины
сколько по времени может проверка что элементы связаны меньше чем в N переходов?
в частности насколько это возможно выкинуть на UI через какой-либо промежуточный сервис
да, немного улучшили, но главная позиция именно в «вам честный стриминг не нужен» и как результат мы имеем
http://beam.incubator.apache.org/capability-matrix/
причем для 2.0 спарка почти ничего не меняется
>> У вас есть какие-то предложения по их развитию
как минимум были предложения по https://github.com/amplab/spark-indexedrdd и которые местами мне интересны, в качестве быстрого распределенного хранилища, без необходимости тянуть сбоку imdb + получаем и локальность вычислений
>> Хм, в презентациях посвящённых Catalyst использовался, вполне себе dataframe-api и не было sql. Ну и потом, они же взаимозаменяемы и оптимизация будет одинаковой
не могут быть они полностью взаимозаменяемые, так как в dataframe как и у rdd хватает терминальных операций, а sql может состоять из нескольких слоев и проще выполнять push down для предикатов. с sql у нас на руках весь план запросов имеется. хотя для простых запросов действительно функционально одинаковы sql vs dataframe.
p.s. и самый простой вопрос который мне нравится к спарку: данные у меня приходят пускай и условно равномерно, но бывают всплески, как мне гарантировать что в какой-то момент я не захлебнусь? у того же beam/dataflow для окна есть тригеры по объему, что мне делать в этом случае со спарком, который не позволяет управлять размером очередного батча
streaming — как пилили микробатчи, так и будем пилить, ожидать честного стриминга не стоит и «он вам не нужен»
sql — как пилили кастомный Catalyst, так и будем пилить, плевать мы хотели на другие уже существующие и отлаженные инструменты (для примера https://calcite.apache.org/ )
rdd — забили на развитие, используйте dataframe
dataframe — пока юзайте, но учтите, что основные изменения у нас в sql, так что может и вам что от планировщика перепадет, но вообще лучше тоже двигайте в sql, там все оптимизации
и да, dataframe уже в разы быстрее чем rdd для питона, так как имеет схему и гонит данные в лямбды достаточно хорошо, поэтому arrow больше для общения между любыми системами интересно
я не спорю, что спарк развивается, но зачастую шумихи больше чем достижений
вот возьмите Фрунзенский район =) еще то веселье, даже в ванне запах хлорочки летом может стоять, про чай из этой воды я вообще молчу. Пока жил в Партизанском районе меня все и из под крана устраивало, а после переезда сразу начал покупать бутилированную, потом поставил фильтр с обратным осмосом.
1. sharding — у вас он ручной,
1.1 что делать если клиенты в разных шардах растут с разной скоростью и у нас на одном шарде 100млн, а на другом 1млн записей?
1.2 как делать перебалансировку в случае если нам нужно добавить +1 сервер в кластер
2. fault tolerance
2.1 мультимастер еще нужно уметь настраивать, в master-slave при выпадении master тоже веселье
если у вас 1 мастер и пачка слейвов, так как нагрузка на запись минимальная, почти все это чтение, то вам конечно повезло,
но ведь nosql любят в первую очередь за то, что у вас ключи разбиты по бакетам которых заметно больше чем серверов и эти бакеты свободно мигрируют между узлами (решаем задачу 1 с балансировкой и добавлением новых узлов), а выпавшего мастера автоматически подхватывает кто-то другой (в hbase и mongodb на основе кворума, у cassandra вообще мастера нету) (решаем задачу сложности конфигурации для задачи 2).
правда если уж начали про mysql в качестве nosql, то я бы ожидал услышать про handlersocket, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных