Context Navigation

Changes between Version 8 and Version 9 of IppToPspsDatastorePV3Descriptions

v8	v9
2	2
3	3	There is a desire to organize the datastores for PV3 into sky chunks that are of a similar size of data, organized by dxlayer and load merge machine. The intent is to always feed the PSPS a chunk of batches that add up to a similar size in bytes for each PSPS machine so there are no surprises. It also follows the new PSPS hardware design including the switches and network.
4		See [https://ps1wiki.ifa.hawaii.edu/trac/wiki/PSPSClusterHardwareEstimate2015 \| PSPS Hardware Plan C] Over the course of the ingest and merge, the only thing that will significantly vary as we ingest across the sky is the cumulative size of the merged database. Each subsequent addition prior to merge, will be about the same size, and will be handled by a similar machine. Our greatest uncertainty at this stage is the scaling with the total size, not the scaling per chunk. This page describes a "datastore tessellation".
	4	See [https://ps1wiki.ifa.hawaii.edu/trac/wiki/PSPSClusterHardwareEstimate2015 PSPS Hardware Plan C] Over the course of the ingest and merge, the only thing that will significantly vary as we ingest across the sky is the cumulative size of the merged database. Each subsequent addition prior to merge, will be about the same size, and will be handled by a similar machine. Our greatest uncertainty at this stage is the scaling with the total size, not the scaling per chunk. This page describes a "datastore tessellation".
5	5
6	6	== Step 1 ==