#javascript #json #compression #protocol-buffers #msgpack
#javascript #json #сжатие #протокол-буферы #msgpack
Вопрос:
У меня есть сетка, которая загружает около 100 тысяч строк данных, объем которых составляет около 20 МБ. Чтобы получить эти данные, мы в настоящее время делаем что-то вроде этого:
cursor.execute(sql)
data = cursor.fetchall()
return HttpResponse(data.json())
И затем мы будем использовать JSON.parse в javascript, чтобы затем загрузить эти данные в сетку. Из конца в конец, каков был бы самый быстрый способ получить эти данные из нашей базы данных в нашу сетку (с одной оговоркой, что мы не разрешаем sql-запрос во внешнем коде javascript)?
Возможные решения, о которых я подумал::
- отправляйте вещи как есть, без сжатия
- gzip данные json (требуется почти нулевая работа)
- сжатие до lz4, затем распаковка в javascript (потребуется компиляция cpp в javascript)
- используйте другой формат, такой как protobuf или пакет сообщений
Меня не беспокоит размер сообщения, меня беспокоит только время от конца до конца отображения этих данных во внешнем интерфейсе. В основном, сколько времени требуется конечному пользователю для получения ответа.
(Обратите внимание, что я не беспокоюсь о разбиении данных на фрагменты, это очень специфический вариант использования, когда пользователь запрашивает загрузку всех данных в таблицу html)
Комментарии:
1. Звучит как хороший вариант использования для синхронизации данных с IndexedDB в браузере. Не нужно было бы отправлять все 100 тыс. строк при каждой загрузке страницы
2. @charlietfl это то, что мы будем делать. Это больше для загрузки данных в начале для пользователя или, если когда-либо произойдет «полное обновление» данных.
3. Я бы также рассмотрел возможность использования пользовательского формата данных, если это влияет на размер полезной нагрузки на огромное количество, обычный CSV? или есть общий префикс, который можно исключить из всех 100 тыс. строк в данных, например, столбец содержит только URL-адреса, такие как example.com/?id=1 , example.com/?id=3 …. У меня просто было бы 1,2,3 в этом столбце csv. Поэтому я думаю, что пользовательский формат данных со сжатием gzip может быть хорошей ставкой.