Возможно я не в курсе про какую-то концепцию. Но я не помню, чтобы в C/C++ было понятие транзакций памяти. Ссылка на статью в Вики про транзакционную память -- это совершенно другое понятие, которое к ручному менеджменту памяти имеет весьма опосредованное отношение
Ну справедливости ради, json тоже вполне себе можно быстро парсить. Например, тут парсят со скоростью 3.5 Гб/секунду https://github.com/simdjson/simdjson
Да и жмется обычной он вполне хорошо (я сжимал биржевые данные и получал сжатие до 27 раз).
Да и просто замена может не сработать, например, если у разработчиков неструктурированные данные, то не получится однозначно сконвертировать.
Еще важный момент, что переход от json к csv на на текстовых данных вероятно уменьшит размер всего в 2 раза (если предположить, что размер ключей ~ размеру значений), что уменьшит размер в вашем случае до 1.5...2.5гб, чего может быть недостаточно, если количество данные растет
Выглядит, что проблема точно не в формате данных. Замена на csv не решит проблему, в лучшем случае отсрочит. вероятнее всего вам нужно более глобально архитектуру переделывать, чем просто поменять формат
Хочу вбросить мысль, что сейчас в интерфейсы (в смысле GUI) так быстро меняются, что навык основанный на каком-то отдельном интерфейсе и процессах в нем -- весьма бессмысленный и затрачиваться на конкретный интерфейс сейчас точно не стоит
Сейчас главный навык -- поиск. Почти во всех современных интерфейсах операционных системах добавили функцию быстрого поиска. Во многих IDE она есть и тд
Например, в window больше никогда не ищу пуск -> стандартные -> ножницы и тд. Намного удобнее и быстрее нажать win и вбить "ножн.."
То есть в нынешних реалиях важнее научиться искать, использовать инструменты быстрого поиска и практически никогда не переучиваться) а все эти особенности интерфейсов превращаются в белый шум, которым не стоит никогда пользоваться
Ещё добавил бы, что индекс hash не поддерживает WAL, поэтому
они не crash safe. Их в случае сбоев надо их перестраивать (но, понятное дело никто после падения об этом не встромнит и после перезапуска пользователи будут жить с закорапченым индексом)
при физической репликации индексы не будут обновляться (тоже ничего хорошего не будет после сбоев)
Возможно я не в курсе про какую-то концепцию. Но я не помню, чтобы в C/C++ было понятие транзакций памяти. Ссылка на статью в Вики про транзакционную память -- это совершенно другое понятие, которое к ручному менеджменту памяти имеет весьма опосредованное отношение
Ну справедливости ради, json тоже вполне себе можно быстро парсить. Например, тут парсят со скоростью 3.5 Гб/секунду https://github.com/simdjson/simdjson
Да и жмется обычной он вполне хорошо (я сжимал биржевые данные и получал сжатие до 27 раз).
Да и просто замена может не сработать, например, если у разработчиков неструктурированные данные, то не получится однозначно сконвертировать.
Еще важный момент, что переход от json к csv на на текстовых данных вероятно уменьшит размер всего в 2 раза (если предположить, что размер ключей ~ размеру значений), что уменьшит размер в вашем случае до 1.5...2.5гб, чего может быть недостаточно, если количество данные растет
Выглядит, что проблема точно не в формате данных. Замена на csv не решит проблему, в лучшем случае отсрочит. вероятнее всего вам нужно более глобально архитектуру переделывать, чем просто поменять формат
А тут случайно не получится генетический алгоритм с дополнительными шагом в виде численных методов оптимизации?)
Хочу вбросить мысль, что сейчас в интерфейсы (в смысле GUI) так быстро меняются, что навык основанный на каком-то отдельном интерфейсе и процессах в нем -- весьма бессмысленный и затрачиваться на конкретный интерфейс сейчас точно не стоит
Сейчас главный навык -- поиск. Почти во всех современных интерфейсах операционных системах добавили функцию быстрого поиска. Во многих IDE она есть и тд
Например, в window больше никогда не ищу пуск -> стандартные -> ножницы и тд. Намного удобнее и быстрее нажать win и вбить "ножн.."
То есть в нынешних реалиях важнее научиться искать, использовать инструменты быстрого поиска и практически никогда не переучиваться) а все эти особенности интерфейсов превращаются в белый шум, которым не стоит никогда пользоваться
Спасибо!
как быстро информация устаревает)
Ещё добавил бы, что индекс hash не поддерживает WAL, поэтому
они не crash safe. Их в случае сбоев надо их перестраивать (но, понятное дело никто после падения об этом не встромнит и после перезапуска пользователи будут жить с закорапченым индексом)
при физической репликации индексы не будут обновляться (тоже ничего хорошего не будет после сбоев)
Вероятно вам стоит сделать в другой бд буферную таблицу, потом на основе нее сделать что-то вроде
insert .... from select ...
Если это повторяющийся процесс, то посмотрите в сторону различных etl решений, например, nifi , apache airflow
Если вы хотите выгрузить таблицу + связи, то вероятно вам потребуется выгрузка через pg_dump