Pull to refresh
35
0
Илья Сазонов @poxvuibr

Software developer

Send message

А как вы с этим боретесь? Как выбираете чем заниматься и что говорите тем, чьи задачи делать не будете?

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

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

В "правильном" ответе на 7-ой вопрос в Антарктиде группировка не под дате, а по типу

Там есть вариант, где в селекте первым стоит date и два варианта, где первым стоит type. Понятно, что варианты с первым type не могут быть верными вообще никак, потому что в результате в первой колонке дата. И, конечно, по тесту результат с date в селекте неверный ))

Проще сразу использовать envers

Собственно об этом и был вопрос ))

А зачем оставлять удалённых пользователей в той же таблице, в которой хранятся активные? В чём смысл? Почему их не копировать в отдельную таблицу?

Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"

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

Похоже дело в ваших догадках, "чтении" моих мыслей, да прочтении между строчек!

Да, дело в этом. Я совершенно неправильно истолковал ваш текст.

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

Что благодаря разбиению на страницы можно загружать только часть данных и не нужно ждать пока прогрузится вся таблица? И что благодаря сортировке можно посмотреть не только первые страницы, но и последние.

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

Я тут тоже высказываю догадки и занимаюсь прочтением между строк, это неправильно. Напишите, пожалуйста, что вы хотели сказать.

И что вы имели в виду под грамотной работой с базой данных? Какие приёмы из статьи?

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

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

Есть и страница 1011, под спойлером "Работает!" в ответе вам. С таймингами в отладчике firefox.

Да, странно, что номер страницы 1011, а offset - 352 . Поэтому я и уточняю. Наверное отладчик firefox показывает загрузку какой-то другой страницы? Но вот то, что строки по одной загружаются я правильно понял?

Это же открытый код.

Я чего-то ссылки в статье не нахожу. Плохо ищу?

Вдруг есть идея как сделать так, чтобы выдавало за 1-2мс на произвольной сортировке и базе

Если сделать индексы по каждой колонке, сортировать только по одной колонке, не накладывать фильтры и убрать limit ... offset , то можно . А так - я не знаю как. Вот прочитал что вы написали про большие таблицы, посмотрел на возможность сортировки в интерфейсах и подумал - вдруг вы знаете.

PostgreSQL не выдаст неверный результат, а вот "супер пупер производительная СУБД убийца PostgreSQL" вполне может поступить как вы описали

Это ж будет баг в реализации sql. Я не слышал про СУБД с таким поведением. Они правда есть или это предположение?

Пример с удачным планом для запроса:
select * from ways order by scale desc limit 35 offset 350;
Time: 51,948 ms

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

В простом случае да [используется limit ... offset ] .

Судя по коду у вас как раз такой случай. И я вас так понял, что всё работает с приемлемой скоростью. Или я неправильно понял?

Если хочется быстрее, то конечно надо переходить на ctid

А можно использовать ctid вместе с сортировкой по произвольной колонке?

Первичный ключ и гео столбцы [по ним есть индексы]

На скриншоте можно сортировать по любой колонке. Скорость получается приемлемой несмотря на отсутствие индексов?

И ещё на скриншоте оффсеты совсем маленькие. 352, например. И они меняются на единицу каждый раз. Такое впечатление, что каждая строка загружается отдельным запросом с limit... offset . Страницы из середины или конца больших таблиц при этом загружаются быстро?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Information

Rating
Does not participate
Date of birth
Registered
Activity