-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Кислов Данил ИТМО ФИТиП HW6 #203
Conversation
# Conflicts: # src/main/java/ru/vk/itmo/test/kislovdanil/service/DatabaseHttpServer.java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR diff size of 20638 lines exceeds the maximum allowed for the inline comments feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR diff size of 20640 lines exceeds the maximum allowed for the inline comments feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR diff size of 20642 lines exceeds the maximum allowed for the inline comments feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR diff size of 20644 lines exceeds the maximum allowed for the inline comments feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Необходимо разрешить конфликты.
Изначальная реализация DAO не читала в оперативную память | ||
весь range, поэтому проблем с решением для этапа не возникло. | ||
Большая часть времени уходит на передачу данных; чтобы уменьшить latency | ||
можно попробовать добавить сжатие данных или как-то ускорить передачу |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Непонятно поможет ли сжатие, так как тогда добавится время на компрессию и декомпрессию.
Из того, что я видел, обычно сжатие используют не для уменьшения latency, а для реализации холодного хранилища. В этом случае о latency как раз не думают, оно напротив увеличивается. Здесь оптимизируется занимаемое место.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
В целом да, хотя я не уверен что нет алгоритмов которые бы сжимали бы быстрее чем было бы передавать, просто гипотетическое предположение
Пробовал все ключи выгрузить из базы одним запросом? |
@incubos |
try { | ||
session.write(ChunkTransformUtility.HEADERS, 0, ChunkTransformUtility.HEADERS.length); | ||
for (Iterator<Entry<MemorySegment>> it = dao.get(start, end); it.hasNext(); ) { | ||
ChunkTransformUtility.writeContent(it.next(), session); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Так, а если в какой-то записи лежит очень большое value. Ты будешь его целиком в сокет запихивать?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Да, а какие варианты? Доставать куски из MemorySegment и их по очереди записывать чтобы не переполнить память? Настолько большой value в текущей логике, кажется, просто не получится записать в бд
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Поговорил с коллегами. Обработку данного случая, мы от вас требовать не будем.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C session.write
вроде бы есть еще проблема. Вроде как там внутри неограниченная очередь, из-за чего теоертически клиент может медленнее отправлять чанки, чем твой код их туда пушит. И это в конечном итоге может привести к тому, что мы таки выгрузим много данных в оперативную память.
Однако я считаю, что перебор от вас такое требовать)
Ок, 15 поставлю |
No description provided.