Comments 5
У меня была похожая задача, сначала тоже хотел json сохранять, но потом подумал, что читать целиком его всё равно никто не будет, зато нужно несколько приседаний при записи и чтении, что видно в статье. И всё ради чего? Ради того, чтобы это был валидных json. Автору нужно поддержать старый контракт, а я перешёл на .jsonl, в котором каждый айтем данных хранится на отдельной строке в файле в виде цельного json-объекта.
Даже курсорное чтение из s3 прикрутил, когда АПИ вместе с данными возвращало смещение в файле, чтобы можно было батчами вычитать все данные.
А если рядом положить файл с смещением каждой, скажем, каждой сотой строки, то вообще с произвольного места читать можно будет :D
>В .NET подобные структуры данных имеют дополнительную служебную нагрузку (примерно 24 байта на элемент), а также хранят ссылки на свои элементы.
А у вас есть контроль над типами ReportItem/ReportValue? Нельзя ли там какие-то элементы уложить собственно в структуры (struct) и посмотреть, какая экономия памяти из этого получится?
>Именно так работает потоковая сериализация, мы не строим весь объект в памяти, а записываем каждую пару ReportItem в ReportValue сразу в JSON-файл. Никаких временных словарей. Никаких temp-файлов. Только один проход и готово.
Всего кода не видно, но по описанию мне кажется, что у вас в цикле за чтением следует запись, а тут напрашивается вариант разделения чтения и записи на два потока с использованием какой-нибудь потокобезопасной очереди в качестве буфера обмена (system.threading.channels - наверное, проще всего). Интересно, принесло бы в вашем случае это какие-то существенные выгоды?
Вы в key в json держите List? Современный System.Text.Json сериализует через pipewriter, нету никакой полной буферизации в памяти, зато есть частичная буферизация чтоб не обращаться часто к диску. Также оптимальней чем у Вас организована работа с памятью.
Непонятно в чем заключается обработка отчетов.
Оптимизация обработки больших отчетов в .NET Core: от памяти к потокам