Комментарии 19
Я бы дополнил бы статью примерами использования дата-время, в разных ISO стандартах, там много интересного есть
hello world! джейсон примерно 300Гб, напишите как вы там будете?
мне кажется, или тому кто использует джейсоны на 300 Гб надо просто оторвать руки, чтобы он не мучался и не мучал окружающих?
Кстати, напомнили. Во времена, когда гугловый RSS reader прекращал своё существование, я успел сохранить (экспортировать, архивировать) всю новостную ленту со всеми новостями. Он в JSON формате. Без форматирования. Точный размер не скажу, но помню, что исчислялось гигабайтами.
Существующие на тот момент библиотеки не справлялись с таким объёмом данных. Нужно попробовать этот вариант, ради интереса.
Чтож, оторвите, например. Вопрос то был про "длинные" данные, а вы руки отрываете и это! hello world, то что есть из коробки в го, итак понятно.
кстати, у Дейва Чейни была великолепна статья, как работать с большими объемами, вы ему скажите, что оне не прав и всем хватит 640 килобайт
Смотря как оно лежит
В 90% случаев это простой массив обьектов (логи или отчеты)
И оно спокойно читается построчно
Но даже если все "по красоте" с отступами и переносами и сам документ не просто листинг однотипных обьектов, то все равно читаешь построчно но уже до определенного обьема с расчетом что бы закрылась ветка максимально (простая математика скобочек и кавычек с двоеточиями)
.
Я не знаю задачи где бы понадобилось выгрузить все 300гб данных в память одним обьектом
А декомпозицией можно терабайтами ворочать
Видимо, вопрос с подвохом, потому что есть возможность читать не просто построчно или поблочно, а по-токенно. Читать его хоть из потока, и на лету декодировать содержимое
"На лету" json можно поймать коленом
Особенно если данные никак не формализированы и могут прилетать и строки с экранированными символами
Потому и поблочно. Во первых это можно асинхронно, а во вторых сначала разметил блок, валидация и ток потом парсинг.
Json очень человеко-доступный но в плане машинного доступа он только в малых размерах приятен.
назовите хоть одну библу, где там вся асихронщина, ы?
Если под строками с экранированными символами вы подразумеваете json-строки, то и ничего страшного: буферизируете токены, пока не соберётся полный литерал; либо наткнётесь на ошибку.
Что касается формализации, так эта проблема никак не решается наивным разбиением на некоторые допустимые блоки исходных данных. Более того, вы вводите тем самым допущение, что очередная порция данных не будет превышать какой-то порог.
сначала разметил блок, валидация и ток потом парсинг
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.
Поэтому определение границы блока, валидация и парсинг — по сути один процесс, который можно и нужно делать в один проход. Ну а коли так, то почему бы и не из пайпа, к примеру? Если переживаете насчёт памяти, то можно и добавить проверку превышения некоторого порога.
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.
Неа
Как раз для больших и кривых данных именно так как я написал
Сначала выделяется блок. Логика простая - читаем из файла в буфер, пока буфер не станет определенного размера. Самое главное обрезать буфер там где количество открывающих/закрывающих кавычек и скобок вышло в ноль (например инкремент на [, декримент на ])
Потом мы валидируем этот блок. Еще не парсим, но валидируем так как отсечение по нулевой сумме закрытия хоть и быстрый процесс, но очень не точный. Теперь четко определяем начало json-переменной и проверяем что бы было закрытие. Если закрытие уперлось в конец буфера, то подставляем закрывающий нужный символ
И когда у нас есть фрагмент файла из которого получили валидный json - только тогда уже стандартными средствами заряжаем его в парсер json
.
Если сразу пихать фрагмет в парсер а потом отталкиватся от обработки ексепшенов, то на порядок больше времени и ресурсов потратится потому как парсеры разбирают все дерево и только в случае неудачи выбивают панику или ексепшен
бинго! Вы все правильно поняли!
видимо вы не умеете читать, разговор, если вы не поняли, был про коробку го и "длинные" данные, которые не из коробки. Что там и где лежит вы там порешали, очередной синьор помидор?
Кто ты к̶л̶о̶у̶н̶ воин?
Куча коментариев потому отвечу только тут.
Поток сознания далек от осмысленности, но что вы имели в виду я понял.
Для того и нужна декомпозиция что бы не работать с большими данными одним куском
Если же вы за то что в go размерность обычно в int возращается а не в uint из за чего можно провафлится с реально большими данными - сушествует uintptr и множество способов работы с большими данными в go
вы не знаете задач про 300Гб, поделитесь про террабайтную декомпизицию.
Поддерживаю! А для логов/отчётов уже придуман JSONL (JSON Lines).
Приветствую. Ошибка в "полный код" - нет доступа в https://goplay.tools/snippet/UfszC3iDvZW
Публикации
JSON in GO