It is necessary to make a backend for storing tiles of cards. The size of each tile is 16 by 16 pixels (initially there is data about the color of each pixel)

Well, as always, the standard requirements: there are a lot of tiles (1k +), there will also be enough requests.

Advise on what to write this miracle and how to store data? And if you can, tell me why nodejs + many png files are bad

    1 answer 1

    It is difficult to say for sure, as the general application is unclear, but I would advise storing it as one big-big file with all the necessary data. Without compression, it will not give profit on such volumes, but it will somehow force it to address everything, i.e. do index and store offsets + sizes.

    Relatively speaking, in your map (as I understand it, this will be an online game or something with small locations) there is a two-dimensional addressing, and you need a 555x777 file with coordinates. We know that the whole map is 1000x1000, which gives us just a million. We consider the offset:

    смещение=(555+777*1000)*(16*16)

    Now we can read 256 bytes from here and give them to the client. Similarly, you can and write.

    why nodejs + many png files are bad

    nodejs is bad because illiterate people write on it, because of which the image of this or that technology suffers. In my personal impression, everyone who used to shkabil php, ran to the node.

    Many files are bad because, as a rule, 1 cluster / block of 4 kb each is allocated to each file (usually, you can of course download files), and we will have 256 byte files (if black-and-white) or 768 (if the color is without alpha channel). Therefore, 4096-256 bytes per file will be lost, this is a huge hole in disk space. The inodes may still end - this is when there seems to be a lot of disk space, and new files have nowhere to go. However, all this can be zatyunit.

    The real problems begin on the search - the driver should read every directory in its path and only then find the file you need. If all the files are folded in one directory, then as a rule this leads to very large brakes. If the directory is spread on a bunch of subdirectories - in principle, it works better, but the search does not go away. In the case of direct addressing, this is not necessary.

    PNG is not bad, but you will not get any sense from compressing such a small amount, but you will receive a bunch of headers and the need for additional processing. In general, it does not make sense.

    • one
      I finished a little - bukkojot