我有一个大型的BigQuery,其中数据是每个时间戳的JSON字典。当用户在浏览器上单击上传数据时,会启动一个 AJAX 命令,告诉python从Bigquery下载,破解JSON,应用各种用户确定的FFT等,然后将数据返回给用户显示。这一切都在Cloud Run和Flask上运行。
我的想法是缓存大部分的活动,这样“最近”的时间戳将得到破解和FFT的,但所有的旧时间戳将已经准备在该高速缓存。
但事实证明,我在缓存方面的尝试比使用BigQuery要慢。我想知道我是否可以改进一些设计决策。
我通过Docker上传应用程序,并在/data_dir
上拥有临时存储,我猜是SSD存储。给定转换后的数据,我将一个包含〉100,000行的Parquet文件写入该SSD,然后从SSD上传到Google Cloud Storage上的存储桶。
当需要该高速缓存时,我使用blob.download_to_filename
和pq.read_table.to_pandas()
从GCS下载到SSD。当我完成后,然后更新该高速缓存,使用pq.write_table
到SSD和blob.upload_from_filename
到GCS。访问/从SSD似乎相当快,但GCS相对较慢。10秒,约20 MB。
我很困惑Docker容器示例的规则是什么。我读到过短暂的文件不能在多个示例中生存。但是,我是否可以简单地放弃GCS而只使用临时卷?也就是说,如果一个 AJAX 调用创建了线程并在/data_dir
上保存了缓存,那么我是否可以假设将来的任何Ajax调用都能够访问同一个文件?如果有帮助的话,所有的 AJAX 调用都将转到Flask master python应用程序。
还有什么其他的替代方案可以让缓存对未来的javascript调用可用?
谢了T
1条答案
按热度按时间lrl1mhuk1#
这只是答案的一部分,但这里有两种方法,我研究了从Google Cloud Storage上的一堆文件中提取元数据。使用GCSFS的速度要快两倍多,至少使用下面的代码是这样的(典型比率~0.9秒vs ~2。(3)第三章。