All streams
Search
Write a publication
Pull to refresh
35
0
Илья Сазонов @poxvuibr

Software developer

Send message

Получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных.

А как вам это удалось? Ведь судя по джаваскрипту используется конструкция limit ... offset . Неужели работает? Или там одна строка занимает мегабайты? Но на скриншоте строки маленькие.

Интересно, узнать объём данных поточнее. Сколько там сотен гигабайт получилось? И сколько это строк. И на каком диске лежат данные?

Индексы, наверное, по всем колонкам, да?

И выходит так, что спрятав через lombok обвязку, приходится писать еще больше бессмысленного кода (юнит тесты на все это спрятанное).

Эти юнит тесты нужны не зависимо от того, пишет программист код сам или делегирует это lombok. Но если код написан вручную, то в юнит тестах ещё надо как-то проверять, что при добавлении нового поля, программист поправил код так, чтобы он его тоже обрабатывал. А если мы используем lombok, то это не нужно, потому что lombok делает это за нас

С одной стороны приятно спрятать лишний код

С моей точки зрения польза от lombok не в том, что можно спрятать лишний код, а в том, что можно добавить в класс поле и к нему автоматически сгенерируются все обвязки. И геттеры и сеттеры и конструктор и билдер и всё остальное. Чтобы убедиться, что я ничего из этого не забыл - нужны юнит тесты. Точно такие же, как к ДТО с использованием lombok, только более подробные.

По итогу мне не нравится lombok, но я за его использование, потому что без него получается ещё хуже.

Так что тестировать такой класс не пришлось бы, ибо корректность кода мы перекладываем на язык/генератор.

Да вот не фак. Рекорды ещё ничего, но вот Lombok это сложная библиотека и не факт, что вы правильно расставите аннотации. Плюс там таки встречаются баги, хотя это уже реже.

Вдобавок, если брать не просто работу с памятью, а работу с каким-нить рамдиском, то его производительность вполне сопоставима с PCI-E NVMe

Возможно, если воткнуть nvme в слот, который находится "близко" к процессору, то скорость будет как-то сопоставима, но на чисто эмоциональном уровне я не верю )))

К тому же tmpfs не использует кеш о котором столько сказано в тексте статьи, а значит в должна быть побыстрее хотя бы формально.

И наконец, интесивная работа в tmpfs не истощает ресурс ssd ))

Хотя, конечно, было бы неплохо проверить, какая там разница по скорости будет, я только не уверен как это сделать. Могу ядро скомпилировать, но не уверен, что это показательно

Впринципе, если сначала писать код, а потом мучительно добавлять для него тесты, то наверное и правда в каком-то таком простом случае ChatGPT прямо поможет. Но кто же пишет тесты после кода )))

Ибо современный размер сектора - 4 кб

Размер кластера в ФС тоже 4 килобайта по умолчанию. Но я, например в последнее время ставлю 64к, потому что на дисках в основном большие файлы. Вот тебе и запись минимум 64к )) . На одном диске вообще два мегабайта размер кластера. Там совсем большие файлы

Что такое?!... Я опять отмонтировать забыла?!

Ничего страшного, sync не забыла, так что нормально всё будет ))

как может человек знать линукс на уровне глубже двойного клика по ярлыку и не знать про кеширование записи?

Это знание приходит после того, как он в первый раз выдёргивает из компа флешку, на которую скопировал файлик гига где-нибудь на 4 )))

Смотря что вы имеете в виду. Если вы о type erasure в смысле C++

Нет, я про type erasure в смысле дженериков в Java

Если я нигде не пользуюсь конкретным n в типе Vect n Nat, то таскать с собой n в рантайме совершенно не обязательно.

В смысле если мы у нас есть объект с полем, которое называется pole и мы этот объект передаём по значению и путём статического анализа кода мы поняли, что pole не используется внутри функции, то мы можем не делать копию pole при передаче?

Выбрасывание типов после компиляции — лучшее, что с ними можно сделать.

Задам дурацкий вопрос. Это про type erasure?

"не используйте технологии/процессы бездумно, а спрашивайте себя и команду зачем и почему"

Представьте себе ситуацию - вы не значете, зачем вы используете именно эту технологию и почему процесс выстроен именно так. Ну, то есть спросили и не нашли ответа, который вас бы устроил. Что делать дальше?

Ну как. Процессы называют аналогичными, если они описываются одинаковыми уравнениями. Ну или похожими, если аналогия не точная. Это нужно как раз, для того, чтобы не понимать, как происходит процесс, но иметь возможность его контролировать, за счёт того, что ты понимаешь, как происходит аналогичный процесс

Аналогии для объяснения вредны, потому что создают больше проблем, чем решают
Полезны они только для иллюстрации, когда вы кого-то чему-то учите, а не спорите с кем-то.

Я бы даже сказал, что не для иллюстрации, а для того, чтобы человек мог что-то делать, на самом деле не понимая что он делает.

Вы верно понимаете проблему, но у вас плохой аргумент.

Про АЭС это был не аргумент, это была аналогия. Аналогии врут, но мне постоянно советуют использовать их для объяснения. В очередной раз я продемонстрировал, что их лучше не использовать.

В случае ML-инструментов (но не только их) существует проблема того, что мы не знаем, что именно случится, если их использовать.

Хорошее уточнение, да. Если развить аналогию с АЭС, то можно сказать, что когда ты не в курсе какие правила нужно соблюдать, чтобы АЭС была безопасной - лучше её вообще не включать. Но аналогии врут, конечно. То, что написали вы, мне кажется более понятным.

Традиционное замечание: инструменты не опасны, опасны люди которые их применяют со злыми намерениями.

Стандартный ответ от Юдковского. В случае с ИИ опасен инструмент сам по себе. Для того, чтобы он принёс вред, злых намерений не нужно. Как с атомной электростанцией - достаточно не соблюдать технику безопасности и всё кончится плохо. И если с АЭС технику безопасности хотя бы стараются соблюдать, то с ИИ этот вопрос не волнует вообще никого.

В общем вы просто можете получить вложенный список как вложенный список (чудо).

Можем, да.

И нет, производительность не немного отличается, а очень-очень сильно отличается.

Вот это прямо интересно, может у вас есть ссылки на тесты?

Это легко можно или проверить

Вы проверяли? Какую СУБД использовали? Может быть есть ссылка на гихаб?

И нет, batch size делает вообще не это

Не это? А что вы имеете в виду? Непонятно о чём речь. Непонятно на какой кусок из моего комментария вы возражаете. Я писал, что @BatchSize помогает одновременно порешать проблему декартова произведения и проблему n + 1 . Так оно и есть.

Я же говорю про inner select и CTE

Сложно сказать, что вы имеете в виду. Я сначала думал, что речь о том, чтобы с помощью подзапрос вытащить все элементы коллекции и преобразовать их в jsonb, но дальше вы пишите, что Hibernate умеет делать inner select. Наверное вы имели в виду subselect, но в Hibernate он отвечает за другое. Было бы круто пример какой-нибудь

Hibernate можно постараться приказать делать inner select, только он будет игнорировать указания в ряде случаев (и не упадет с ошибкой)

Можно пример?

мы этого хотим только по причине того, что не можем нормально, удобно использовать for update с orm.

Чтобы использовать select for update с jpa нужно написать

query.setLockMode(LockModeType.PESSIMISTIC_WRITE)

Не то чтобы это сильно отличается по удобству от вставки for update прямо в запрос

Наше приложение не могло идентифицировать эту разнообразную чушь и падало. Мы сначала писали кучу обработчиков, но тщетно... вот пришли к такому решению.

Ну по идее надо сделать один обработчик на методе получения данных. Или там данные, которые пришли снаружи, могли привести к ошибке в непредсказуемый момент? Тогда я бы стал логать данные и также сделал общий обработчик, который пишет в логи стектерйс эксепшна.

Игнорировать исключения - неправильно, надо их хотя бы логгировать. Я лично в своём пет проекте пару дней назад словил неприятностей, потому что заигнорил исключения. Казалось, там вооще ничего не могло пойти не так. А надо было логгировать, времени это бы мне сэкономило серьёзно.

Видимо не понравилось оно сообществу. Один хейт в комментариях.

Хейт не из-за того, что ваше решение не понравилось, а из-за того, что вы не использовали стандартные решения. Мне ваша статья понравилась, я её плюсанул. Для меня наличие стандартного решения - не повод не рассказать о велосипеде.

Комментарий у меня ехидный получился, конечно ((( . Примите как дружескую подколку. Как я понял суть вашей статьи в том, как манипулировать процессами с помощью питона, а не в том, как писать идеальный код ))

Может быть если бы вы написали, что можно было решить проблему по другому, но вы выбрали именно свой вариант - минусов было бы меньше. Но и комментариев было бы меньше ))

Information

Rating
4,750-th
Works in
Date of birth
Registered
Activity