issue_comments
4 rows where author_association = "NONE" and issue = 466994138 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Support parallel writes to zarr store · 4 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
672978363 | https://github.com/pydata/xarray/issues/3096#issuecomment-672978363 | https://api.github.com/repos/pydata/xarray/issues/3096 | MDEyOklzc3VlQ29tbWVudDY3Mjk3ODM2Mw== | cdibble 8380659 | 2020-08-12T16:26:46Z | 2020-08-12T16:26:46Z | NONE | Hi All, Thanks for all of your great work, support, and discussion on these and other pages. I very much appreciate it as I am working with Xarray and Zarr quite a lot for large geospatial data storage and manipulation. I wanted to add a note to this discussion that I have had success using Zarr's built-in It does seem that providing explicit chunking rules as you have mentioned above (or using the Zarr encoding argument, which I haven't tried but I think is another option) is a great way to handle this and likely outperforms the locking approach (just a guess- would love to hear from others about this). But the locks are pretty easily implemented and seem to have helped me avoid the problems related to race conditions with Zarr. For the sake of completeness, here is a simple example of how you might do this:
I would be happy to discuss further and am very much open to critique, instruction, etc. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Support parallel writes to zarr store 466994138 | |
549730000 | https://github.com/pydata/xarray/issues/3096#issuecomment-549730000 | https://api.github.com/repos/pydata/xarray/issues/3096 | MDEyOklzc3VlQ29tbWVudDU0OTczMDAwMA== | VincentDehaye 18643609 | 2019-11-05T09:06:27Z | 2019-11-05T09:06:27Z | NONE | Coming back on this issue in order not to leave it inactive and to provide some feedback to the community. The problem with the open_mfdataset solution was that the lazy open of a single lead time dataset was still taking 150MB in memory, leading to 150*209 = 31,35GB minimum memory requirement. When I tried with a bigger (64GB memory) machine, I was then blocked with the rechunking which was exceeding the machine's resources and making the script crash. So we ended up using a dask cluster which solved the concurrency and resources limitations. My second use-case (https://github.com/pydata/xarray/issues/3096#issuecomment-516043946) still remains though, I am wondering if it matches the intended use of zarr and if we want to do something about it, in this case I can open a separate issue documenting it. All in all I would say my original problem is not relevant anymore, either one can do it with open_mfdataset on a single machine as proposed by @rabernat, you just need some amount of memory (and probably much more if you need to rechunk), or you do it with a dask cluster, which is the solution we chose. |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Support parallel writes to zarr store 466994138 | |
516043946 | https://github.com/pydata/xarray/issues/3096#issuecomment-516043946 | https://api.github.com/repos/pydata/xarray/issues/3096 | MDEyOklzc3VlQ29tbWVudDUxNjA0Mzk0Ng== | VincentDehaye 18643609 | 2019-07-29T15:37:27Z | 2019-07-29T15:38:31Z | NONE | Coming back on this issue (still haven't had time to try the open_mfdataset approach), I have another use case where I would like to store different variables being indexed by the same dimension, but not all available at the same moment. For example, I would have variables V1 and V2 indexed on dimension D1. V1 would be available at time T, and I would like to store it in my S3 bucket at this moment, but V2 would only be available at time T+1. In this case, I would like to be able to save the values of V2 at time T+1, leaving the missing V2 values filled with the fill_value specified in the metadata between T and T+1. What actually happens is that you can append such data, but then if you want to open the resulting zarr the open_zarr function needs to be given V2 as value for its drop_variables argument, otherwise you get the error shown in my original post. However, as the open_zarr function is called when appending as well (cf. original post's error trace), and in this case you can not provide this argument, you will fail the next append attempts, thus preventing you from appending the values of V2. Your dataset is now frozen. Am I misusing the functionality, or do you know any workaround using xarray and not coding everything myself (for optimization reasons)? |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Support parallel writes to zarr store 466994138 | |
510816294 | https://github.com/pydata/xarray/issues/3096#issuecomment-510816294 | https://api.github.com/repos/pydata/xarray/issues/3096 | MDEyOklzc3VlQ29tbWVudDUxMDgxNjI5NA== | VincentDehaye 18643609 | 2019-07-12T09:19:41Z | 2019-07-12T09:19:41Z | NONE |
Hi @rabernat, thank you for your quick answer. I edited my MCVE so that you can reproduce the error(as long as you have access to a S3 bucket). I actually forgot about With regards to |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Support parallel writes to zarr store 466994138 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] ( [html_url] TEXT, [issue_url] TEXT, [id] INTEGER PRIMARY KEY, [node_id] TEXT, [user] INTEGER REFERENCES [users]([id]), [created_at] TEXT, [updated_at] TEXT, [author_association] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [issue] INTEGER REFERENCES [issues]([id]) ); CREATE INDEX [idx_issue_comments_issue] ON [issue_comments] ([issue]); CREATE INDEX [idx_issue_comments_user] ON [issue_comments] ([user]);
user 2